Security teams should avoid exposing the model to every tool in every connected server. A better pattern is to filter tool metadata to the few tools relevant to the task, then route calls through a shared optimization layer. This reduces context size, improves tool selection, and lowers the chance of hallucinated tool calls in multi-server MCP environments.
Why This Matters for Security Teams
When an AI assistant connects to many MCP servers, token waste is more than a cost issue. Every unnecessary tool descriptor increases prompt size, raises selection error rates, and broadens the blast radius if the assistant calls the wrong function. In MCP-heavy environments, the practical goal is not to expose every available capability, but to present only the tools that are relevant to the task and its trust boundary.
This is consistent with the direction of OWASP Agentic AI Top 10, which treats uncontrolled tool exposure as an operational risk, not just a usability issue. NHI Management Group has also documented how protocol-level sprawl turns into credential exposure, including the Guide to the Secret Sprawl Challenge and Analysis of Claude Code Security, both of which show that AI-connected workflows create new secret and tool sprawl faster than teams usually anticipate.
Current research also shows how quickly MCP ecosystems accumulate exposure: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to the State of MCP Server Security 2025. In practice, many security teams encounter token waste only after assistants start calling irrelevant tools, consuming context budget, and surfacing unexpected data paths in production.
How It Works in Practice
The most effective pattern is to treat tool discovery as a scoped retrieval problem, not a full inventory problem. Instead of passing every server’s entire tool catalog into the model, place a filtering layer in front of MCP that selects a small, task-specific subset based on intent, user role, environment, and policy. That keeps the context window smaller and makes tool choice more accurate.
A common implementation looks like this:
- Classify the request by intent before tool discovery begins.
- Map that intent to an approved server set and an approved tool set.
- Strip unused parameters, descriptions, and redundant metadata from the prompt.
- Route execution through a shared optimization layer that can cache, deduplicate, and normalize tool schemas.
- Log both the original tool universe and the filtered set for audit and tuning.
This approach aligns with the least-privilege direction in NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially where access scoping and system resource control matter. It also matches NHI guidance in the Secret Sprawl Challenge, where the key lesson is that reducing exposed surface area is often more effective than trying to manage every exposed credential or tool later.
For multi-server deployments, the optimization layer should also normalize naming collisions, remove duplicate tools across servers, and suppress tools that are technically available but irrelevant for the current business workflow. That reduces hallucinated calls because the model sees fewer near-equivalent options and has less room to guess. These controls tend to break down when teams expose raw server catalogs directly to the assistant, because large, overlapping tool sets create ambiguity that the model cannot resolve reliably.
Common Variations and Edge Cases
Tighter tool filtering often increases integration overhead, requiring teams to balance lower token usage against the cost of maintaining intent maps and policy rules. Best practice is evolving, and there is no universal standard for how aggressive filtering should be across all MCP environments.
Some teams prefer static allowlists, but that can become brittle when tasks vary widely. Others use dynamic, context-aware selection that refreshes per request, which is usually more efficient but requires stronger policy checks and better telemetry. The right answer often depends on whether the assistant is serving a narrow workflow, such as ticket triage, or a broad workflow that spans many systems and users.
Where there are many servers with overlapping functions, it is often better to hide server boundaries from the model and expose a synthesized capability layer instead. That reduces token waste and prevents the assistant from learning a noisy, low-value tool universe. In high-change environments, teams should also revisit tool metadata regularly, because stale descriptions can be just as harmful as excess descriptions. NHI Management Group’s research on OWASP Agentic Applications Top 10 and Vercel Context.ai OAuth Supply Chain Breach both show that uncontrolled surface area creates avoidable exposure long before a direct compromise occurs.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | T2 | Limits tool exposure and reduces agent misuse risk in MCP environments. |
| CSA MAESTRO | GOV-3 | Supports runtime governance over agent tool access and execution paths. |
| NIST AI RMF | Addresses governance and measurement of AI system behavior and risk. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access scoping maps directly to selective tool exposure. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers overexposed identities and secrets in multi-server integrations. |
Define oversight metrics for tool selection quality, context size, and failure rates.
Related resources from NHI Mgmt Group
- How should security teams govern MCP servers used by AI coding assistants?
- How should security teams monitor AI agents and MCP servers in production?
- How can security teams reduce the blast radius of AI agents using MCP?
- How should security teams implement AI security testing when agents, tools, and MCP servers are changing quickly?
