Mario Thomas

Posted on Mar 4

MCP has a discovery problem. Here's a fix.

#mcp #ai #dns #architecture

Model Context Protocol defines how AI agents connect to tools. It says nothing about how agents discover which tools exist.

Today, the answer is manual configuration. A developer decides which MCP servers an agent has access to, hard-codes those addresses at build time, and hopes the list stays accurate. This works for a single developer with a handful of tools. It doesn't work for an organisation deploying dozens of agents across hundreds of systems.

The problem has a name in distributed systems: the n×m integration problem. n agents × m servers = n×m bespoke configuration decisions. With a discovery layer, that becomes n+m: each agent knows where to find the registry, each server registers itself once.

DNS has solved this before

Email clients find mail servers via MX records. Services advertise endpoints via SRV records. _dmarc handles email authentication. In each case the pattern is the same: a well-known naming convention points any compliant client to the right service, without prior configuration or bilateral agreement between the parties.

The same pattern works for MCP.

The proposal

Publish a single DNS TXT record at _mcp.yourdomain.com:

_mcp.yourdomain.com  300  IN  TXT  "v=mcp1;
  registry=https://mcp.yourdomain.com/registry;
  public=true;
  auth=https://auth.yourdomain.com/token;
  version=2026-02"

Any compliant agent that knows your domain resolves that record and finds your entire MCP ecosystem. No central directory. No proprietary SDK. No new protocol.

The registry is itself an MCP server

This is the key design decision. Rather than introducing a separate discovery API, the registry exposes four tools via the standard MCP protocol:

discover_servers — returns all servers the agent is authorised to see
get_server_details — returns connection details for a specific server
search_servers — searches by capability, data type, or keyword
check_server_health — returns last-known health status

Agents discover the registry using the same tools/list and tools/call calls they already make. Zero new client behaviour required. An agent that speaks MCP can use this registry without modification.

Public and private in one deployment

The registry supports two access tiers from a single deployment. Unauthenticated requests return public servers — tools any agent can use. Authenticated requests (RS256 JWT bearer token) additionally surface private servers — internal systems, sensitive data, governed tools.

The auth= field in the DNS record is a pointer to a token endpoint. It's a signpost, not a gate. Authentication and authorisation remain the responsibility of the registry and each individual MCP server.

The discovery flow

1. Agent resolves _mcp.yourdomain.com TXT record
2. Agent finds registry URL: https://mcp.yourdomain.com/registry
3. Agent sends tools/list to registry — gets discover_servers tool
4. Agent calls discover_servers — gets list of available MCP servers
5. Agent connects to individual servers and calls tools/list on each
6. Agent now has full capability picture — ready to act

Steps 1–4 are what this proposal addresses. Step 5 onwards is standard MCP.

The governance angle

Every registry change is a pull request. An engineer raises a PR to the registry repository. A designated reviewer approves it. On merge, a GitHub Actions workflow writes the change to DynamoDB. Every change is attributed, reviewed, and revertible.

The read path is fully serverless — CloudFront and Lambda@Edge. The write path is where governance lives. This produces something organisations will increasingly need: a queryable log of every agent that accessed the registry, what it requested, and when.

Infrastructure and cost

The reference implementation uses:

AWS Lambda@Edge — request parsing, JWT validation, JSON-RPC routing
Amazon DynamoDB Global Tables — registry data, globally replicated
Amazon CloudFront — global distribution, sub-50ms response times
Route 53 — DNS hosting for the _mcp record

Total cost at 1 million queries/month: under $5. The architecture is vendor-neutral — equivalent implementations are possible on Cloudflare Workers + KV, Azure Front Door + Cosmos DB, or any CDN with edge compute and an associated data store.

It's live right now

A working reference implementation is running at mcp.mariothomas.com. Three servers registered: articles and locations (public), documents (authenticated).

Verify the DNS record:

dig TXT _mcp.mariothomas.com +short

Query the live registry:

curl -X POST https://mcp.mariothomas.com/registry \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"discover_servers","arguments":{}}}'

Where to go next

Full architecture paper (security model, IANA considerations, deployment guide): mariothomas.com
Source code, SPEC.md, CloudFormation template: github.com/mariothomas/mcp-dns-registry
Community discussion: open in the modelcontextprotocol/modelcontextprotocol repository

The proposal is seeking community feedback — particularly on the field syntax, the layering model relative to SEP #1959, and the path to formal standardisation. Issues and alternative implementations are welcome.

DEV Community