Summary

  • A 28 October individual IETF draft proposes using DNS-SD and mDNS to find nearby A2A agents and MCP servers before obtaining their fuller description or opening a session.
  • Every host on a shared link can announce an instance. The proposed descriptor digest helps notice change, while the later authenticated connection decides which agent the client actually reached.

The list has no doorman

A visitor joins the office network and asks which local agents are available. A DNS-SD browse can return names, service types, hosts and ports without a preloaded directory. That is the convenience in Loránd Jakab and Frank Brockners’ 28 October revision. It expands an earlier A2A sketch to cover MCP, shared discovery parameters and services reached beyond a single link. The publication is an individual Internet-Draft. The design remains a proposal.

The same browse request makes a small governance problem large. On a shared link, any host can publish an agent service instance and fill its TXT fields. A display title can imitate another agent. A desc-ref can point at a description whose operator the record never identifies. Revision 01 adds desc-ref-digest, but the advertiser supplies that value too. It can tell a client that the referenced description appears to have changed; it cannot authenticate the description. The red carpet and the guest list are made by the guests.

The draft keeps discovery in two stages. First, DNS-SD narrows the candidates and supplies rendezvous details. Then the client fetches an A2A description or begins an MCP handshake and authenticates the endpoint under that protocol. This sequence matters most where the candidate URL is assembled from an SRV host and port plus a path hint. A forged local announcement can steer a client toward a URL the advertiser influenced. The draft names the checks a client must own: accepted schemes, address ranges, ports, redirects, credentials and cross-domain requests. A default https scheme still leaves the server’s identity to be verified at connection.

For an MCP client, the prize behind the name is the list of tools, resources and prompts a server offers. A local announcement is a way to find that server. TLS identity and the client’s own authorization rules decide whether it gets to supply work. Likewise, a proxy that carries an advertisement beyond the original link only broadens its audience. It does not turn a self-declared title into an attested identity. RFC 9665 can reserve a registered service name on a first-come basis; the first arrival still has to prove who operates it.

There is a second bill for easy discovery: every host on the link can see the advertised service inventory. Protocol subtypes narrow search results, not visibility. A site that regards its agent names or protocols as sensitive has to decide which interfaces advertise, which optional fields appear, and which segments can browse. The relevant question for an operator is blunt: which machine may announce a candidate, which client may follow it, and which later proof lets the candidate act?

Sources: revision 01; revision 00; Datatracker status; mDNS, RFC 6762; DNS-SD, RFC 6763; service registration, RFC 9665.