Without curation, tool surfaces become too large to reason about, too inconsistent to secure, and too messy to operate. Tool definitions balloon, selection accuracy drops, and context is consumed before the model can act. In practice, teams lose control over what each agent can see and use, which turns integration sprawl into a governance problem.
Why uncured MCP tool growth stops being tractable
Model Context Protocol works well when the tool surface is deliberately bounded. Once the tool catalog grows faster than the team can curate it, the problem stops being “add another integration” and becomes control-plane debt. The surface is no longer small enough for humans or agents to reason about consistently, which means every new tool adds not just capability, but ambiguity, operational overhead, and security review burden.
A curated MCP surface gives you a narrow set of tools with predictable names, inputs, outputs, and trust assumptions. An uncured surface does the opposite: similar tools accumulate, overlapping capabilities appear, and the model has to choose from too many near-equivalent options. That increases the chance of tool selection errors, contradictory behaviors across agents, and brittle downstream automation that only works when the right tool happens to be chosen.
Tool growth also changes the governance shape of the system. At small scale, owners can answer who may call what, under which conditions, and with which credentials. At larger scale, that answer becomes fuzzy unless there is explicit curation, versioning, and deprecation discipline. The operational issue is not just count, it is whether the tool surface still has a stable mental model and a reliable ownership boundary.
Why larger tool surfaces degrade security and model performance
Security and utility degrade together when the tool list expands without review. More tools mean more schema variance, more authentication paths, more trust boundaries, and more opportunities for weakly reviewed functionality to be exposed to the model. That widens the attack surface and also makes it harder for the model to use the remaining tools correctly, because the context budget is consumed by tool metadata before the agent can act.
That is why curated tool design is a practical security control, not just a cleanliness preference. A smaller, intentional tool set reduces confusion, limits the blast radius of a mistaken invocation, and makes it easier to detect when a tool is behaving outside its intended role. For MCP specifically, the authorization model only stays meaningful when the tool catalog is bounded enough that access decisions map cleanly to actual usage patterns, which is why the Model Context Protocol: Authorization specification matters as the surface scales.
It also matters because tool sprawl can hide privilege creep. If the model can see too many tools, or too many versions of the same tool, teams often respond by granting broad access to keep workflows moving. That is usually the moment when least-privilege design starts to fail in practice: the system becomes harder to secure precisely because the interface layer is no longer curated enough to support fine-grained control.
What teams should do before the tool catalog becomes unmanageable
The right response is to curate the surface as a product, not as an afterthought. Every MCP tool should have a clear owner, a narrow purpose, a documented trust level, and a review path for changes and retirement. If two tools do the same job, consolidate them. If a tool is rarely used, expensive to reason about, or difficult to secure, remove or isolate it rather than leaving it in the general pool.
Practically, that means treating tool addition as a governed decision with explicit acceptance criteria: does the tool add distinct value, can the model select it reliably, can the team secure it, and can operators explain why it exists? The best signal of a healthy MCP surface is not raw capability count, but whether the current tool set is still understandable at a glance and still supports predictable agent behavior.
When the tool surface is already noisy, the first remediation step is not more model tuning, it is reduction. Remove duplicates, retire stale tools, standardise naming and schema patterns, and separate experimental integrations from production ones. If the answer to “what can this agent do?” requires a long catalog walkthrough, the surface has already outgrown curation.
Risk and Threat Considerations
Uncurated MCP tool growth creates a compound risk: the system becomes easier to misuse, harder to govern, and more attractive to attackers who benefit from confusion at the trust boundary. The more tools are exposed, the more likely one of them has weaker validation, overly broad permissions, or a surprising side effect that an agent can trigger accidentally or maliciously.
Failure mechanism: Tool sprawl expands the attack surface, weakens selection reliability, and encourages broad access patterns that obscure which actions are actually permitted. Once teams lose the ability to reason about the tool set, they also lose the ability to spot unsafe overlap, excessive privilege, and hidden dependencies before they are exploited.
Impact: The practical result is governance drift, greater likelihood of mis-execution, and a higher chance that a compromised or confused agent will invoke the wrong capability with real operational consequences. Over time, the environment becomes harder to audit, harder to contain, and easier to abuse through the very integrations that were meant to increase productivity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Uncurated MCP tools increase misuse and wrong-tool selection risk. |
| ASI03 — Identity & Privilege Abuse | Tool sprawl often expands permissions and obscures what agents may use. | |
| ASI08 — Cascading Failures | Large tool surfaces create brittle dependencies and cross-tool failure chains. | |
| Recommendation — Restrict agent tool exposure and remove overlapping tools to reduce misuse. Constrain agent privileges to the smallest curated tool set. Partition agent tools to limit cascading impact from one bad integration. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Tool surfaces need inventory and deprecation discipline to stay governable. |
| Recommendation — Maintain a current inventory and retire stale interfaces promptly. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | A growing MCP surface needs an accurate inventory to remain understandable and controllable. |
| Recommendation — Inventory all active tools and decommission unused entries. | ||
Practitioner Guidance
What to prioritise: Curate the tool catalog before you optimise prompts or agent policies. If the surface is already large, reduce and consolidate first, because selection quality and security both depend on a manageable set of tools.
What to verify: Every production tool should have a named owner, an explicit purpose, and a removal or review date. If a team cannot explain why a tool still exists, it is probably already a governance liability.
What good looks like: The agent sees a small, distinct, well-labelled set of tools with limited overlap, and operators can explain access boundaries without consulting a sprawling registry.
Practitioner takeaway: MCP becomes hard to secure when the tool layer stops being curated enough for humans to understand and agents to choose from reliably; control the surface area, or the surface area will control the risk.
Related resources from NHI Mgmt Group
- What breaks when MCP tool definitions change without re-approval?
- What breaks when MCP tool listings are available without authentication?
- What breaks when shadow MCP servers are allowed into agent workflows without review?
- What breaks when sensitive data is allowed to flow from Zapier MCP into an AI model without inspection?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
