Model Context Protocol (MCP), a standard for connecting AI agents to external tools and data, is still a very new tech, and as such, it’s experiencing the same growth pains that any other technology experiences. In this process, certain use and design patterns are starting to emerge — and not always for the better.

One common pattern that has emerged is simply taking your API, generating an MCP wrapper around it, and then calling it a day. On paper, this makes total sense — if you’re exposing an API, why not just expose the entire surface area and let agents interact directly?

While it might seem intuitive, it’s actually a design anti-pattern and has some pretty poor results in practice. MCP isn’t supposed to be a one-to-one mirror of your API — it’s supposed to be an interface for intent.

But what does this mean, and what does it look like in practice? Below, we’ll unpack this issue and try to answer that question, as well as define what a better pattern might look like. Let’s dive right in!

MCP Is Intentional

The pattern of wrapping an API with MCP one-to-one is a misunderstanding of what MCP was designed to be and do. MCP wasn’t built for human developers — it was built for AI agent systems that understand tasks, not just URIs. When you map your MCP functions on a one-to-one basis with your API, what’s the functional difference between your MCP tools and your API? If you take your REST or GraphQL service and replicate it for the MCP broker, what are you practically doing differently?

The answer is simple — nothing. You’re asking the agent to navigate the same maze a developer would. And while a developer may understand complex authentication flows, pagination, request composition, data shapes, or idiosyncratic query parameters, the whole reason MCP exists is because agents can’t do that. In essence, mapping like this to an MCP is doing precisely what MCP was designed to stop.

Instead, MCP should be designed around intents — specifically, what the agent wants to do. Think about an action like creating a user profile. Does the agent want to hit only a single endpoint? Or does it need to make multiple calls, figure out conditional responses, undergo a schema transformation, or much more?

By abstracting the workflow to the intent level, you’re making the agent’s behavior more predictable and its responses contextually aligned with user goals. By just providing the API as is in an MCP wrapper, you’re adding little value — at best, you’re wasting your time, and at worst, you’re making it harder to interact with your systems.

Why One-to-One Mapping Is a Non-Starter

So why exactly does this approach fail? There are a few concrete reasons why this flies against the entire structure and intent of the MCP approach.

Firstly, agents don’t reason like developers. They don’t read API documentation like humans do. Rather, they infer behavior from outcomes. They don’t have 20 years of experience developing APIs. They only have access to their current model training and reference data.

Also, exposing a vast and unstructured data surface can be innocuous. The agent might get confused or hit rate limits. It can also cause more significant issues, like causing them to use the wrong endpoints, hallucinate, or even try to break out of their endpoint confines to force the outcome.

Secondly, complex APIs are seldom a one-and-done affair — they often require complex orchestration, and this orchestration is often obfuscated from the end user. Real-world APIs usually connect multiple endpoints or functions, such as: creating a user → assigning permissions → updating labels → sending a welcome email → changing a variable depending on the response. A one-to-one wrapper forces the agent to handle this orchestration entirely by itself with uncontrollable and unpredictable results.

There’s also the plain fact that humans made this API, and humans aren’t perfect. Most APIs have some level of schema bloat, verbosity, orphaned or shadow systems, zombie endpoints, and so forth. Exposing everything clutters the agent’s mental model, which could increase the risk of malformed requests, and that’s to say nothing of malicious actors who may use this MCP to try to break the system.

Finally, exposing your API this way leads to higher maintenance and drift. Every time your API changes, the MCP tool will need to be re-generated, re-contextualized, and re-documented. It’s messy.

Build Around User Actions

What, then, is the better approach? You should be thinking of MCP tools as SDKs for agents. Just as a human-facing SDK simplifies a complex API into idiomatic functions, an MCP tool should encapsulate the logic an agent needs to accomplish a specific task.

This can be done in a few ways. First, you can create defined flows that handle a specific intent. For example, instead of exposing /api/v1/customers and /api/v1/orders, expose a single MCP method like create_customer_order() that handles the full flow. You could also expose domain verbs like summarize_document() or generate_report() that package context for the model, or even expose an MCP method like find_product_by_keyword() that unifies separate search, filter, and pagination endpoints.

Even if you’re not going to make specific bespoke endpoints and functions, your MCP documentation should provide ample instructions for specific flows and intents.

Best Practices for MCP Development

If you’re trying to get this right, there’s no silver bullet for every MCP implementation. However, there are some best practices and MCP design patterns you can adopt to make your MCP better than the sum of its parts.

Design for Human Intent

Firstly, design for human intent. Remember that today’s agents are acting on behalf of users, not machines. Therefore, identify the verbs that users actually care about, like “create project,” “summarize status,” or “create profile,” and then build your MCP around this intent.

Combine Calls into Workflows

Bundle related operations, and treat a full workflow as a single action. The agent shouldn’t have to chain ten function calls to complete a basic function, and it certainly shouldn’t have to try to intuit how to do something common and relatively basic.

Consider Natural Language

It’s also important to remember that agents are based on large language models (LLMs), which themselves are trained on natural language. So, there’s no need to talk to them robotically or programmatically. Adopting definitions and naming practices that follow how users speak can help here.

Constrain Systems with Schemas

Use schemas to constrain your systems. Give your MCP tool tight and opinionated input and output schemas, and then enforce these schemas to help the agent reason more reliably. This should reduce overall ambiguity, resulting in more intentional utilization. This can also help to establish guardrails and context reference, which can help direct the agent to examples, success criteria, and fallback behavior in the MCP spec. This will thus help the agent stay firmly within the operational expectations of the MCP server, preventing it from going rogue.

Limit What You Expose

Finally, make sure that you keep your sensitive systems and API private. The MCP shouldn’t expose the entire API — it should expose its own layer for its own purpose. You’re basically treating this as a backend-for-frontend or a shim, not as a standalone system. Limiting what the MCP exposes is also good security hygiene, as it helps your authorization logic follow the rule of least privilege.

Foundationally, if we treat MCP as just another interface layer, we’re missing the entire purpose — the MCP isn’t about surfacing every possible endpoint, it’s about teaching an agent what it can do, with what context, and to what end.

The Future of APIs and MCPs

Ultimately, the most successful MCP server implementations are going to be the ones that distill complex systems into intuitive and declarative tasks — tasks that are well-documented and based around intent, not just a data dump of all that can be done.

MCP tools should speak the language of intent, not implementation. As you build out your MCP, ask yourself if you’re building a tool for a developer or a tool for an agent trying to accomplish a task. If you’re doing the former, you might stumble, and if you’re doing the latter, you must treat it as such.