Tadata

There’s lots of talk about why directly translating APIs makes for bad MCPs. Among those chiming in are three prominent “Davids” in the community: David Cramer from Sentry, David Gomes from Neon, and David Soria Parra, co-creator of the MCP spec itself. And it’s true: most APIs break down in an LLM setting.

And yet, at Tadata, we believe your API is the best place to start. Let’s break it down.

Why APIs Don’t Translate Well to MCPs

1. APIs are designed for granularity, not goal completion

APIs break complex tasks into atomic, tightly-scoped endpoints. That’s great for engineers. But LLMs don’t want a pile of ingredients—they want a recipe.

For example, consider a checkout flow. A developer might string together multiple endpoints:

Create a cart
Add item(s)
Set shipping info
Apply promo code
Submit payment

An LLM has to figure out the correct order, required fields, conditional paths—and execute it all reliably. Even if it can eventually learn to chain calls correctly, it's fragile. And for critical flows like checkout or subscription upgrades, “fragile” is not acceptable.

LLMs thrive on use-case-based primitives, not low-level API mechanics.

2. API patterns don’t work for AI

Conventions like pagination or UID-based references are optimized for bandwidth or engineering clarity—not for LLMs.

APIs assume the consumer knows the business logic. But LLMs are generalists. MCPs should embed that logic into the tool—or better yet, provide reusable prompts and resources so the LLM doesn’t have to guess.

Designing for LLMs means designing for context, resilience, and intent—not just precision and performance.

3. Tool descriptions ≠ API descriptors

What works in OpenAPI—e.g., "status": "The current state of the object"—isn’t helpful when an LLM is deciding when and why to use a tool.

LLMs need expressive, instructional descriptions that guide behavior and decision-making. That’s a very different writing style than what’s typically in your Swagger file.

Why Start With Your API Anyway?

Despite all this, your API is still the best starting point.

Why?

Because it's the closest, most honest expression of your product’s functionality. It’s structured. It’s already maintained. And it lets you go from zero to something usable—fast.

At Tadata, we believe your MCP server should be an extension of your codebase, not something you create from scratch and maintain separately.

Beyond APIs: The Real Power of MCP

MCP isn’t just about tools. It also offers:

Resources: contextual data the LLM can preload
Prompts: reusable, task-oriented instructions

When you simply translate API endpoints into MCP tools, you miss the opportunity to take advantage of these features—and to build smarter, more robust interactions

Some examples:

Tavily’s MCP writes Tavily API integrations that follow their best practices
Neon built a server that tests and safely executes database migrations
Stripe exposes their comprehensive docs as a browsable tool to help LLMs answer developer questions

These go way beyond “just the API.”

Want to Try It?

If you're interested in starting from your API and evolving toward a robust, AI-friendly MCP, check out:

fastAPI-MCP: Open source project to scaffold your MCP from a FastAPI app
Tadata’s platform: Add auth, resources, prompt libraries, and CI integrations to create your MCP and keep it updated as your API evolves

Your API might make a bad MCP. But it’s a great first draft.