Stop Building MCPs Like APIs: Why the Model Context Protocol Demands a Completely Different Mindset

There is a pattern emerging across AI engineering teams right now. A team gets excited about MCP, the Model Context Protocol, reads the spec, and within a week they have shipped a server. It exposes list_records, get_record, create_record, update_record. It looks clean. It mirrors the REST API they already have. The model can call it. Ship it.

Except it doesn't work the way anyone expected. The model calls four tools to answer a question that should have needed one. Latency is terrible. Token costs are through the roof. Users complain that the AI feels slow and dumb. The team blames the model.

The model didn't design those tools. You did. MCP is not an API protocol, it's a cognitive interface, and the moment that lands, the way you name and shape every tool has to change.

• What is MCP?
• MCP is a conversational mindset
• Building MCP as API vs. MCP Reality
• MCP is user-thought design
• The hidden costs of chatty MCP design
• Principles for MCP design

1. What is MCP?

Model Context Protocol (MCP) is an open standard introduced by Anthropic that defines how AI models communicate with external tools, data sources, and services during a conversation. Think of it as a universal plug standard. Instead of every AI application inventing its own way to call a database or trigger an action, MCP gives a single, consistent contract that both the model and the tool server understand.

At its core, an MCP server exposes three types of primitives:

• Tools: Functions the model can invoke to perform actions or retrieve dynamic data, such as running a query, sending a notification, or looking up a record.
• Resources: Static or slowly-changing content the model can read as context, such as documentation, configuration files, and schema definitions.
• Prompts: Pre-built prompt templates that guide the model through complex workflows in a consistent, reusable way.

The protocol is transport-agnostic, running equally well over stdio, HTTP/SSE, or WebSockets, and it is language-agnostic. SDKs exist for Python, TypeScript, Go, and more. But the spec being flexible is precisely why so many teams reach for the familiar shape of an API when they build their first MCP server. Flexibility doesn't mean equivalence. If you're looking to build production MCP servers, Aptologics offers end-to-end MCP Server development services.

2. MCP is a Conversational Mindset

An API is designed for a deterministic caller. A developer writes code that calls GET /orders?status=pending and knows exactly what they'll receive. The caller is a program. It never improvises.

An MCP server is consumed by a language model mid-conversation. The caller is a reasoning system that is simultaneously managing context, tracking user intent, deciding which tools to invoke, and generating natural language. It improvises constantly. The tools you expose are not just functions. They are vocabulary that the model uses to think.

This distinction reshapes everything about how you should design:

• Tool names are semantic, not technical. A model reads get_pipeline_health_summary and immediately understands what intent it serves. It reads fetchPipelineData and has to infer from the description. Good names reduce ambiguity and therefore reduce wrong tool calls.
• Descriptions are instructions, not documentation. The model reads tool descriptions the way a new hire reads an onboarding doc, to understand when to use something, not just what it does. Weak descriptions lead to hallucinated tool parameters and unnecessary calls.
• Granularity is a design choice, not a default. REST naturally pushes you toward fine-grained, composable endpoints. MCP pushes you toward intent-sized operations, meaning tools that match what a user would naturally ask for in a single thought.

So design for what's on the other end: a reasoning system, mid-conversation, reaching for whatever vocabulary you handed it. Give it bad names and it reaches badly.

3. Building MCP as API (Integration & CRUD) vs. MCP Reality (Workflows)

Here's one capability, built two ways.

The API-shaped MCP server:

• list_pipelines() returns all pipelines
• get_pipeline(id) returns one pipeline by ID
• get_pipeline_runs(pipeline_id, limit) returns recent runs
• get_run_errors(run_id) returns errors for a run
• get_pipeline_config(pipeline_id) returns config

To answer "Why did the customer_orders pipeline fail last night?", the model must call all five tools in sequence. Each call waits for a response before the model can reason about the next step. Five round trips. Five latency hits. Five tool result injections into the context window.

The workflow-shaped MCP server:

• diagnose_pipeline_failure(pipeline_name, date) returns a structured summary: which run failed, what errors occurred, which config was active, and the last successful run for comparison.

One tool call. One round trip. The model gets everything it needs to compose a clear, accurate answer. The user gets a response in seconds instead of tens of seconds.

The API-shaped approach feels more composable and reusable, and it is, for a human developer writing code. The LLM isn't. It's improvising in real time, under token pressure, and every needless tool call is a tax on the answer, paid in latency and tokens.

4. MCP is User-Thought Design

The best mental model for designing MCP tools is this: map each tool to a complete user thought, not a data operation.

A user thought is the natural unit of intent in a conversation. "Show me what broke in production this morning." "Tell me which customers are at risk of churning." "What should I prioritize in the data backlog this week?" These are user thoughts. Each one is a single message that carries a complete intent.

When you design tools that map to user thoughts, several things happen automatically:

• Tool selection becomes obvious to the model. There is rarely ambiguity about which tool fits a given message when the tool was designed around that kind of message in the first place.
• Parameters map to what the user actually said. If the user says "last night", the tool accepts a natural date expression. If the user says "the orders pipeline", the tool accepts a pipeline name. You are not forcing the model to translate human language into system IDs.
• Error surfaces are meaningful. When a workflow-level tool fails, the error message can tell the model, and through it the user, something useful: "No runs found for that pipeline in the last 24 hours. Did you mean the orders_v2 pipeline?" A CRUD tool failure just says the record wasn't found.

User-thought design also forces you to talk to the people who will actually use the AI interface. What do they ask? What do they care about? What decisions do they make? Your tool inventory should read like a list of those questions, not a list of your database tables.

5. The Hidden Costs of Chatty MCP Design

Fine-grained MCP designs feel safe. Smaller tools are easier to test, easier to reason about, and easier to document. The cost isn't obvious until you're in production, and then it compounds.

Latency compounds multiplicatively.

• Each tool call involves a model inference step (deciding to call), a network round trip, and another inference step (reading the result). At 100–300ms per round trip plus inference overhead, five sequential tool calls can easily add 3–5 seconds to a response, all before the model writes a single word of its answer.

Token costs add up fast.

• Every tool result is injected into the context window. Five tool responses that each return 500 tokens of JSON add 2,500 tokens of input to every subsequent model call. With caching, the first call is expensive; with a long conversation, the cumulative cost is significant.

Reasoning quality degrades under cognitive load.

• When a model must orchestrate many fine-grained tools to answer a single question, it spends reasoning capacity on orchestration rather than on the actual answer. The more tool calls required, the more opportunities for a wrong parameter, a misread result, or an abandoned chain. Fewer, richer tools free the model to focus on what matters.

Debugging becomes harder.

• When something goes wrong in a five-step tool chain, it is genuinely hard to know whether the model made a bad decision, whether a tool returned bad data, or whether the sequence of calls was inherently ambiguous. Workflow-level tools fail at the right altitude, where the business logic lives.

None of this means you should never expose granular tools. There are cases, such as exploratory data analysis, debugging sessions, and power-user interfaces, where granular access is exactly right. The point is that granularity should be a deliberate choice based on the use case, not the default because it mirrors your API layer.

6. Principles for MCP Design

After building and auditing MCP servers across several production AI systems, these principles consistently separate the designs that work from the ones that look right on paper but fall apart in use.

Design at intent level, not data level.

• Start with the questions users will ask, not the tables in your database. Map tools to those questions. If you find yourself building a tool just to support another tool, that's a sign the parent tool should do more work server-side.

Write descriptions as decision guides, not API docs.

• Your tool description should answer: when should the model pick this tool over another one? Include the conditions under which this tool is appropriate. Call out what it does NOT do. If two tools are similar, explicitly distinguish them in both descriptions.

Accept human-language parameters where possible.

• Prefer pipeline_name: string over pipeline_id: uuid. Prefer date_range: "last 7 days" | "yesterday" | "this month" over raw timestamps. The model speaks the user's language, so your tool should meet it there, with the translation to system identifiers happening server-side.

Return structured, narrated results.

• A tool that returns raw JSON forces the model to parse and summarize. A tool that returns a structured summary with a brief prose explanation gives the model something it can quote directly. This reduces hallucination and shortens response generation time.

Use resources for stable context, tools for dynamic action.

• Schema definitions, team glossaries, and static configuration belong in MCP resources, since they load once and stay in context. Real-time queries, mutations, and state-dependent lookups belong in tools. Blurring this distinction leads to tools that always return the same thing (waste) or resources that go stale (bugs).

Limit your tool surface area ruthlessly.

• A large tool list increases the probability of the model choosing the wrong tool. For any given AI use case, aim for the minimum number of tools that can answer the full range of user intents. Add tools when you have evidence from real conversations that a gap exists, not as a precaution.

Validate with real conversation traces, not unit tests.

• Unit tests verify that your tool returns the right data when called with the right parameters. They don't verify that the model calls it correctly, interprets the result correctly, or uses it to compose a coherent answer. Log real conversations, trace tool call sequences, and identify where the model hesitates or calls the wrong thing. That is your real test suite.

MCP is still young. The ecosystem is moving fast, and best practices are being written by the teams building with it right now. But the teams that are getting it right share a common discipline: they never forget that the consumer of their MCP server is not a program. It is a model that is thinking out loud. Design for that, and everything else follows.

Team at Aptologics have extensive experience designing and deploying production AI systems, including MCP-powered data and analytics agents. Feel free to reach us on info@aptologics.com to explore how we can help you build AI experiences that actually work.