The tool discovery surface is the set of names, descriptions, and capabilities exposed before a client invokes a tool. In MCP, this surface can leak sensitive context or invite prompt injection, so it must be governed as part of access control rather than treated as harmless metadata.
What the tool discovery surface is
The tool discovery surface is the pre-invocation layer that tells a client what tools exist, how they are described, and what capabilities they appear to offer. In MCP-style systems, that surface is not just convenience metadata, it is part of the trust boundary that shapes what the client can learn and attempt next.
Because discovery happens before a tool is actually called, it can reveal enough context to change user behaviour, client routing, or an attacker’s next move. A description that is too detailed can expose internal workflows, naming conventions, system relationships, or sensitive operational cues that were never meant to be public.
Why the discovery layer matters for authorization
Discovery should be treated as an authorization-adjacent control surface, not as harmless catalog text. If a client can enumerate tools freely, then the names and descriptions become part of the access decision environment, especially when the discovery output hints at privileged functions, admin actions, or sensitive data paths.
This is where access control must account for both the existence of a tool and the information needed to find it. A client that sees a tool named for a sensitive function may not yet be authorized to use it, but it may still learn enough to target social engineering, prompt injection, or misuse of adjacent capabilities.
For that reason, discovery design should follow the same discipline used for other access-bearing metadata: expose only what is needed for legitimate use, keep descriptions bounded, and avoid capability overstatement that makes a tool look broader than it should be.
How exposure becomes abuse
The main failure mode is information leakage through names, summaries, examples, and capability labels. Even without direct execution, discovery can reveal privileged terminology, hidden workflows, environment names, or task chains that help an attacker craft a prompt injection or a targeted misuse path. See RFC 9728: OAuth 2.0 Protected Resource Metadata for a standards-based example of how metadata can support authorization discovery when it is deliberately published and constrained.
Another failure mode is capability inflation, where a tool description implies a safe, narrow function but the actual tool reaches much further. That mismatch can lead a client, user, or downstream agent to overtrust the tool and chain it into workflows it should not influence. The risk is not just misuse of a single tool, but the compounding effect of discovery that encourages broader and less defensive automation.
How to think about it in MCP and agentic systems
In MCP and similar agentic environments, discovery is part of the control plane for delegated action. If tool metadata can leak sensitive context or be manipulated through prompt injection, then the problem is not only tool invocation, it is the trust placed in the discovery process itself. The discovery surface should therefore be reviewed alongside tool authorization, description hygiene, and client-side filtering.
For teams building or evaluating these systems, the practical question is whether the discovery surface is revealing only what a legitimate client needs to route a request, or whether it is also revealing operational detail that enlarges the attack surface. That distinction is central to secure tool governance, especially where tools bridge into privileged data, internal APIs, or high-impact actions. The OWASP Non-Human Identity Top 10 is also useful here because tool exposure often travels with credentialed machine access and over-privileged automation.
Risk and Threat Considerations
The discovery surface can become an attacker’s reconnaissance layer. If tool names and descriptions expose sensitive context, they can help an adversary identify high-value actions, map internal business logic, or craft prompt injection that steers a client toward unsafe tool use.
Failure mechanism: Overly descriptive or unfiltered discovery metadata leaks enough context to weaken authorization boundaries and to make tool-targeted abuse easier.
Impact: Sensitive operations may be easier to find, easier to target, and easier to chain into broader compromise, especially when discovery is consumed by autonomous or semi-autonomous clients.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity 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 API Security Top 10 | API8 — Security Misconfiguration | Tool discovery metadata exposed by an API-like surface can disclose unsafe capabilities. |
| Recommendation — Minimise exposed discovery metadata and validate that published tool descriptions do not leak sensitive context. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Discovery must be constrained so tool information exposure follows enforced access rules. |
| AC-6 — Least Privilege | Discovery should disclose only the minimum metadata needed for legitimate tool use. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Tool discovery and subsequent use benefit from auditability when metadata or routing decisions are abused. | |
| Recommendation — Enforce access checks on tool discovery and reveal only the metadata each requester is entitled to see. Apply least privilege to discovery metadata and suppress unnecessary capability detail. Log discovery access and review unusual tool enumeration or metadata-driven misuse patterns. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Discovery often advertises tools that non-human clients may reach with excessive authority. |
| Recommendation — Reduce tool exposure and confirm that non-human clients cannot discover or reach overprivileged actions. | ||
Practitioner Guidance
Governance implication: Treat discovery output as controlled security metadata, not as documentation text. Limit descriptions to the minimum needed for correct use, and review tool naming, summaries, and examples with the same care used for privileged endpoints or access-bearing APIs.
What to watch for: Watch for discovery entries that reveal internal system names, environment details, privileged actions, or instructions that make unsafe chaining easy. If a tool description helps a client decide how to use the tool, it can also help an attacker decide how to abuse it.
Related resources from NHI Mgmt Group
- When should organizations consider adopting advanced tool discovery for AI agents?
- How should security teams handle tool discovery for AI agents in MCP environments?
- When does app discovery automation become a governance control instead of a reporting tool?
- When does crawl-based discovery fail to find the attack surface?