One of the most common mistakes I see in early MCP server design is also the most understandable. A team has an existing API, they want their agents to use it, and the fastest path forward is to wrap each endpoint as an MCP tool. The OpenAPI spec generates the manifest, the SDK does the work, and within an afternoon there's a working server. The problem doesn't show up until that server gets connected to a real agent alongside two or three others — and the agent starts making worse decisions than it did with a single tool.
In this article, we'll walk through why API-mirrored MCP servers degrade agent performance, what well-scoped tool design looks like, and how to audit what you've already deployed. We'll close on how Connect AI's Workspaces and Toolkits implement these principles directly.
How MCP tools end up in the context window
The mechanics are straightforward, but the implications take some unpacking. When an agent connects to an MCP server, the server publishes its full tool manifest—every tool name, description, and parameter schema—and that manifest is injected into the LLM's context window before the agent processes a single user message. The model reads all of it on every request, not just on initial discovery, which makes the manifest a fixed overhead on every turn.
The token math compounds quickly. A single well-described tool typically consumes 200–600 tokens once you account for the name, description, and parameter schema. Five MCP servers with 30 tools each puts 150 tools into context, and at those rates tool metadata alone can consume 25–30% of a 200k-token context window before any user message, task history, or retrieved data enters the picture.
The enforcement signals from major AI clients reflect this. Cursor caps MCP tools at 40. GitHub Copilot hard-limits at 128. Those thresholds reflect measured performance degradation past those points. The portion of an agent's available context consumed by tool definitions rather than task-relevant information is a context window tax, and it scales linearly with every tool added to the server.
The API-mirroring trap
When developers build MCP servers by mapping API endpoints directly to tools, they reproduce the API's structure and its verbosity inside the LLM's context. A CRM with 40 REST endpoints becomes 40 MCP tools. Fine-grained CRUD operations compound this: create_account, update_account, delete_account, get_account, and search_account become five tools where a well-designed server might need one. The interface that was useful for a REST client gets reproduced verbatim for a reasoning model that has very different ergonomics.
The reason this happens is structural. Auto-generated MCP servers from OpenAPI specs or SDK wrappers take the path of least resistance: one endpoint, one tool. That's fast to ship and easy to maintain, and for a single-source agent it can even appear to work. The mismatch only surfaces when multiple sources get composed together. An agent accessing Salesforce, Jira, and Snowflake through three API-mirrored servers can easily inherit 100–200 tools before any task-specific context is loaded, and at that point most of its reasoning budget goes to evaluating which of those hundred-plus tools might apply.
The framing API architects have started using is the right one: MCP tools should be designed the way you'd design experience APIs, where multi-step, fine-grained operations are hidden behind a single capability-shaped interface. An MCP tool should resemble what the agent is trying to accomplish, not what the underlying API method happens to be called.
What tool bloat does to agent performance
The downstream effects extend well beyond token consumption. LLMs distribute attention across all content in the context window, so a large toolset spreads the model's attention across many options — increasing the probability of selecting the wrong tool, invoking a tool with hallucinated parameters, or misinterpreting a tool's output. Tool-calling accuracy declines measurably once the count climbs past even a modest number of poorly scoped choices.
In practice, this surfaces as three failure modes. Wrong-tool selection: the agent picks a similar-sounding but incorrect tool: get_contact when the task called for get_account. Incorrect parameterization: the agent fills required parameters with plausible but wrong values, often because parameter schemas across many tools start to blur together. Context displacement: task-critical information gets crowded out by tool definitions and the agent loses the thread of what the user actually asked for.
There's also a cost dimension that doesn't get enough attention. Every tool description injected into context adds tokens to every request in the session, which makes tool exposure a recurring inference cost rather than a one-time overhead. The Amazon Prime Video engineering team published a useful validation point here: after reducing tool exposure from hundreds of options down to three or four context-appropriate tools per task, they reported measurable improvements in agent accuracy and a noticeable reduction in hallucinations.
What well-designed MCP tool architecture looks like
The core principle is short enough to fit in one sentence: an MCP server should expose capabilities, not API endpoints. The design question shifts from “what does this API call do?” to “what task does the agent need to accomplish?” That reframing changes both the shape and the count of the tools that get built.
Three properties define a well-scoped MCP tool. It should be task-oriented, named in terms of what the agent is trying to do rather than the underlying API method. It should be broadly applicable, working across multiple objects or entities where possible to keep total tool count low. And it should be scoped to a use case, with the set of tools exposed matching the agent workflow rather than the full capability surface of the source system.
Use-case scoping is where most teams find the biggest gains. A customer success agent needs account, ticket, and contract data; a finance agent needs GL entries, invoices, and budget data. Those agents shouldn't share a single bloated server. Each agent should connect to one scoped precisely to its task. Practitioners generally recommend staying under 10–15 active tools per agent, and that threshold becomes much easier to hit when scope is the design constraint rather than an afterthought.
Auditing your current MCP server design
A useful first step is a tool inventory. List every tool exposed to each agent, count the total, and calculate the approximate token overhead. If the count exceeds 15–20 tools for any single agent, that server is a candidate for redesign, not as a hard rule, but as a strong signal that the design is mirroring an API surface rather than serving an agent workflow.
From there, four diagnostic questions help separate noise from signal. Are any tools duplicates of the same operation on different objects, like get_account, get_contact, and get_lead as separate tools? Are any tools exposed that no current workflow uses? Are tools named in API terms rather than task terms? Does the agent have access to data sources it will never query? Each “yes” represents context paid for and not used.
The architectural fix is to group by use case rather than by source system. Instead of a “Salesforce MCP server” exposing all Salesforce capabilities to all agents, build a “pipeline management server” with only the objects relevant to pipeline review, and a separate “customer health server” with only the objects relevant to CS workflows. The performance benefit is the obvious one, but there's a governance benefit underneath it: scoped servers enforce least-privilege access at the agent level, which reduces the blast radius if an agent is manipulated or makes an error.
How Connect AI implements this with Universal Tools and Toolkits
This is the architecture we built Connect AI around. Rather than generating one MCP tool per endpoint per source, Connect AI exposes a fixed set of Universal Tools — getCatalogs, getSchemas, getTables, getColumns, queryData, getProcedures, and executeProcedure — that work uniformly across all hundreds of connected sources. An agent that has learned the Universal Tool set for one source knows how to interact with any source, and the tool surface stays at a constant seven regardless of how many systems are wired up underneath.
Workspaces handle the scoping. Administrators define a Workspace as a scoped data catalog, a bundle of specific tables, views, and derived views organized by business function. A Workspace named “Customer Success” might contain only the Salesforce account tables, Zendesk ticket views, and contract data a CS agent needs. The Workspace becomes the unit of least-privilege data access, defined once and reused across however many agents share that scope.
Toolkits handle which tools are available within a given Workspace. A read-only reporting agent might get a Toolkit with getSchemas, getTables, getColumns, and queryData; a write-capable operations agent gets additional tools layered on. Each Workspace + Toolkit combination deploys as a dedicated MCP server endpoint automatically, with no additional infrastructure to stand up.
The result is that administrators deploy purpose-built MCP servers—each with a minimal tool surface, scoped data access, and a dedicated endpoint—matched to the agents using them. Context stays lean, agent accuracy stays high, and the connectivity layer underneath remains a single managed platform rather than a sprawl of bespoke servers.
Frequently asked questions
Why does tool count affect LLM accuracy so much?
LLMs attend to everything in their context window when deciding what to do next, so a large toolset forces the model to evaluate many options at once. That increases the chance it picks a similar-sounding but wrong tool, hallucinates a parameter, or loses focus on the task. The effect is measurable even in models with large context windows.
What's the difference between Universal Tools and Custom Tools in Connect AI?
Universal Tools are Connect AI's standard operations — getCatalogs, getSchemas, getTables, getColumns, queryData, and stored procedure execution—and they work the same way across all 350+ connected sources. Custom Tools are administrator-defined operations for specific workflows: pre-baked queries, field-level access limits, or named business operations. Both compose into a Toolkit and deploy as a scoped MCP server.
Does deploying multiple scoped MCP servers create operational complexity?
Each Workspace + Toolkit combination generates a dedicated endpoint automatically, so the configuration work is bounded. The alternative (one large server serving all agents) trades operational simplicity for compounding performance and accuracy costs at scale.
What tool count should I target per agent?
Most practitioners recommend staying under 15. Connect AI's Universal Tools give you a full data-access surface in seven, which keeps most agent configurations well under that threshold even after adding workflow-specific Custom Tools.
Build scoped MCP servers with Connect AI
CData Connect AI's Workspaces and Toolkits let you build purpose-scoped MCP servers from hundreds of enterprise sources, each deployed as a dedicated endpoint, carrying only the tools and data access your agents actually need. Start a free trial of CData Connect AI and give your agents a connectivity layer matched to the way they reason.
Your enterprise data, finally AI-ready.
Connect AI gives your AI assistants and agents live, governed access to hundreds of enterprise systems — so they can reason over your actual business data, not just what they were trained on.
