Opens in a new tabSkip to content
Agent LighthouseAgent Lighthouse

    Searches the text of every published page. The evidence sources themselves are not in this index — search all of them on the trusted sources page.

    GitHub ↗
    Browse checks and page contents
    agent-interfaces/mcp-registry-listing-ownership

    The MCP server is listed in the official registry under a namespace this domain owns

    What it checks

    Checks two things about the site’s MCP server. Whether it is discoverable in the official MCP Registry. And whether it is listed under the reverse-DNS namespace of the audited domain, which the registry grants only on proof of domain control. Together they distinguish a first-party listing from a third-party aggregator’s republish of the same server.

    The namespace match is the ownership signal. The registry checks the proof when the publisher logs in, by DNS TXT record or by HTTP file, and neither has to stay published. So the audit reports whether /.well-known/mcp-registry-auth is served, but a missing file never fails a listing. A file that is served but malformed is a warning.

    Why it matters

    The registry grants a com.example.* namespace only on proof of domain control, and the proof is externally observable: either an apex DNS TXT record of exact form v=MCPv1; k=ed25519; p=<base64> or a file at exactly /.well-known/mcp-registry-auth with the same payload. A listing under io.github.<user>/* is bound to an individual’s GitHub account, and a listing under an aggregator namespace (observed live in the registry as e.g. ai.smithery/<Org>-<repo> with remotes[].url pointing at server.smithery.ai) is bound to neither the brand nor its infrastructure — the brand cannot update or revoke it, and agents routed through it reach a proxy rather than the origin.

    The proof is checked at login, not on every read, so a listing in the domain’s namespace is itself the evidence that control was proved once. The falsifiable claim: a domain with no first-party registry entry is absent from the official index that downstream marketplaces and sub-registries pull from, so clients that read those catalogs never see the domain’s own server.

    Evidence

    • How to Authenticate When Publishing to the Official MCP Registry — Model Context Protocol (vendor-doc, verified 2026-10-17)
    • GitHub authentication binds a server name to io.github.<user or org>/*. Domain authentication binds it to com.example.*/*, the reverse-DNS form of the domain.
    • Domain control is proved by a DNS TXT record v=MCPv1; k=ed25519; p=<key>, or by the same payload served at https://<domain>/.well-known/mcp-registry-auth.
    • Both methods are checked when the publisher runs mcp-publisher login. The guide gives no step that keeps either proof published after login, so a domain that proved control by TXT alone serves no file and is still a legitimate owner.
    • The MCP Registry — Model Context Protocol (vendor-doc, verified 2026-10-17)
    • The official metadata repository for public MCP servers, backed by Anthropic, GitHub, PulseMCP and Microsoft. It offers “A REST API for MCP clients and aggregators to discover available servers”.
    • Namespace authentication “ensures that only the legitimate owner of a GitHub account or domain can publish servers under that namespace”.
    • Official MCP Registry API — Model Context Protocol (spec, verified 2026-10-17)
    • Public and unauthenticated. A search returns each listing’s name, remotes[].url, status and version, which is what the audit reads.

    Grade: B — the registry and its namespace rules are documented by the protocol’s maintainers, and the listing is directly observable. The registry is still in preview, and its documented consumers are aggregators rather than agents, so the grade is B rather than A.

    Limits

    The registry says it “is not intended to be directly consumed by host applications”. Agents reach it through downstream marketplaces and sub-registries, so a missing listing hides a server from those catalogs, not from an agent given the URL. The registry is labelled preview: “Breaking changes or data resets may occur before general availability.” The audit cannot see a DNS TXT proof, and it does not verify the registry’s signature over the entry. It trusts the registry’s namespace grant instead.

    How it scores

    Tier per evidence policy: scored — grade B meets the A/B bar required for scored audits.

    Example finding

    A B2B analytics vendor runs a solid MCP server at analytics.example.com/mcp. Searching the registry for ‘example.com’ returns exactly one match: ai.smithery/example-analytics, whose remotes[].url is server.smithery.ai/…/mcp and whose headers[] demand a Smithery API key. The vendor has no first-party listing, serves no /.well-known/mcp-registry-auth, and has no apex TXT proof. Agents resolving ‘the MCP server for example.com’ from the canonical registry are routed through a third party the vendor has no contractual relationship with, cannot revoke, and cannot update when the endpoint moves.

    Sources