Discovery in the Model Context Protocol

See also

Sources

1. 1
   Independent commentary published 2026-09-03 describes server/discover as the mechanism by which clients may learn a server's supported protocol versions and capabilities, states that calling it is not mandatory for clients, and describes no other in-protocol discovery mechanism.field report

   MCP 2026 changes the rules · article body · Checked 2026-09-16
2. 2
   The architecture guide states that servers advertise their capabilities in response to server/discover, which clients may call before any other request for up-front capability discovery, while clients include their own capabilities in per-request _meta.

   Architecture · Capability Negotiation · Checked 2026-09-16
3. 3
   For authorization server metadata MCP uses the default oauth-authorization-server well-known suffix from RFC 8414 and defines no application-specific suffix, and clients MUST try the endpoints in a fixed priority order: RFC 8414 with path insertion, then OpenID Connect discovery with path insertion, then OpenID Connect path appending for issuer URLs that have path components.

   Authorization Server Discovery · Authorization Server Metadata Discovery · Checked 2026-09-16
4. 4
   After retrieving authorization server metadata the client MUST verify that the issuer value in the document is identical to the issuer identifier used to construct the well-known URL, and MUST NOT use the metadata if they differ.

   Authorization Server Discovery · Authorization Server Metadata Discovery · Checked 2026-09-16
5. 5
   MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728) to indicate authorization server locations, and the metadata document MUST include authorization_servers with at least one authorization server.

   Authorization Server Discovery · Authorization Server Location · Checked 2026-09-16
6. 6
   MCP servers MUST implement one of two authorization-location mechanisms, the resource_metadata URL in a WWW-Authenticate header on 401 or a well-known URI, and clients MUST support both and MUST use the header URL when it is present, otherwise falling back to the well-known URIs in the specified order.

   Authorization Server Discovery · Protected Resource Metadata Discovery Requirements · Checked 2026-09-16
7. 7
   A cached response is identified by the request method together with the parameters that affect the result, and clients MUST NOT serve a cached response for a request whose method or parameters differ; results produced through the multi round-trip retry mechanism MUST NOT be cached.

   Model Context Protocol specification 2026-07-28, Caching · Cache Key · Checked 2026-09-16
8. 8
   A cacheScope of public means any client, shared gateway or caching proxy MAY store and serve the response to any user, and the spec warns that a public result from an authenticated endpoint may be shared outside the initial authorization context with different access tokens.

   Model Context Protocol specification 2026-07-28, Caching · Cache Scope Field; Security Considerations · Checked 2026-09-16
9. 9
   If ttlMs is absent clients SHOULD assume 0 (immediately stale), negative values SHOULD be ignored and treated as 0, servers MUST provide ttlMs >= 0, and TTL is a freshness hint rather than a guarantee.

   Model Context Protocol specification 2026-07-28, Caching · Time-to-Live (TTL) Field · Checked 2026-09-16
10. 10
    Calling server/discover is optional for clients: a client may invoke any RPC inline and handle UnsupportedProtocolVersionError if the server does not support the requested version.

    Model Context Protocol specification 2026-07-28, Discovery · When to Call · Checked 2026-09-16
11. 11
    On UnsupportedProtocolVersionError the client SHOULD select a mutually supported version from the supported list and retry the request, or surface an error to the user if no compatible version exists.

    Model Context Protocol specification 2026-07-28, Versioning and Compatibility · Protocol Version Negotiation · Checked 2026-09-16
12. 12
    Because legacy clients have no fall-forward mechanism, a server that must keep existing initialize-based integrations working while adopting 2026-07-28 has to be dual-era rather than modern-only, and it may serve both eras concurrently on one endpoint.inferred

    Model Context Protocol specification 2026-07-28, Versioning and Compatibility · Compatibility Matrix; Backward Compatibility with Initialization-Based Versions · Checked 2026-09-16
13. 13
    A dual-era server selects its behaviour from how the client opens: a request carrying modern per-request _meta is served statelessly under this revision, while an initialize request selects legacy semantics scoped to the stdio process or the HTTP session, and the server MAY serve both eras concurrently on the same endpoint or process.

    Model Context Protocol specification 2026-07-28, Versioning and Compatibility · Backward Compatibility with Initialization-Based Versions (dual-era server bullets) · Checked 2026-09-16
14. 14
    The era determination is a property of the server rather than of an individual request; clients SHOULD cache it for the lifetime of the stdio process or the HTTP origin and MAY persist it across restarts of the same server configuration, re-probing if the cached assumption later fails.

    Model Context Protocol specification 2026-07-28, Versioning and Compatibility · Backward Compatibility with Initialization-Based Versions · Checked 2026-09-16
15. 15
    MCP partitions the JSON-RPC server-error range so that -32000 to -32019 is legacy and MUST NOT receive new allocations while -32020 to -32099 is reserved for the specification and implementations MUST NOT emit undefined codes from it.

    Overview (base protocol) · Error Codes · Checked 2026-09-16
16. 16
    The stdio fallback MUST NOT be keyed to one specific error code, because legacy servers respond to unknown pre-initialize requests with implementation-defined errors (commonly -32601 or -32602) or not at all.

    stdio · Backward Compatibility · Checked 2026-09-16
17. 17
    On 400 Bad Request a dual-era client SHOULD inspect the response body before falling back, because modern servers also use 400 for UnsupportedProtocolVersionError, MissingRequiredClientCapabilityError and header-validation failures; a recognized modern JSON-RPC error means retry or correct rather than fall back, while an empty or unrecognized body means fall back to initialize.

    Model Context Protocol specification 2026-07-28, Streamable HTTP · Backward Compatibility · Checked 2026-09-16
18. 18
    Every POST to the MCP endpoint MUST include an MCP-Protocol-Version header whose value matches io.modelcontextprotocol/protocolVersion in the body _meta, and a mismatch MUST be rejected with 400 Bad Request and a HeaderMismatch error.

    Model Context Protocol specification 2026-07-28, Streamable HTTP · Request Metadata - Protocol Version Header · Checked 2026-09-16
19. 19
    If the server does not implement the requested RPC method it MUST respond with 404 Not Found and a JSON-RPC error with code -32601 (Method not found), and the JSON-RPC body is what distinguishes that from a legacy HTTP+SSE server that does not host the modern MCP endpoint.

    Model Context Protocol specification 2026-07-28, Streamable HTTP · Request Metadata - Protocol Version Header · Checked 2026-09-16
20. 20
    On Streamable HTTP an unsupported protocol version MUST be answered with 400 Bad Request carrying an UnsupportedProtocolVersionError that lists the supported versions.

    Model Context Protocol specification 2026-07-28, Streamable HTTP · Request Metadata - Protocol Version Header · Checked 2026-09-16
21. 21
    The 2026-07-28 revision removes the initialize and notifications/initialized handshake so that every request carries its protocol version and client capabilities in _meta.

    Model Context Protocol specification 2026-07-28, Key Changes · Major changes (item 2) · Checked 2026-09-16
22. 22
    The compatibility matrix records that a legacy client against a modern server fails with no fall-forward mechanism: on stdio the server rejects initialize with an implementation-defined JSON-RPC error, and on HTTP the request is rejected with 400 Bad Request because required headers are missing.

    Model Context Protocol specification 2026-07-28, Versioning and Compatibility · Compatibility Matrix (Legacy client / Modern server row) · Checked 2026-09-16
23. 23
    The compatibility matrix records that a modern client against a legacy server fails: the server may reject the request with an implementation-defined error, stay silent, or even process an era-ambiguous method under legacy semantics.

    Model Context Protocol specification 2026-07-28, Versioning and Compatibility · Compatibility Matrix (Modern client / Legacy server row) · Checked 2026-09-16
24. 24
    io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities are required on every client request, clientInfo is optional though clients SHOULD include it, and a request missing a required field is malformed and MUST be rejected with -32602 (or 400 Bad Request on HTTP).

    Overview (base protocol) · _meta - Per-request protocol fields · Checked 2026-09-16
25. 25
    If processing a request requires a client capability the client did not declare, the server MUST return MissingRequiredClientCapabilityError with code -32021 and data.requiredCapabilities listing the missing capabilities, or 400 Bad Request on HTTP.

    Overview (base protocol) · _meta - Per-request protocol fields · Checked 2026-09-16
26. 26
    A server that supports only modern versions SHOULD name the protocol versions it supports in any error it returns to an initialize request, on any transport, because legacy clients have no fall-forward mechanism and that message may be the only diagnostic they can surface to users.

    Model Context Protocol specification 2026-07-28, Versioning and Compatibility · Backward Compatibility with Initialization-Based Versions · Checked 2026-09-16
27. 27
    There is no version negotiation handshake in 2026-07-28: every request carries its protocol version and the server accepts or rejects each request independently.

    Model Context Protocol specification 2026-07-28, Versioning and Compatibility · Versioning and Compatibility (introduction); Protocol Version Negotiation · Checked 2026-09-16
28. 28
    Probing with server/discover is RECOMMENDED even for a client that supports only modern versions, because some legacy servers do not validate that a request arrives after initialize and would process an era-ambiguous method such as tools/call under legacy semantics.

    stdio · Backward Compatibility · Checked 2026-09-16
29. 29
    The registry layer and the in-protocol discovery layer answer different questions and neither substitutes for the other: the registry tells a host where servers are and how to launch or reach them, while server/discover tells a client what an already-addressed server supports and which protocol versions it speaks.inferred

    The MCP Registry · Relationship with MCP Host Applications; compared against the specification Discovery page · Checked 2026-09-16
30. 30
    The registry REST API base URL is https://registry.modelcontextprotocol.io and exposes GET /v0.1/servers, GET /v0.1/servers/{serverName}/versions and GET /v0.1/servers/{serverName}/versions/{version}, with the special version latest and cursor-based pagination via limit and cursor plus updated_since filtering in RFC 3339 format.

    MCP Registry Aggregators · Consuming the MCP Registry REST API; Pagination; Filtering Since · Checked 2026-09-16
31. 31
    The MCP Registry is not intended to be directly consumed by host applications; hosts should consume other registries such as downstream marketplaces via a REST API conforming to the official registry's OpenAPI spec.

    The MCP Registry · Relationship with MCP Host Applications · Checked 2026-09-16
32. 32
    The MCP Registry does not support private servers and recommends that organisations wanting private servers host their own private MCP registry.

    The MCP Registry · Relationship with Server Developers · Checked 2026-09-16
33. 33
    The MCP Registry is the official centralised metadata repository for publicly accessible MCP servers, and it provides a REST API for MCP clients and aggregators to discover available servers.

    The MCP Registry · The MCP Registry (introductory list) · Checked 2026-09-16
34. 34
    Registry metadata is stored in a server.json format containing the server's unique reverse-DNS name, where to locate the server (for example an npm package name or a remote server URL), execution instructions and other discovery data such as description and capabilities.

    The MCP Registry · The MCP Registry (server.json bullet list) · Checked 2026-09-16
35. 35
    An aggregator that also implements the registry OpenAPI spec acts as a subregistry, and the spec allows it to inject custom metadata under vendor-prefixed keys inside the _meta field, for example user ratings, download counts and security scan results.

    MCP Registry Aggregators · Acting as a Subregistry · Checked 2026-09-16
36. 36
    A server/discover request carries no body parameters beyond the standard _meta object.

    Model Context Protocol specification 2026-07-28, Discovery · Request · Checked 2026-09-16
37. 37
    The worked server/discover request example carries _meta keys io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientInfo and io.modelcontextprotocol/clientCapabilities.

    Model Context Protocol specification 2026-07-28, Discovery · Request (JSON example) · Checked 2026-09-16
38. 38
    server/discover results are cacheable: servers MUST include ttlMs and cacheScope on a complete DiscoverResult, and interim input_required results carry no caching hints.

    Model Context Protocol specification 2026-07-28, Caching · Cacheable Results · Checked 2026-09-16
39. 39
    DiscoverResult.capabilities reports the capability families the server supports (tools, resources, prompts and so on) rather than an enumeration of individual tools.

    Model Context Protocol specification 2026-07-28, Discovery · Data Types - DiscoverResult (capabilities bullet) · Checked 2026-09-16
40. 40
    DiscoverResult includes an optional instructions field carrying natural-language guidance for LLMs on how to use the server effectively.

    Model Context Protocol specification 2026-07-28, Discovery · Data Types - DiscoverResult (instructions bullet) · Checked 2026-09-16
41. 41
    DiscoverResult carries the server's identity in _meta under io.modelcontextprotocol/serverInfo with a name and version, and servers SHOULD include this field.

    Model Context Protocol specification 2026-07-28, Discovery · Data Types - DiscoverResult (serverInfo bullet) · Checked 2026-09-16
42. 42
    DiscoverResult.supportedVersions lists the protocol versions the server supports, and the client should choose one of them for subsequent requests.

    Model Context Protocol specification 2026-07-28, Discovery · Data Types - DiscoverResult · Checked 2026-09-16
43. 43
    Because serverInfo is unverified and the protocol supplies no integrity binding for a discovery result, an enterprise cannot use server-reported identity as the basis for approving which tools an agent may call, and must bind approval to something it verified itself such as the endpoint origin, a registry record or an administrator decision.inferred

    Model Context Protocol specification 2026-07-28, Discovery · Data Types (Note below DiscoverResult) · Checked 2026-09-16
44. 44
    The 2026-07-28 revision defines a server/discover RPC that lets a client query a server's supported protocol versions, capabilities and identity before sending any other request.

    Model Context Protocol specification 2026-07-28, Discovery · Discovery (opening paragraph) · Checked 2026-09-16
45. 45
    serverInfo is self-reported by the server and is not verified by the protocol; clients SHOULD NOT use it to change their behaviour and SHOULD NOT rely on it for security decisions.

    Model Context Protocol specification 2026-07-28, Discovery · Data Types (Note below DiscoverResult) · Checked 2026-09-16
46. 46
    Servers MUST implement server/discover under the 2026-07-28 revision, making it the revision's mandatory-to-implement but optional-to-call RPC.

    Model Context Protocol specification 2026-07-28, Discovery · Discovery (opening paragraph) · Checked 2026-09-16
47. 47
    Clients discover skills with skills/list, which supports pagination and caching, retrieve entries with skills/get, and read skill files with resources/read; a skill's identity is the originating server's identity together with the skill URI and hosts MUST preserve both in registries, approvals and caches.

    Skills · Listing Skills; Getting a Skill; Reading Skill Content · Checked 2026-09-16
48. 48
    Servers that support the Skills extension MUST declare both the resources capability and the io.modelcontextprotocol/skills extension in server/discover, and servers that declare the extension MUST implement skills/list and skills/get.

    Skills · Capabilities · Checked 2026-09-16
49. 49
    For a skill with a manifest, hosts MUST restrict file reads to URIs in the retained manifest, verify each file's byte size and SHA-256 digest before use, and obtain fresh approval when a file is changed, added or removed.

    Skills · Integrity and Verification · Checked 2026-09-16
50. 50
    The security best practices page names OAuth metadata discovery as an SSRF surface: during discovery an MCP client fetches the resource_metadata URL from the WWW-Authenticate header, the authorization_servers URLs from the protected resource metadata document, and the token_endpoint and authorization_endpoint URLs from authorization server metadata, all of which a malicious MCP server can populate to point at internal resources.

    Model Context Protocol specification 2026-07-28, Security Best Practices · Server-Side Request Forgery (SSRF) - Attack Description · Checked 2026-09-16
51. 51
    Mitigations specified for discovery-path SSRF include requiring HTTPS except for loopback, blocking private and reserved IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16, fc00::/7, fe80::/10), validating redirect targets, and routing discovery fetches through an egress proxy.

    Model Context Protocol specification 2026-07-28, Security Best Practices · Server-Side Request Forgery (SSRF) - Mitigation · Checked 2026-09-16
52. 52
    Because MCP is stateless and has no protocol-level sessions, servers that need state mint explicit handles, and servers implementing authorization MUST verify all inbound requests and MUST NOT treat possession of a state handle as authentication.

    Model Context Protocol specification 2026-07-28, Security Best Practices · State Handle Hijacking · Checked 2026-09-16
53. 53
    The stdio probe has three outcomes: a DiscoverResult means the server is modern; a recognized modern JSON-RPC error means the server is modern but does not support the requested version, so the client uses an advertised version and does not fall back to initialize; any other error or no response within a reasonable timeout means the server is legacy and the client falls back to initialize.

    stdio · Backward Compatibility · Checked 2026-09-16
54. 54
    A documented use of server/discover is as a stdio backward-compatibility probe, because on stdio there is no per-request HTTP status code to drive fallback; a client supporting both modern and legacy servers SHOULD send server/discover first.

    Model Context Protocol specification 2026-07-28, Discovery · When to Call - stdio backward-compatibility probe · Checked 2026-09-16
55. 55
    The specification defines modern (revision 2026-07-28 and later, version and capabilities conveyed as per-request metadata), legacy (2025-11-25 and earlier, session established by an initialize handshake) and dual-era (an implementation supporting both) as its interoperability vocabulary.

    Model Context Protocol specification 2026-07-28, Versioning and Compatibility · Terminology · Checked 2026-09-16
56. 56
    UnsupportedProtocolVersion carries JSON-RPC error code -32022.

    Overview (base protocol) · Error Codes (table) · Checked 2026-09-16
57. 57
    If the server does not implement the requested version it MUST respond with UnsupportedProtocolVersionError listing the versions it does support in data.supported alongside data.requested.

    Model Context Protocol specification 2026-07-28, Versioning and Compatibility · Protocol Version Negotiation · Checked 2026-09-16
58. 58
    In Webex the set of actions discoverable by an agent is scoped by the chosen server, the user's permissions, granted scopes, organisation settings and tool-specific controls, and administrators can review authentication, enable or block access, select allowed tools and inspect schemas.

    AI in Webex Overview · Discovery mechanisms (agentic apps as governance and discovery layer) · Checked 2026-09-16
59. 59
    In the Webex agentic model an external agent acts as the MCP client, connects to a Webex MCP server, discovers approved tools and then uses them against Webex services as the authenticated user.

    AI in Webex Overview · Discovery mechanisms (tool discovery by MCP clients) · Checked 2026-09-16
60. 60
    The Webex App Hub badge set includes ciscoOfficial, ciscoOnboarded, partnerOnboarded, developerOnboarded and federatedThroughRegistry, and applications imported from an external registry without manual review fall under federatedThroughRegistry, which is not a direct Cisco certification.

    Submit to App Hub and Badging · Certification badges · Checked 2026-09-16

Documents

Cite this page

WarmTransfer. (2026, September 16). Discovery in the Model Context Protocol. WarmTransfer. https://warmtransfer.net/knowledge/mcp-discovery

@misc{warmtransfer-mcp-discovery,
  title  = {Discovery in the Model Context Protocol},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/mcp-discovery},
  note   = {Verified 2026-09-16}
}