Resource Discovery

What Resource Discovery Means in MCP

Resource discovery is the step where an AI model learns what tools, data sources, and capabilities are available from a connected service before it tries to use them. In Model Context Protocol, that discovery phase makes the model’s behaviour more predictable, but it also means the service must carefully control what is exposed and to whom.

In practice, discovery is not the same as execution. A model can only act safely if the service presents a trustworthy view of its available functions, because overbroad discovery can unintentionally advertise sensitive capabilities, internal endpoints, or data-bearing operations that were never meant for broad use.

Why Discovery Matters for Control and Trust

Discovery is a control point because it shapes what the model believes it can request. If the discovery surface is too generous, the model may attempt actions that exceed the user’s intended scope, or it may learn about capabilities that should remain hidden behind stricter authorization checks.

That makes discovery part of the trust boundary, not just a convenience feature. A well-designed discovery process should help the model find only the resources it is entitled to know about, while preserving the service’s ability to separate public capability from privileged capability.

When discovery is carefully scoped, it improves consistency across model interactions. When it is not, it can blur the line between visibility and permission, which is why MCP deployments need to treat resource advertisement and authorization as linked design choices.

How Resource Discovery Is Commonly Implemented

Resource discovery is usually handled through a service-defined description of available tools, schemas, or endpoints. The model or client can then inspect that description before selecting an action. In a healthy design, the discovery layer is descriptive, not permissive: it explains what exists without automatically granting the right to use it.

That separation is important because not every discoverable capability should be callable by every requester. Services often need to expose different resources to different users, environments, or trust levels, and the discovery response should reflect those limits rather than flatten them.

For MCP specifically, the discovery process should be consistent with the server’s authorization model and token audience rules. The discovery output should not become a side channel for revealing more than the caller is supposed to know.

Security Implications of Overexposed Discovery

Overexposed discovery can create information disclosure, privilege escalation opportunities, and confusing tool selection. If a model learns about hidden or highly sensitive capabilities, that knowledge can expand the attack surface even before any action is taken.

Discovery also becomes risky when it is not tightly tied to authorization boundaries. A service that advertises too much can encourage unsafe assumptions about what is allowed, especially when the model treats discoverable functions as broadly usable rather than context-limited.

Strong discovery design therefore helps reduce accidental misuse, supports least privilege, and narrows what an attacker or malformed prompt can infer about the environment.

Practitioner Guidance

Why practitioners should care: Treat discovery as a security control, not a purely informational feature. If the model can only see a reduced, role-appropriate set of tools and data sources, it is less likely to reason toward unsafe or out-of-scope actions.

What to watch for: Review whether your discovery surface changes appropriately by user, session, tenant, or environment, and whether it ever reveals sensitive capabilities that the caller should only learn about after stronger authorization succeeds.

Practitioner takeaway: The safest MCP designs make discovery useful enough for correct tool selection, but narrow enough that visibility never outruns permission.

Related resources from NHI Mgmt Group

• What breaks when resource discovery is routed through a management proxy?
• What is the difference between resource discovery and code-to-resource mapping in Terraform operations?
• How should security teams implement OAuth protected resource metadata in a way that supports dynamic discovery without weakening trust boundaries?
• Why does delegated CloudControl access increase the risk of resource discovery?