Of the four machine surfaces check C4 accepts, one is a settled standard, one is a published protocol with real clients, one is a convention without a specification, and one is a proposal. This post says which is which as of this writing, what we have built and what we have deliberately not built, and why. It will be revised as the standards move, and the date at the top is the date on which the description was true.
The rule we hold ourselves to is the one on the implementation service page: build to what is actually being consumed today, and say plainly which parts are a bet. Selling a proposal as a standard would be the same offence as publishing a score with no scan behind it.
Four surfaces, four states
| Surface | State as of this writing | What we have done |
|---|---|---|
| OpenAPI | Settled specification, 3.1.0 published | Published at /api/v1/openapi.json |
| MCP | Published protocol with dated revisions; clients exist; discovery from a bare domain not fixed | Hosted server at /mcp |
agents.json |
No governing specification | Published, with a schemaVersion of 0.1 and field names of our own |
| WebMCP | A proposal | Not built |
The scanner's view of these is narrower than the table. It fetches /agents.json and awards that surface if the response is 200 and parses as JSON. It tests the homepage HTML for a reference to an OpenAPI or Swagger document, for a link to documentation, and for an MCP reference, where the MCP pattern is /.well-known/mcp, mcp.json or the string modelcontextprotocol. One surface scores three of the five points; two or more score all five. Why most sites score zero on machine endpoints covers the check as a whole.
What WebMCP is
WebMCP is a proposal for letting a web page expose tools to an agent from inside the page itself. Where MCP puts the tools behind a separate server endpoint, the idea in WebMCP is that the page declares what can be done on it, in the same place its forms and buttons live, so that an agent operating in a browser can call those tools rather than driving the interface by guesswork. The proposal is developed in the open at github.com/webmachinelearning/webmcp.
That is as far as this post goes on the mechanism, on purpose. The names, the shapes and the surface are the parts of a proposal most likely to change, and a description of them written today would be a description of a draft.
What a proposal is
A proposal is text that people are discussing. It is not a standard. Nothing in it is promised to ship in any browser, and the outcome of the discussion may be a standard that looks like the proposal, a standard that looks different, or nothing. Names get renamed, arguments get reordered, and whole mechanisms are dropped between drafts. Anyone who has watched a web platform feature go from explainer to shipping knows how much changes in between, and how many explainers never get there.
That does not make proposals unimportant. It makes them the wrong thing to build a customer's site to and then call finished. The honest positions are "we are watching this" and "we will build it when there is something to build against", and the dishonest one is "WebMCP-ready".
Why we have not built to it
Three reasons, in order of weight.
First, the one above. We score sites on a published rubric and we sell fixes against it. If we shipped something labelled WebMCP today, we would be selling a bet as a settled surface, and the next revision of the proposal could make it wrong. The MCP server we did build is a published protocol with a version we can name, and even that comes with a caveat below.
Second, the scanner has nothing settled to look for. The rubric's text for C4 names "an MCP or WebMCP manifest" among the surfaces it accepts, and the check as implemented in version 1.0.1 looks for the MCP pattern described above. There is no WebMCP-specific pattern, because there is no settled artefact, no agreed filename and no agreed location that a scan could test for and defend as evidence. If a page built to a WebMCP draft happens to match, it is because it references MCP.
Third, our crawler does not execute JavaScript. That is a deliberate choice that keeps every finding about the raw HTML an agent actually receives, and it means a mechanism that lives in the running page is, for now, outside what the free scan can evidence. When WebMCP settles, that will need a decision about how to measure it, and that decision will arrive as a rubric version bump with an entry in the changelog. Scores issued under the current version will not be restated.
What is settled enough to build now
OpenAPI first. The specification is published and stable, tooling has existed for a decade, and a read-only document over data you already render is a bounded piece of work. Publishing an OpenAPI spec for a site that has no API shows the minimum. Nothing about this is a bet.
MCP second, with two caveats we would rather state than have you discover. The protocol has dated revisions; our server negotiates three of them, 2025-06-18, 2025-03-26 and 2024-11-05, which tells you both that it is a real released protocol and that it is still moving. And 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 /mcp explicitly rather than relying on a well-known path. Build a read-only server and link it from everywhere a program might look.
agents.json alongside either, with its bet named. It is cheap and it earns the surface, and it is also the least settled of the three we have built: our file declares schemaVersion: "0.1" because there is no authoritative version to declare, and the field names are ours. agents.json explained goes through the file and says which fields we expect to survive.
WebMCP, watch. Read the repository, note which browser vendors and client authors are participating, and do not commission work against it until there is a shipped implementation to test in.
What to watch, and what we will change
Four things could move the rubric. A WebMCP specification with a shipping implementation, which would give the scanner an artefact to test. A discovery convention for MCP servers that clients actually use, which would let /.well-known/mcp mean something rather than merely match. A governing specification for agents.json, which would turn our 0.1 into a version we did not choose. And the agentic commerce protocols, which we have left out of this post entirely because none of them is a surface the scanner tests yet.
Each of those would be a change to what C4 accepts, and each would follow the same path: a version bump, a changelog entry saying what changed and why, and historical scores left exactly as they were. Until then, the safe order is OpenAPI, then MCP, then a manifest that lists only what exists.
Check your own site
Run the free scan and read the C4 evidence; the found list shows which machine surfaces the crawler could see, and nothing on it depends on a proposal. The full definition, with the text naming each accepted surface, is in pillar C of the methodology, and /docs shows what we have built against each of the settled ones.