Too many MCP tools push agent selection accuracy past the cliff

At a glance

What this is: This analysis argues that MCP agents become less reliable when too many tools are exposed at once, with the selection cliff appearing around 40 tools in a single context.

Why it matters: For IAM, NHI, and agentic AI teams, the issue is not just usability but governance, because overexposed tool manifests widen access scope and increase the chance of the wrong action being taken.

Context

MCP tool exposure is not just an interface design problem. It is a governance problem because every additional tool expands the decision space an AI agent must evaluate before acting, and that affects both reliability and control. In practice, large manifests make the agent less precise even when the underlying model is capable.

The article focuses on a familiar failure mode in agentic systems: the surface grows faster than the control model around it. That matters for teams designing MCP security guide-style deployments, because tool inventory, scoping, and exposure limits are part of the security boundary, not just the developer experience.

Key questions

Q: What breaks when agents are given too many MCP tools at once?

A: Agents can lose the ability to choose the right tool cleanly, especially when tool definitions, parameters, and response formats all enter the prompt at once. The result is context pressure, more invocation errors, and more retries, which makes both execution quality and governance visibility worse. The practical fix is to reduce default tool exposure and load capabilities only when they are relevant.

Q: Why does tool sprawl increase operational risk for agentic systems?

A: Because every extra tool increases the number of actions the model can plausibly take, and that expands both error rates and the blast radius of a mistaken choice. When multiple tools overlap, the agent may execute the wrong action confidently, which is harder to detect than a hard failure. That makes tool inventory and scoping governance controls, not just engineering preferences.

Q: How can security teams reduce MCP tool-selection errors?

A: Start by narrowing what the agent can see. Split broad assistants into role-specific agents, clean up overlapping descriptions, and move rarely used tools behind a search step so the model only evaluates a short list at decision time. Those changes reduce confusion at the source and improve selection accuracy without relying on a better model.

Q: Should organisations use search-and-run instead of exposing every tool directly?

A: Yes, when the catalog is large or the tools are unevenly used. Search-and-run is better for long-tail capability because it keeps the default context small and reveals only the relevant tools at the moment of need. That improves accuracy, limits unnecessary exposure, and gives teams a cleaner way to govern what an agent can reach.

Technical breakdown

Why large MCP manifests degrade tool selection

Tool selection is a classification problem, and the prompt carries every candidate into the model's working context. As the number of tools rises, descriptions compete for attention, overlap becomes more common, and the model increasingly picks by name resemblance instead of intent fit. The failure is not that the model cannot reason at all. It is that the signal-to-noise ratio falls until the right choice is no longer the most visible one.

Practical implication: Treat tool count as a control variable, not a convenience metric, and cap the number of tools visible to any one agent at a manageable threshold.

How role-scoped and identity-scoped tool surfaces reduce risk

A smaller manifest is not just easier for the model to use. It is also a stronger authorization pattern. Role-scoped agents only see the tools relevant to a function, while identity-scoped tools change exposure based on who is asking. That means the same assistant does not present the same action surface to every user, which reduces both confusion and over-privilege. The architecture is closer to least privilege for agent tooling than to a shared catalog. See the Agentic AI Identity Guide.

Practical implication: Apply role and user scoping before the model sees the manifest so the tool list reflects necessity, not ambient availability.

Why search-and-run beats list-everything for long-tail tools

Search-and-run changes the problem from choosing among hundreds of tools to choosing among a small, relevant subset generated on demand. The agent first searches for intent, then inspects only the closest matches, then executes one selected tool. That keeps the prompt smaller, reduces overlap, and prevents the long tail from polluting every interaction. It is a structural fix, not a prompt tweak, because the model only sees what it needs at the moment it needs it.

Practical implication: Move seldom-used tools behind a retrieval layer so the agent searches for them instead of carrying the entire catalog in context.

NHI Mgmt Group analysis

Tool sprawl is becoming an identity and authorization problem, not just an LLM quality problem. Once an agent can see dozens of tools, the question is no longer whether the model is smart enough, but whether the environment has exposed more capability than any one task should require. That is an NHI governance issue because each tool is effectively an action-bearing identity surface. Teams should treat manifest size as a privilege boundary, not a convenience setting.

Agent reliability degrades in the same way human decision-making degrades under interface overload. The article's strongest point is that the failure is structural: tool descriptions overlap, labels blur, and the model starts choosing by superficial similarity. That creates a new governance debt for agentic AI programmes, where more integration can reduce rather than increase effective control. The remedy is to design narrower, task-scoped surfaces from the start.

Search-and-run is the right control pattern for large tool estates. Exposing every MCP tool up front forces the model to carry the cost of the full catalog on every request, while search-and-run pays that cost only when a tool is actually relevant. That makes the pattern more defensible for large environments and easier to govern through inventory, filtering, and scoped exposure. In practice, agentic application risks are easier to manage when the agent sees less, not more.

Identity scoping should be built into tool delivery, not bolted on after deployment. The article shows that who the user is should shape which tools the agent can even consider. That is a direct fit for modern NHI and agentic AI programmes, where delegation without exposure control creates unnecessary blast radius. Teams should move from static manifests to policy-shaped tool surfaces that change with role and context.

The real architectural lesson is that model upgrades cannot substitute for access design. The article notes that the curve moves with model quality, but it never disappears. That means governance must focus on reducing ambient tool availability, sharpening descriptions, and separating hot-path actions from long-tail capabilities. Practitioners should expect the next reliability gain to come from access architecture, not from hoping the model becomes omniscient.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Tool surface management will become a standard control for agentic programmes. As MCP estates grow, teams will need to govern not just which tools exist, but which tools are visible to which agents at which time. That pushes identity-aware authorization closer to the runtime layer and makes manifest design part of the security architecture.

Agent reliability will increasingly depend on exposure discipline, not model size alone. The practical lesson is that better models may widen the safe operating range, but they will not eliminate the need for scoping, filtering, and curated tool surfaces. Programmes that keep adding integrations without a selection strategy will accumulate avoidable failure modes.

For practitioners

• Cap the number of tools in any one agent context Set a hard threshold for visible tools per agent and treat large manifests as a design defect, not an acceptable default.
• Split broad agents by role and task Break general-purpose assistants into narrower agents so each one sees only the tools needed for its job, such as support, finance, or engineering.
• Rewrite tool descriptions for disambiguation Remove near-duplicate language from tool names and descriptions so the model can distinguish similar actions without guessing.
• Move the long tail behind search-and-run Keep the most-used tools in the manifest and expose rarer tools through a search step so they are not always present in context.
• Scope tool exposure by user identity Filter available tools by user role before the agent receives the manifest so the action surface matches the user's legitimate need.

Key takeaways

• Too many MCP tools create a selection problem that looks like model weakness but is usually a manifest design issue.
• The operational breakpoint arrives earlier than most teams expect, so tool count and description quality need active governance.
• Role-scoped access and search-based discovery are the most practical ways to keep agent behaviour reliable as tool estates expand.

Related NHI Mgmt Group resources: MCP Security Guide · Agentic AI Identity Guide · OWASP Agentic Applications Top 10 · AI Agent Identity Security Buyer's Guide

Key terms

• MCP tool surface: The MCP tool surface is the set of tools, actions, and data endpoints exposed to an AI agent through Model Context Protocol. It defines what the agent can call, read, or invoke. Security teams treat it as a control boundary for authorization, logging, least privilege, and abuse prevention.
• Tool Selection Accuracy: Tool selection accuracy measures whether an agent chooses the right tool for a given task, not merely whether the tool responds successfully. It is a governance signal because repeated wrong-tool choices can create cost, security, and compliance problems even when the end output appears acceptable.
• Search-and-Run Pattern: An access pattern in which an agent searches for relevant tools first, then executes only a small set of candidates. It reduces prompt bloat and improves governance by keeping long-tail capabilities out of the default context.
• Identity-Scoped Tools: Tools whose visibility depends on the user's role, identity, or authorization context. This reduces unnecessary exposure and helps ensure the agent only considers actions the user is legitimately allowed to request.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and workload identity. It helps practitioners design access and lifecycle controls for the systems that now issue and consume credentials.