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

Hey everyone,

I've been reading through the discovery discussion in thread #1147 with a lot of interest. It's clear solving this is a top priority, and the ideas there around using /.well-known/mcp.json are compelling.

I wanted to explore this same problem from a different technical angle, using DNS TXT records (much like MX records). Since the underlying mechanism is different, I felt it warranted a clean, separate thread to keep both conversations focused.

The conversation seems to be coalescing around a /.well-known/mcp.json file. This is a solid approach, but as I thought about it, I kept coming back to first principles. The .well-known path requires an active web server to respond, which feels like it might be adding an extra step.

The internet already has a more fundamental, lower-level mechanism for service discovery that doesn't even require a web server: DNS. It's how we've handled email discovery with MX records for 40 years. It's incredibly robust and decentralized.

So, I wrote up a spec called Agent Interface Discovery (AID) that applies this idea to agents. Instead of hitting a web endpoint, a client just makes a standard DNS query.

The entire proposal is a single TXT record at _agent.<domain>:

_agent.wix-site.com. IN TXT "v=aid1;p=mcp;uri=https://mcp.wix.com/site-id-123;auth=pat"

Why this might be a better fit:

• Simpler: It's just DNS. No web server, no HTTP GET, no JSON parsing if all you need is the endpoint. It pushes the complexity to where it belongs: the actual MCP connection.
• More Robust: DNS is one of the most resilient, cached, and distributed systems on the planet.
• Separation of Concerns: It keeps the location of the agent (a network-level concern) separate from the capabilities of the agent (an application-level concern). The .well-known proposals seem to conflate these, adding things like capabilities and schemas, which feels like a job for the Initialize step in MCP itself.

This AID approach is intentionally minimal. It has one job: get the uri for the MCP server. Then it gets out of the way.

This seems to align with the spirit of the original post in #1147 while simplifying the implementation and avoiding some of the complexity that the thread has since taken on.

I built a small workbench to show how it works and formalized the spec. Would love to hear what the community thinks of this DNS-first approach as an alternative path for discovery.

You can see the spec and try the workbench here: aid.agentcommunity.org

Scope

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