enable MCP server authors to publish io.modelcontextprotocol.server atproto records

[zzstoatzz]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

this registry is centralized, a big old postgres db if im not mistaken

the mcp-publisher CLI could make it easy for MCP server authors to publish MCP server metadata as ATProto records to their own PDSs (i.e. MCP server 1:1 with atproto record). this would allow for MCP authors (i.e. @thedsp.bsky.social) to meaningfully and verifiably own their MCP server implementations, without trusting a centralized registry.

in my naive estimation, you've already done the hard part, which is agree on a JSON schema that each record of an MCP server needs to satisfy, which is called a lexicon in atproto-speak

for example, this is what i had (naively) as an MCP server record when i explored this idea a while ago

{
  "name": "street-map-generator",
  "$type": "app.mcp.server",
  "tools": [
    "plot_street_map_from_address",
    "plot_street_map_from_coordinates"
  ],
  "version": "0.0.1",
  "language": "python",
  "createdAt": "2025-03-09T14:59:43.066538",
  "publisher": {
    "did": "did:plc:xbtmt2zjwlrfegqvch7fboei",
    "handle": "alternatebuild.dev",
    "verifiedDomain": "alternatebuild.dev"
  },
  "description": null,
  "installation": "uv run https://raw.githubusercontent.com/zzstoatzz/maps/refs/heads/main/main.py",
  "lastRegisteredAt": "2025-03-09T14:59:43.758398"
}

here's the actual record on my PDS. its associated with my domain alternatebuild.dev, which is the human-readable identifier that uniquely identifies me, the same way that anthropic.com uniquely identifies anthropic (but can be changed)

this schema is flawed in at least one way, primarily because the NSID doesn't correspond to a domain i own (i.e. mcp.app). it's likely that the "minimum viable schema" that satisfies both your JSON schema and that of a valid atproto record is not very different at all from your current JSON schema. (i would need to refresh myself on this) maybe just adding $type?

since (i assume) modelcontextprotocol.io is the domain that corresponds most closely to a governing identity for the protocol, an NSID grammar might be io.modelcontextprotocol.*

so then, the revised schema might be

{
  "name": "street-map-generator",
  "$type": "io.modelcontextprotocol.server",
  "tools": [
    "plot_street_map_from_address",
    "plot_street_map_from_coordinates"
  ],
  "version": "0.0.1",
  "language": "python",
  "createdAt": "2025-03-09T14:59:43.066538",
  "publisher": {
    "did": "did:plc:xbtmt2zjwlrfegqvch7fboei",
    "handle": "alternatebuild.dev",
    "verifiedDomain": "alternatebuild.dev"
  },
  "description": null,
  "installation": "uv run https://raw.githubusercontent.com/zzstoatzz/maps/refs/heads/main/main.py",
  "lastRegisteredAt": "2025-03-09T14:59:43.758398"
}

(still there are likely issues with the schema here, e.g. its missing resources and prompts, or instead should not have any knowledge of tools/resources/prompts)

imagine an opt-in extension of your mcp-publisher CLI, which can discover the publishers handle (e.g. @anthropic.com) and app password (or a dev token backed by full oauth via confidential clients) if set as env vars, and simply create the io.modelcontextprotocol.server record around the same time the publish to your managed API happens

this would:

• allow MCP server authors to display their official MCP server offerings without relying on a central registry
• open the door for publishers to build public reputation via attestations from other verifiable identities, without relying on a specific platform's concept of the publisher's identity
• offer a distribution mechanism for MCP servers (the protocol itself)

your centralized registry could remain a convenient, optimized index for all publishers everywhere (those who publish atproto records to their PDS or not) for example, using tap to sync all the io.modelcontextprotocol.* records to your postgres DB and offer a nice API/UI on top of your global index (though i suppose you wouldn't even have to run tap, since you'd already have a practical source of truth in your db, but if your db exploded, you could use tap to rehydrate the registry for those who were publishing atproto records)

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[zzstoatzz]

related inspiration: https://atcr.io/

[zzstoatzz]

https://bsky.app/profile/baileytownsend.dev/post/3mdnt57rds22u