MCP Server Discovery is the process of finding available Model Context Protocol servers that expose tools, resources, or prompts to an AI agent. It covers how an agent, client, or orchestrator locates endpoints, validates access, and determines what capabilities are available before making tool calls or exchanging context.
What MCP Server Discovery Really Means
MCP server discovery is more than locating an endpoint. It is the step where an agent or client determines which Model Context Protocol servers exist, what trust boundary each server sits behind, and whether the server should be considered usable before any tool call or context exchange happens. That makes discovery part of both capability management and access gating.
For a practical overview of how discovery, consent, allowlists and registry choices fit together, see Unsanctioned AI Agents and MCP Servers Guide.
Why Discovery Shapes the Agent’s Attack Surface
The discovery step decides what the agent can even see, so weaknesses here widen the attack surface before a single tool is invoked. If an unapproved server appears trusted, the agent may inherit unsafe tools, prompts, or resources; if a legitimate server is invisible, the system may drift toward shadow configurations and unsafe workarounds.
Discovery also matters because an MCP server is not just a name in a list. It can imply an authorization model, metadata endpoint, registry entry, or local configuration source that the client uses to decide whether the server is real, current, and safe to contact. When those signals are inconsistent, users and orchestration layers can be misled into connecting to the wrong service.
How Discovery Relates to Validation and Capability Selection
Discovery is the point where capability claims should be treated as provisional, not assumed. A robust flow checks provenance, configuration source, and access conditions before the agent relies on declared tools or resources, especially when multiple servers advertise similar functions. That is why discovery and trust assessment belong together, not as separate afterthoughts.
For the underlying MCP security model, including authorization, token handling and protected resource metadata, Model Context Protocol: Authorization specification is the primary reference. For the IETF metadata mechanism many MCP servers use during discovery, RFC 9728: OAuth 2.0 Protected Resource Metadata explains the discovery fields that support that trust decision.
Governance, Trust, and Operational Control for MCP Servers
In practice, discovery is where governance becomes enforceable. Organisations need to know whether servers are coming from a registry, a private allowlist, a local configuration file, or some other source of truth, because each path creates a different trust expectation and different failure mode. Discovery without policy can turn into silent expansion of tool access.
For operational control over approved servers, registry usage and server publication rules, MCP Gateway and MCP Server Governance Guide and MCP Registry and Server Publishing Security Guide are the most relevant internal references. If discovery is happening through local desktop configuration or developer tooling, Local MCP Server Security Guide is the best companion for the trust and consent model.
Risk and Threat Considerations
Discovery becomes risky when a client trusts a server too early, or trusts the wrong source of discovery metadata. That can expose the agent to rogue servers, shadow deployments, malicious tool definitions, and consent manipulation, especially when discovery and authorization are loosely coupled.
Failure mechanism: An attacker or unsafe integration can get a server listed, referenced, or auto-resolved in a way that makes the client believe it is approved, then use that trust to influence tool selection, capture context, or redirect credentials and requests.
Impact: The result can be tool misuse, prompt or context exposure, unauthorized capability use, and broader compromise of the agent’s execution path, especially if the discovered server is able to participate in token handling or downstream requests.
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 addresses 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 | Discovery determines which tools an agent can reach. |
| ASI03 — Identity & Privilege Abuse | Discovery can expose or elevate server capabilities available to an agent. | |
| ASI10 — Rogue Agents | Unapproved MCP discovery can surface rogue or unsanctioned agent infrastructure. | |
| Recommendation — Restrict discovered tools to approved servers and verify tool provenance before use. Enforce least-privilege access to discovered servers and their capabilities. Block unapproved servers and require allowlisted discovery sources. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Discovery must only surface servers the client is allowed to access. |
| IA-5 — Authenticator Management | Discovery often leads to token and credential use for server access. | |
| AU-2 — Event Logging | Discovery events should be logged for later review and anomaly detection. | |
| Recommendation — Enforce access decisions at discovery time and reject unapproved endpoints. Manage and rotate authenticators used when discovered servers require access. Log server discovery, approval, and connection events for review. | ||
Practitioner Guidance
What to watch for: Treat discovery as a controlled intake process, not a convenience feature. The important question is not just whether a server exists, but whether its source, authority, and declared capabilities match the organisation’s approved trust model.
Practitioner takeaway: If discovery is not governed, the agent will often inherit a larger and less predictable tool surface than the organisation intended.
Related resources from NHI Mgmt Group
- What breaks when MCP server discovery is missing from security controls?
- How should organisations govern MCP server discovery in developer tools?
- Who should be accountable for AI discovery and MCP server risk decisions?
- What should organisations do when discovery finds an unapproved MCP server or local model runtime?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org