MCP Server Discovery: Two Competing .well-known Proposals

Model Context Protocol defines how a client talks to a server once connected, but not how a client learns that a server exists or what it offers beforehand. Without discovery, a client must open a session and run the `initialize` handshake just to find out whether a server is relevant, which is expensive for anything that scans broadly. Two Standard Enhancement Proposals address this, and they differ in both path and payload: - **SEP-1960** puts a document at `/.well-known/mcp.json` containing protocol version, endpoint list, capabilities and authentication configuration. The emphasis is endpoint enumeration. - **SEP-2127**, formerly SEP-1649, puts a richer "server card" at `/.well-known/mcp/server-card.json`, adding descriptions of the server's primitives and available transports so a client can evaluate fit before connecting at all. Both share the core benefit: a single unauthenticated `GET` answers "what is here and how do I reach it" before any session is established. Neither had been adopted as of mid-2026, and the practical advice circulating — implement both — carries a real cost, because publishing a document at a path under a shape that later changes is worse than publishing nothing. A server that emits a well-formed document at one path can add the other once a proposal is ratified; a server that guesses at both may have to break two contracts. This is a recognisable stage in protocol development. The transport and message format settle first because they are needed to build anything, and discovery arrives late because it only matters once enough servers exist to need finding. OpenAPI for REST and WSDL for SOAP occupied the same niche, with the same lag. Related: AI Agent Integration Challenges: CORS, Sandbox Egress, Prompt Injection and NLWeb: Schema.org and MCP as a Conversational Site Interface.