Feature · SEP-1649

DNS for MCP tools.

Drop a .well-known/mcp.json file at any domain. MCPOrbit reads it and indexes every MCP server published there — no manual registration, no centralised directory, no curation gatekeeper.

Read the spec →

First MCP manager to ship·Spec-aligned·Free

How it works

From a JSON file at a known path to every server you publish — in one step.

The publisher drops a single JSON file at https://yourdomain.com/.well-known/mcp.json. The file lists each MCP server they expose: name, transport, command or URL, capabilities, description.

The consumer points MCPOrbit at the domain. MCPOrbit fetches the card, validates it, and surfaces every listed server in the registry browser as installable connections. No README, no gist, no Discord channel, no central directory.

Publish: one JSON file at a known path
Discover: paste the domain into MCPOrbit; every server appears

Why this matters

The first decentralised discovery layer for MCP.

Every other MCP discovery model today runs through a registry — a curated central list, with an approval bottleneck. Server Cards inverts that. Anyone running a domain can publish, anyone running MCPOrbit can discover, and the network effect lives in the open web instead of in a database.

No approval queue
No centralised directory
No vendor lock
Works for private internal MCP servers behind a VPN

What's in the file

A tiny JSON file. That's the whole spec.

Each server entry lists name, transport (stdio or streamable-http), URL or command, capabilities, and a description. Everything else is optional. The card is human-readable on purpose.

.well-known/mcp.json

1{
2  "version": "1.0",
3  "owner": {
4    "name": "Acme Inc",
5    "url": "https://acme.example"
6  },
7  "servers": [
8    {
9      "name": "linear-mcp",
10      "transport": "stdio",
11      "command": "npx",
12      "args": ["-y", "@acme/linear-mcp"],
13      "description": "Linear issues, projects, and cycles."
14    },
15    {
16      "name": "db-mcp",
17      "transport": "streamable-http",
18      "url": "https://mcp.acme.example/db",
19      "description": "Read-only Postgres queries against analytics db."
20    },
21    {
22      "name": "analytics-mcp",
23      "transport": "streamable-http",
24      "url": "https://mcp.acme.example/analytics",
25      "description": "Run named reports; never raw SQL."
26    }
27  ]
28}

Two angles

Use it from the publisher side or the consumer side.

Server author

Add a single JSON file to your domain. Your users install MCPOrbit, paste your URL, and see every server you publish. No README copy-paste. No Discord link to a config gist.

Consumer

Point MCPOrbit at any domain that publishes a card and pull every server from it. Build a private internal directory by pointing at your own company domain.

Server Cards FAQ

Where can I read the spec?

SEP-1649 in the official specification repo. We link to the open PR above; once it merges, we'll point at the merged page.

Does my server have to be public on the internet?

No. The card can sit on any domain MCPOrbit can reach, including a private hostname inside your VPN. We don't gate on TLS certificates or DNS visibility — only on the card being parseable.

Does this replace the Official MCP Registry?

No. The registry is a curated index. Server Cards are decentralised discovery. Both can co-exist. MCPOrbit reads both.

What if I publish a card and a server fails?

MCPOrbit shows the card-level metadata, then surfaces the connection error against the failing server. The card is still indexed; failures are scoped per-server.

Does MCPOrbit cache cards?

Yes — locally, with a TTL of 1 hour by default and a manual refresh option in the connection's row menu.