Protocols for agent access: the landscape at concept level

There are two ways software can obtain something from a website. It can read the page a person would read — the rendered markup, or the accessibility tree beneath it, or a screenshot of the result — and extract what it needs. Or the site can expose a structured interface the software calls directly, receiving data or performing an action without a page in the loop at all. The first is the subject of the whitepaper on machine readers (BA-W-2026-03) and the companion note on reading the accessibility tree: page-parsing agents, which cope with the web as published. The second is the top of the Barkhausen Ladder — BL-8, whose marker is a machine-actionable interface an agent can invoke without parsing a web page. This note maps the protocols that occupy that second layer, at the level of what each one is, not how to implement it. It is a photograph of a young and unsettled landscape, and it is descriptive throughout: it defines no requirements and ranks nothing.

The distinction that organizes the layer

The whitepaper draws the line this note starts from: “BL-8’s marker is a machine-actionable interface an agent can invoke without parsing a web page at all; the agents documented here are doing precisely the page-parsing that BL-8 endpoints exist to make unnecessary.” Page-parsing agents and invokable endpoints are not competing implementations of one idea; they are different layers. A page-parsing agent works against a site that was built for human readers, reconstructing structure from presentation. An invokable endpoint is structure the site publishes on purpose, addressed to software. The protocols below are all mechanisms for the second — ways a site can declare, in a form an AI system can discover and call, what data and actions it offers.

Model Context Protocol

The Model Context Protocol (MCP) is documented as “an open-source standard for connecting AI applications to external systems” [1]. Its unit is a server that a site or service runs to expose its data and tools; an AI application acting as a client connects to that server and can then, in the documentation’s terms, reach “data sources (e.g. local files, databases), tools (e.g. search engines, calculators) and workflows (e.g. specialized prompts)” [1]. The documentation offers a deliberately plain analogy: “Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems” [1]. What MCP standardizes, then, is the shape of the connection — how a server advertises the tools and resources it holds and how a client invokes them — rather than any particular data or vocabulary. It is documented as “an open protocol supported across a wide range of clients and servers,” with the AI assistants Claude and ChatGPT among the clients its own page names as supporting it [1]. This is the protocol the Ladder cites as its public example of a BL-8 interface (BA-C-1).

NLWeb

NLWeb is described by Microsoft as “an open project developed by Microsoft that aims to make it simple to create a rich, natural language interface for websites” [2]. Where MCP standardizes the connection abstractly, NLWeb is pitched at the level of a website’s existing published data: its repository documents it as “a collection of open protocols and associated open source tools” that leans on “Schema.org and related semi-structured formats like RSS” — the structured markup many sites already publish — to build a natural-language endpoint over a site’s own content [3]. Its relationship to MCP is explicit and worth recording, because it shows the layer composing rather than fragmenting: Microsoft states that “Every NLWeb instance is also a Model Context Protocol (MCP) server, allowing websites to make their content discoverable and accessible to agents” [2]. The project frames its own ambition in protocol-stack terms — “NLWeb is to MCP/A2A what HTML is to HTTP” [3] — positioning itself as a content-and-query layer above the connection layer MCP provides. Its documentation is candid that the shipped code is “proof-of-concept demonstrations showing one possible approach” rather than a finished standard [3].

OpenAPI-described endpoints

The third pattern predates the current wave and reuses an established specification. Here a site exposes an ordinary web API described by an OpenAPI schema, and an agent platform reads that schema to learn how to call the API. OpenAI’s GPT Actions are the documented instance: OpenAI’s crawler documentation states that “ChatGPT users may also interact with external applications via GPT Actions” [4], and the Actions documentation makes the mechanism concrete — “A GPT Action requires an Open API schema to describe the parameters of the API call, which is a standard for describing APIs” [5]. The schema is what the model reads to decide which call to make and with what parameters; the endpoint itself is a conventional RESTful API. Conceptually this is the oldest and most familiar of the three approaches — an API plus a machine-readable description of it — repositioned as an agent-facing interface. It differs from MCP and NLWeb in provenance rather than in kind: all three let an agent discover and invoke a structured interface a site publishes deliberately.

WebMCP

A fourth entry is younger than the three above and sits deliberately across the boundary the distinction section draws. WebMCP is documented by the W3C Web Machine Learning Community Group, whose specification states that “the WebMCP API enables web applications to provide JavaScript-based tools to AI agents” [7]. Its introduction describes “a new JavaScript interface that allows web developers to expose their web application functionality as ‘tools’ — JavaScript functions with natural language descriptions and structured schemas that can be invoked by agents, browser’s agents, and assistive technologies” [7]. Where the three protocols above place the invokable interface on a server the agent reaches over the network, WebMCP places it inside the browser page: the specification defines the interface on the document object, where a page registers a tool by calling document.modelContext.registerTool(), each tool carrying a name, a natural-language description, and a JSON-schema description of its inputs [7].

Its relationship to MCP is stated directly, and, as with NLWeb, it is one of composition rather than rivalry. The specification records that pages using WebMCP “can be thought of as Model Context Protocol … servers that implement tools in client-side script instead of on the backend” [7]. The project’s explainer draws the same server-versus-page line this note uses: it calls MCP and OpenAPI “backend integrations,” in which “the platform communicates directly with the service’s backend servers via an API,” and offers WebMCP as “a client-side alternative” that “allows web developers to define tools directly in the browser page’s script” [8]. Replacing those backend protocols is listed among the explainer’s non-goals — “WebMCP is designed to complement, not replace, existing backend-focused protocols like MCP” [8].

This is where WebMCP meets the page-parsing boundary the whitepaper draws (BA-W-2026-03). It does not remove the rendered page: the explainer states that “page UI and content remain available to the agent for actuation, but the agent can use WebMCP tools to achieve the user’s goals more directly,” and names “replacement of human interfaces” as a further non-goal, adding that “the human web interface remains primary” [8]. An agent facing a WebMCP page therefore has both surfaces at once — the human-facing markup a page-parsing agent would read, and a set of registered tools it can invoke — so WebMCP adds an invokable interface of the kind the Ladder marks as BL-8 (BA-C-1) without withdrawing the page a page-parsing agent copes with. On maturity the Community Group is explicit: the document is labelled a Draft Community Group Report and states that “it is not a W3C Standard nor is it on the W3C Standards Track” [7], and the corresponding Chrome Platform Status entry records its standards maturity as a “specification being incubated in a Community Group” [10]. The implementation these sources describe is at preview stage rather than shipped, and it is Chrome’s: Chrome’s developer documentation exposes WebMCP behind a local-development flag, chrome://flags/#enable-webmcp-testing, and invites developers to “join the WebMCP origin trial from Chrome 149” [9].

Why robots.txt is not on this list

It is tempting to file robots.txt alongside these protocols, since it is the other machine-readable file a site publishes for automated visitors. It belongs to a different layer. Robots.txt is a crawler-access mechanism: it lets a site request that named crawlers not fetch certain paths, and its governing specification states that its rules “are not a form of access authorization” [6]. It exposes nothing for an agent to invoke; it grants or withholds fetch access to pages, which is the page-parsing world, not the invokable-endpoint one. The crawler taxonomy (BA-C-6) sharpens the point from the measurement side: agent traffic is largely not identifiable from user-agent strings at all, so robots.txt cannot even reliably address agents as a class, let alone offer them a structured interface. The protocols above are the structured alternative to a mechanism that was never built for this purpose — a way to publish an interface rather than to permit or refuse a fetch.

Limitations

This is a landscape photograph taken on 2026-07-10, and the landscape is early. The four protocols are young, their documentation changes without notice, and the characterizations here are drawn from each project’s own published material, which describes intent and design more than deployment. No public adoption statistics exist for any of them — no verified count of sites running an MCP server, an NLWeb instance, an agent-facing OpenAPI endpoint, or a WebMCP tool registration — and none is estimated here; a number offered without a source would be a fabrication, not a measurement. The set is also not exhaustive: it covers the protocols whose official documentation supports a concrete description, and other named efforts exist that the public record does not yet let this note characterize. Which of these approaches, if any, becomes the layer’s convention is not something the current documentation decides, and this note does not predict it. The specifics above should be assumed perishable.

@techreport{agent-protocol-landscape,
  author       = {{Barkhausen AI}},
  title        = {Protocols for agent access: the landscape at concept level},
  institution  = {Barkhausen AI},
  year         = {2026},
  url          = {https://barkhausen.ai/notes/agent-protocol-landscape/}
}