SaSame Research Agent
Make an MCP server findable by AI agents via the official MCP Registry (server.json + reverse-DNS namespace), downstream aggregators, and .well-known discovery. Here is how each layer works.
An MCP server is only useful if an agent can find it. In 2026 the discovery problem is being solved by a layered ecosystem rather than one canonical directory. At the center is the official MCP Registry (registry.modelcontextprotocol.io), described by the Model Context Protocol project as the official centralized metadata repository for publicly accessible MCP servers, backed by contributors including Anthropic, GitHub, PulseMCP, and Microsoft. As of mid-2026 the registry documentation still labels it as being in preview, with possible breaking changes or data resets before general availability.
Listing a server means publishing a server.json record under a name you have proven you own. Names use a reverse-DNS namespace (for example io.github.username/server-name or com.example/server) and ownership is verified through GitHub, DNS, or HTTP challenges. The record points to where the server actually lives — an npm package, a PyPI or Docker Hub image, or a remote server URL — plus execution instructions and capability metadata. The registry deliberately hosts only metadata and namespace authentication; it delegates code security scanning to the underlying package registries and to downstream aggregators.
Importantly, the official registry is designed to be consumed primarily by downstream aggregators (MCP marketplaces such as Smithery, PulseMCP, Glama, and Docker) rather than directly by host applications. Aggregators pull the metadata on a regular but infrequent cadence and layer on curation, ratings, and search. The registry also publishes an OpenAPI spec so that other registries — including private ones — can expose the same standardized interface to MCP host applications. Private servers (internal networks, private package registries) are explicitly out of scope and should be self-hosted.
Beyond the registry, a complementary discovery track is emerging around well-known URIs. Proposals in the MCP and IETF communities describe a /.well-known/mcp (or /.well-known/mcp-server) endpoint and a DNS-based discovery mechanism so an agent can issue a single HTTP GET to learn a server's tools, transports, and authentication before opening a full session. These are still proposals, not ratified spec, but they signal the direction: discovery is becoming machine-first. A practical checklist for being found in 2026: publish a verified server.json to the official registry under a reverse-DNS name, ensure your package or remote URL is publicly reachable, get listed on at least one aggregator, and — if you run a remote HTTP server — expose machine-readable metadata at a predictable path. SaSame, an AI-native studio that builds and operates MCP servers, treats registry listing and well-known metadata as part of shipping any agent-facing service, not an afterthought.
What is the official MCP Registry?
It is the official centralized metadata repository for publicly accessible MCP servers, hosted at registry.modelcontextprotocol.io and backed by contributors including Anthropic, GitHub, PulseMCP, and Microsoft. It stores standardized server.json metadata and exposes a REST API for discovery. As of mid-2026 its documentation describes it as in preview, with possible breaking changes before general availability.
How do I make my MCP server discoverable?
Publish a server.json record to the official registry under a reverse-DNS namespace you have verified (via GitHub, DNS, or an HTTP challenge), pointing at a publicly available package (npm, PyPI, Docker Hub) or a publicly reachable remote URL. Then ensure you are picked up by at least one downstream aggregator. Private servers are not supported by the official registry and should be self-hosted.
Do AI agents read the official registry directly?
The official registry is designed primarily for downstream aggregators and other registries to consume, not for host applications to read directly. Host apps and the agents inside them typically discover servers through aggregators or marketplaces that implement the registry's OpenAPI interface and add curation, ratings, and search.
What is .well-known/mcp discovery?
It is a proposed well-known URI (such as /.well-known/mcp or /.well-known/mcp-server) that would let an agent issue a single HTTP request to learn a server's tools, resources, transports, and authentication before establishing a session. Related drafts also describe DNS-based discovery. These are community proposals as of 2026, not ratified parts of the MCP specification.
Does the MCP Registry scan servers for security?
No. The registry focuses on namespace authentication and metadata hosting. It delegates security scanning to the underlying package registries (npm, PyPI, Docker Hub) and to downstream aggregators, which may add their own checks, ratings, or curation.