Check C4 in the rubric is worth five points and asks a simple question: does this site publish anything a program can use directly, rather than having to scrape? Any one of an agents.json, an MCP or WebMCP manifest, a published link to API documentation, or a discoverable OpenAPI spec earns credit. More than one earns the full five.
When we scan sites, the usual result on C4 is zero. Not a partial, not a near miss, zero. That is unusual on a rubric where most checks fail by degrees, and it is the reason C4 separates the leaders: it is the one check where doing the work at all puts you in a small group.
What the check is actually asking for
The four things C4 accepts are different in kind, which is worth understanding before deciding which to build.
An agents.json is a manifest at a well-known location that describes the site to an agent: what it is, how to contact the operator, where the documentation lives, how to search it, how the operator would like to be crawled, and which endpoints exist. It is a description, not an interface.
An OpenAPI spec describes an HTTP API precisely enough that a client can be generated from it. It is a settled standard with a decade of tooling behind it, and a great many organisations already have one for internal use. Publishing a read-only subset at a discoverable URL is the smallest step on this list for anyone who already runs an API.
A published API documentation link is the human-readable counterpart. The check wants it to be linked, meaning findable from the site rather than sitting on a subdomain nothing points to.
An MCP or WebMCP manifest exposes capabilities as tools a model can call. MCP servers exist and are consumed by client software today; WebMCP is a proposal for doing the same from inside a web page, and it is still moving.
Why almost nobody has done it
There is no mystery here. Four reasons account for nearly every zero we see.
Nobody's checklist asks for it. Twenty years of SEO produced a well-understood list of things a site should have, and every audit tool checks that list. Machine endpoints are not on it, because search engines never needed them. A site can pass every SEO test ever written and still have nothing on C4; the difference between agent readiness and SEO is largely this.
It needs an engineer, not a marketer. Most of the rubric can be moved by whoever owns the templates or the CMS. C4 is the one check that involves publishing an interface, which means a developer, a decision about what to expose, and a maintenance commitment. That is why it carries a High effort rating.
The standards are unsettled. agents.json has no single governing specification. WebMCP is a proposal. Even where MCP is being consumed, the conventions for discovering a server from a domain are still forming. A sensible engineering lead, asked to publish something against a moving target, will often wait, and waiting is a defensible choice.
There is no visible cost to not doing it. A site without an OpenAPI spec looks identical to one with it, in a browser and in analytics. The agent that could not act on the site does not report an error. It uses a site it could act on, and nobody on your side finds out.
Why that makes it the cheapest differentiation
Five points is not a large share of 100. The value of C4 is not the points; it is the distribution.
On most of the rubric, the sites you compete with are somewhere on a curve. Everyone has a robots.txt, most have some structured data, a fair number have alt text. Moving from partial to full credit on B1 puts you a little ahead of a lot of sites. Moving from zero to five on C4 puts you ahead of nearly every site we have scanned on that check, which is a different kind of gap from a few points on a check everyone half-passes.
It is also, unusually for a High effort check, bounded. Fixing A7 on a client-rendered site can mean re-architecting the rendering layer for every commercial route. Publishing a read-only API with an OpenAPI document is a scoped piece of work with a clear end, and for organisations that already have an API it can be a matter of writing the descriptions and choosing a URL.
What we published, and which parts are a bet
It would be indefensible for us to score C4 and not publish anything ourselves, so we did all four, and they are worth reading as a worked example rather than as a template.
/agents.json is our manifest. It carries the site's name and legal operator, contact addresses for general, security and privacy enquiries, links to llms.txt, llms-full.txt and the methodology with the current rubric version, a search URL template an agent can construct without touching a form, a crawling section that documents our own bot's user agent, limits and opt-out, a list of endpoints, and links to the privacy, terms and data-processing policies. The endpoints list only what actually exists. It was deliberately empty until the API shipped, because a manifest that advertises things that do not exist is worse than none.
curl -s https://agentfriendlyrank.com/agents.json | jq '.endpoints[].type'
/api/v1/openapi.json is an OpenAPI 3.1 document for the read-only API: the rubric, the leaderboard, per-site reports, comparisons and scan status, with no key required. It is hand-written rather than generated, because the value of the document to an agent is in the descriptions it reads to decide what to call, and no generator writes those for you. The path list is unit-tested against the route files so the two cannot drift.
/mcp is an MCP server over Streamable HTTP, no authentication, exposing the same data as five tools: get_site_report, get_leaderboard, compare_sites, get_scan_status and get_rubric.
/docs is the human-readable documentation for both, and /llms.txt points at all of them under a "Notes for agents" heading, so that a program which reads only the text file still finds the machine surfaces.
Now the honest part. OpenAPI is settled; publishing one is not a bet. MCP has real clients today, but the convention for discovering a server from a bare domain is not fixed, which is why our agents.json and llms.txt both point at it explicitly. agents.json itself is the least settled of the four: our file declares schemaVersion: "0.1" because there is no authoritative version to declare, and the field names are ours. WebMCP we have not built, because it is a proposal and we would rather not build to a draft and call it done. When any of this settles, the rubric will change, the changelog will say what changed, and historical scores will stay as they were.
What to build first
If you already run an API, publish an OpenAPI document for a read-only subset at a discoverable URL and link the documentation from your site. That is one thing, it is a settled standard, and it already earns C4 credit.
If you do not, an agents.json that describes the site honestly and lists nothing that does not exist is a small piece of work. Pair it with a documentation page and you have more than one surface, which is the full five points.
Treat MCP as the third step, once there is something worth exposing as tools. Treat WebMCP as something to watch.
The implementation service builds any of these, and we say plainly which parts are a bet before we start.
Check your own site
Run a free scan and open the evidence block on C4; it shows exactly which of the four surfaces the crawler looked for and what it found. The full definition is in pillar C of the methodology.