Capability Listing

What a capability listing is

A capability listing is the server-side catalogue that tells an MCP client which tools, prompts, and resources are available to discover and use. It is not the work itself, but the advertised surface that governs what a client can even see.

In practice, that makes the listing part of the control plane for an MCP deployment. A client may treat the listing as authoritative for what can be invoked, so the listing becomes more than documentation when it drives automated discovery, selection, caching, and later calls.

Why capability listings matter in MCP

The key security property of a capability listing is that it shapes trust. If the list is incomplete, stale, or misleading, the client may miss valid capabilities, continue to rely on retired ones, or treat unintended options as available. That is why NIST Cybersecurity Framework 2.0 remains a useful lens for treating the listing as governed metadata rather than a casual response body.

A cacheable listing can also create a time gap between server state and client belief. If the server changes but a client keeps using an old listing, the mismatch can affect routing, authorization expectations, and operational reliability. In other words, the listing is a dependency that can outlive the configuration it describes.

How stale or poisoned listings affect behaviour

When a listing is stale, the client may continue to invoke capabilities that no longer exist or fail to discover newly added ones. When a listing is poisoned, the client may be steered toward capabilities, prompts, or resources that were not intended by the operator, which turns discovery metadata into an influence point for behaviour. That risk pattern is closely related to the control concerns covered by NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access control, configuration integrity, and auditability.

The practical issue is not only that a bad listing can mislead a user. In an automated client, the listing can affect programmatic decisions, so a corrupted view of available tools can cascade into downstream tool use, prompt selection, or resource access without an obvious human checkpoint.

Relationship to adjacent security controls

Capability listings sit near identity, authorization, and configuration management, but they are not the same thing as any one of them. They describe what is exposed for discovery, while the actual security outcome still depends on how the server validates access, enforces scope, and records use. For that reason, the listing should be treated as one input to policy, not as the policy itself.

This is also why API-style security thinking is often helpful. Even when the protocol is not a conventional REST API, the same design questions arise: what is discoverable, what is callable, what is obsolete, and what happens if the advertised surface is wrong. The OWASP API Security Top 10 is useful here as a parallel model for thinking about exposed interfaces, inconsistent inventory, and broken trust in what a client is told is available.

Risk and Threat Considerations

Capability listings create risk when clients rely on cached or unauthenticated metadata to decide what capabilities to use. A stale listing can preserve access to deprecated surfaces, while a poisoned listing can misdirect discovery toward unsafe or unintended capabilities.

Failure mechanism: The server or an intermediary supplies a listing that no longer matches the real set of capabilities, and the client continues to trust that metadata during discovery or invocation.

Impact: The client may miss required controls, invoke the wrong tool, or follow an attacker-influenced path that changes what the model can do or what resources it can reach.

Practitioner Guidance

Governance implication: Treat the capability listing as security-relevant configuration, not just protocol convenience. Operators should define who can publish it, how freshness is validated, and what changes trigger review because the listing can influence downstream behaviour even before any tool is called.

What to watch for: Pay close attention to cache behaviour, listing drift, and unexpected capability growth or disappearance. If the advertised set changes without a corresponding operational change record, the mismatch deserves the same attention you would give to any other authoritative control-plane metadata.

Related resources from NHI Mgmt Group

• Capability listing cache
• What is the difference between workspace allow-listing and least privilege in AI governance?
• How should security teams govern database listing access in PostgreSQL?
• How can teams tell whether a new platform capability is changing their risk posture?