When You Need Agent Protocols, and When a Content Site Does Not
Everything in this family answers one question: can an assistant do something on your systems, rather than read something you published? If the answer is no, none of it applies, and publishing the files anyway is worse than leaving them out: an empty agent card tells a crawler there is an action surface behind it.
What each one is for
MCP, the Model Context Protocol, is an open protocol for exposing tools and data to an assistant through a server the assistant connects to. It is how a model gets a supported way to call your search, your inventory, or your support system instead of scraping a page and guessing. It matters when you have something to call.
A2A, Agent2Agent, is the equivalent for agents talking to each other rather than to a client. A published agent card describes what an agent can do and how to reach it. It matters when your systems are themselves agents that another agent should be able to delegate to.
auth.md is an emerging convention for a plain markdown file that tells an automated client how to authenticate to your API: which flow, which endpoint, what scopes, what to do when it is refused. It is documentation aimed at a machine, and it only has a subject if you run an API.
An API catalog is a machine-readable index of the APIs you publish, so a client can discover them rather than being told. The pattern is settled enough to have a well-known path, and it is still a document about endpoints you already have.
DNS-AID is DNS-based discovery of agent endpoints, the idea that an agent could be found the way a mail server is found, through a record rather than a page. It is early, it is worth watching, and it is not something a content site needs to publish today.
The test
Ask whether an assistant could take a useful action against your business today, with credentials you would be willing to issue and an audit trail you would be willing to keep.
If yes, these files are how you describe that action surface, and they deserve the same care as any other public API: authentication, scopes, rate limits, logging, and a way to revoke access.
If no, the answer is not to publish a placeholder. A brochure site, a blog, a documentation set and a product marketing page all publish pages, and the protocol for pages is HTTP, a sitemap, and a robots.txt. An agent that can read those can already answer questions about you. Nothing further is required, and nothing further is missing.
What a content site needs instead
Four things, none of them new: a robots.txt that says what may be crawled, a Content-Signal line that says how the content may be used, a sitemap that lists the pages worth reading, and pages whose titles and headings say what they contain. An llms.txt helps an assistant find the right page quickly, and it is optional rather than structural.
That is the whole set for a site like ours. If your report shows no agent protocol files, that is not a failure being reported; it is a fact about what kind of site you run.
How the report treats them
Our AI visibility check reports these files and never scores them. They contribute zero of the 100 points, on purpose. Scoring them would penalize every content site for not publishing an action surface it does not have, which would be a number measuring the wrong thing.
The scored parts are agent access, content signals, llms.txt, the sitemap and Link headers, and markdown negotiation: the things that decide whether an assistant can read the site and know what it is. The protocols table sits beside that as information, and the advisory exists so the question gets answered once rather than asked every month.
