tools/listTools
Returns tool names, descriptions, and input schemas. A later tools/call request invokes a selected operation.
Protocol guide
MCP tool discovery within and across servers
MCP defines how a client discovers primitives exposed by a server it already knows. Production tool discovery becomes a broader problem when the correct server is not installed, multiple providers expose similar tools, or current eligibility matters.
Native discovery
What MCP discovers on a connected server
After initialization and capability negotiation, a client uses list methods to inspect the primitives that the server currently exposes. Listing and execution remain separate calls.
resources/listResources
Returns discoverable resource descriptors. Templates add parameterized resource locations without executing a tool.
prompts/listPrompts
Returns reusable prompt templates the server exposes. These are a distinct primitive, not executable provider capabilities.
Discovery layers
A server list, a registry, and a router answer different questions
Collapsing the layers encourages agents to treat publication as approval or a semantic match as permission. Keep each receipt explicit.
Connected server
Question: what primitives does this configured server expose now? Evidence: initialization response and current list output.
Public registry
Question: what server metadata has a namespace owner published? Evidence: registry record, package or remote endpoint, version, and namespace verification.
Capability router
Question: which currently eligible connection best fits this bounded intent? Evidence: definition, policy, health, behavior, and observed outcomes.
Selection contract
Inspect more than the tool name
Semantic relevance narrows candidates. It does not prove that a tool is callable, current, allowed, or likely to return the evidence the task requires.
Definition
Match the capability type and inspect the exact input schema, description, protocol, and version.
Constraint
Apply risk class, read/write boundary, citation requirement, latency budget, tenant policy, and credential mode.
Evidence
Check provider attestation separately from independent behavior review, definition drift, and current health.
Outcome
Prefer candidates whose comparable attempts produced valid results; retain unresolved when evidence is insufficient.
Failure modes
Common discovery mistakes
These mistakes occur before the provider tool runs. A transport can be healthy while selection is still wrong.
Registry presence is not eligibility
Namespace verification helps attribute a publication. It is not a behavior review, security certification, uptime promise, or ResolveMesh approval.
Descriptions are untrusted input
A provider-authored name or description can be incomplete, ambiguous, stale, or adversarial. Validate definitions before they affect routing.
Discovery is not execution
Finding a candidate does not authorize a tool call. The client still applies credentials, consent, arguments, and result validation.
Primary sources
References
The protocol and Registry claims below come from the current Model Context Protocol project documentation and terms.
MCP architecture overview
Primary protocol reference for initialization, capability discovery, tools/list, and dynamic list-change notifications.
Read the primary sourceThe Official MCP Registry
Primary reference for the Registry's metadata role, namespace verification, downstream aggregators, and trust boundaries.
Read the primary sourceOfficial MCP Registry terms
Current terms governing Registry data and the claims downstream services may make about their relationship to it.
Read the primary source