# MCP, A2A and WebMCP for stores

MCP, A2A and WebMCP: what each specification defines, what it could mean for a store that wants to offer tools to agents, and what status each gives itself.

By Valerii Checha, 18 Oct 2026

A store that wants AI agents to search its catalogue or run its checkout can offer them tools: named actions, with defined inputs and outputs, that an agent can ask to run. MCP and WebMCP define ways to offer tools, and A2A defines how agents talk to one another, with an agent card that describes the agent being called. The three work in different places. This article goes through what each defines, where it runs, what status it gives itself, and how it connects to the commerce protocols UCP, ACP and AP2.

It belongs to a series. [The hub article](https://storewalk.ai/blog/why-agents-cant-buy) sets out five walls between an agent and a finished purchase. How an agent finds a store's documents in the first place, agent cards and server cards among them, is the subject of [How agents discover what a store offers](https://storewalk.ai/blog/how-agents-discover-a-store). [UCP vs ACP vs MCP vs AP2](https://storewalk.ai/blog/ucp-vs-acp-vs-mcp-vs-ap2) compares MCP with the commerce protocols layer by layer.

Where we explain a term in plain words, the explanation is ours, not any specification's. Everything else comes from the documents linked in the text and listed under sources.

## What each one is for

- [MCP](https://modelcontextprotocol.io/specification/latest), the Model Context Protocol: "Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools." An LLM, a large language model, is the kind of AI model that chat assistants run on.
- [A2A](https://a2a-protocol.org/latest/specification/), the Agent2Agent protocol: "The Agent2Agent (A2A) Protocol is an open standard designed to facilitate communication and interoperability between independent, potentially opaque AI agent systems."
- [WebMCP](https://webmachinelearning.github.io/webmcp/): "The WebMCP API enables web applications to provide JavaScript-based tools to AI agents." Its introduction adds: "Web pages that use WebMCP can be thought of as Model Context Protocol \[MCP] servers that implement tools in client-side script instead of on the backend."

A2A's [own site](https://a2a-protocol.org/latest/) sets the first two side by side: "MCP is for agent-to-tool communication: it standardizes how an agent connects to its tools, APIs, and resources to get information." And "A2A is for agent-to-agent communication". An API is a documented way for one program to talk to another.

In our reading, for a store that means three places. MCP tools sit on a server that the store or its platform would run. An A2A agent is a whole agent of the store's own that other agents talk to. WebMCP tools are script in the store's web page, running in the shopper's browser.

## MCP: tools on a server

MCP's specification names three roles: "Hosts: LLM applications that initiate connections", "Clients: Connectors within the host application" and "Servers: Services that provide context and capabilities". In our words, the host is the AI app a shopper uses, a client is the part of it that talks to one server, and the server is the program that offers the tools. They exchange JSON-RPC 2.0 messages. JSON is a plain-text format for structured data, and JSON-RPC is a way of writing a call in it: one side names a function and its arguments, and the other replies with a result or an error.

"Servers offer any of the following features to clients": resources, "Context and data, for the user or the AI model to use"; prompts, "Templated messages and workflows for users"; and tools, "Functions for the AI model to execute". The current revision is 2026-07-28. MCP names its versions by date, "the last date backwards incompatible changes were made", and marks each revision Draft, Current or Final.

The [tools page](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) of that revision says MCP "allows servers to expose tools that can be invoked by language models", and "Each tool is uniquely identified by a name and includes metadata describing its schema." A schema here is a description of the inputs a tool accepts, written in JSON Schema. The page draws the exchange as a diagram with three participants, and the figure follows it message by message.

An MCP tool call, message by message.

1. Client → Server: tools/list. To discover available tools, the client sends a tools/list request. The set of tools may vary by the authorization presented on the request. Source: [MCP specification 2026-07-28: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools).
2. Server → Client: List of tools. Each tool has a name, “Unique identifier for the tool”, a description and an inputSchema, a JSON Schema “defining expected parameters”. Source: [MCP specification 2026-07-28: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools).
3. LLM → Client: Select tool to use. The language model picks the tool. The diagram draws this as a message from the LLM to the client. Source: [MCP specification 2026-07-28: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools).
4. Client → Server: tools/call. The client sends tools/call with the tool’s name and its arguments. The specification says there SHOULD always be a human in the loop with the ability to deny tool invocations. Source: [MCP specification 2026-07-28: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools).
5. Server → Client: Tool result. The server returns the result. In the specification’s example it is text content, with isError false. Source: [MCP specification 2026-07-28: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools).
6. Client → LLM: Process result. The client passes the result to the language model. Source: [MCP specification 2026-07-28: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools).

If the server declared listChanged:

1. Client → Server: subscriptions/listen. This case applies only to a server that declared listChanged, which “indicates whether the server will emit notifications when the list of available tools changes”. The client opens a stream with toolsListChanged: true. Source: [MCP specification 2026-07-28: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools).
2. Server → Client: notifications/subscriptions/acknowledged. The server acknowledges the subscription. Source: [MCP specification 2026-07-28: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools).
3. Server → Client: notifications/tools/list_changed. When its list of tools changes, a server that declared listChanged SHOULD notify a client that opened the stream. Source: [MCP specification 2026-07-28: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools).
4. Client → Server: tools/list. The client asks for the list again. Source: [MCP specification 2026-07-28: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools).
5. Server → Client: Updated tools. The server returns the updated list. Source: [MCP specification 2026-07-28: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools).

On the same page, the set of tools "MAY vary by the authorization presented on the request". In our reading, a store's server could list more tools for a caller that has signed in than for one that has not. And "there SHOULD always be a human in the loop with the ability to deny tool invocations"; the overview adds that "Hosts must obtain explicit user consent before invoking any tool".

Before listing tools, a client can ask a server about itself. The specification's [discovery page](https://modelcontextprotocol.io/specification/2026-07-28/server/discover) says: "server/discover lets a client query a server's supported protocol versions, capabilities, and identity before sending any other requests. Servers MUST implement it." The client sends it to a server whose address it already has; the core specification defines no file at a web address for this step.

Sign-in is optional in MCP. The [authorization page](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) says "Authorization is OPTIONAL for MCP implementations", and that implementations over HTTP, the protocol browsers and servers use to exchange pages, "SHOULD conform" to it. Where they do, "MCP servers MUST implement OAuth 2.0 Protected Resource Metadata (RFC9728)". OAuth is a way for one program to get limited access to an account held elsewhere. Sign-in for agents is the subject of [Why agents stall at checkout](https://storewalk.ai/blog/why-agents-stall-at-checkout).

## Server cards: describing an MCP server before connecting

MCP server cards are for the step before the client has an address. They come from [SEP-2127](https://modelcontextprotocol.io/seps/2127-mcp-server-cards), a numbered proposal to MCP, marked "Status: Final" and "Type: Extensions Track". It defines "a standardized, self-contained format to describe MCP servers for pre-connection discovery", and says "MCP Server Cards are optional and additive". MCP's overview says of its extensions in general that they "are always opt-in and require explicit support from both client and server".

A card is "A static metadata document describing a remote MCP server": its identity (name, version, description and a few optional fields) and "its remote transport endpoints", the addresses where it can be reached. "Cards themselves can be hosted at any unreserved URI, with `<streamable-http-url>/server-card` reserved as the recommended location", which in our reading means the server's own MCP address with `/server-card` added. For a whole domain, "an AI Catalog can link to or embed the relevant Server Cards". The extension's [discovery document](https://github.com/modelcontextprotocol/ext-server-card/blob/main/docs/discovery.md), marked "Protocol Revision: draft", says hosts "MAY publish" a catalogue at `/.well-known/ai-catalog.json`, and "Clients performing domain-level discovery SHOULD attempt to retrieve this well-known URL."

A card does not list tools. SEP-2127 "intentionally omits primitive definitions (tools, resources, and prompts) from server cards", because "the primitives a server exposes can vary by authenticated user, session, configuration, feature flags, deployment state, and more. A static document cannot reliably represent this surface". An agent still learns the tools with tools/list once it is connected. Where a card and server/discover disagree, "clients SHOULD prefer the live server/discover values."

Server cards are an optional extension, so MCP's core specification still defines no discovery file. [The comparison](https://storewalk.ai/blog/ucp-vs-acp-vs-mcp-vs-ap2) counts only what each protocol's core specification defines, and for that reason it gives MCP no discovery layer.

## A2A agent cards: describing an agent

A2A covers a different arrangement: one agent talking to another, where neither has to show the other how it works inside. For a store, in our reading, that means running an agent of its own that other agents can reach.

The specification's latest released version is 1.0.0, and the latest release in its GitHub repository is v1.0.1, published on 28 May 2026. A2A's site says the protocol "was originally developed by Google and donated to the Linux Foundation. It is maintained by a Technical Steering Committee with representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow".

"A2A Servers MUST make an Agent Card available." The card is "A self-describing manifest for an agent", with "the agent's identity, capabilities, skills, supported communication methods, and security requirements", and "Clients use this information for discovering suitable agents and configuring interactions." The specification gives three ways to find one: the address `https://{server_domain}/.well-known/agent-card.json`, "Registries/Catalogs" and "Direct Configuration". An address under `/.well-known/` is a fixed path on a domain where software knows to look without being told. The figure is the specification's own example card.

An A2A agent card, field by field.

The example card in section 8.4.1 of the A2A specification, as printed there. It describes an example agent that echoes messages, not a shop.

```json
{
  "name": "Example Agent",
  "description": "An example agent that echoes messages.",
  "supportedInterfaces": [
    {
      "url": "https://example.com/a2a/v1",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "version": "1.0.0",
  "capabilities": {
    "streaming": false,
    "pushNotifications": false,
    "extensions": []
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "echo",
      "name": "Echo",
      "description": "Echoes the input.",
      "tags": ["echo"]
    }
  ]
}
```

Its fields:

- "name". In our words: What the agent is called. Required. What the source says: “A human readable name for the agent.” Source: [A2A specification](https://a2a-protocol.org/latest/specification/).
- "description". In our words: What the agent is for, in plain language, for people and for other agents. Required. What the source says: “A human-readable description of the agent, assisting users and other agents in understanding its purpose.” Source: [A2A specification](https://a2a-protocol.org/latest/specification/).
- "supportedInterfaces". In our words: Where to send messages to the agent, and how. A card can list several addresses, best first. Required. What the source says: “Ordered list of supported interfaces. The first entry is preferred.” Each entry’s url is “The URL or address where this interface is available”. Source: [A2A specification](https://a2a-protocol.org/latest/specification/).
- "protocolBinding". In our words: The message format this address speaks. Here it is JSON-RPC, and protocolVersion says which A2A version. What the source says: “The protocol binding supported at this URL … The core ones officially supported are JSONRPC, GRPC and HTTP+JSON.” protocolVersion is “The version of the A2A protocol this interface exposes.” Source: [A2A specification](https://a2a-protocol.org/latest/specification/).
- "version". In our words: The version of this agent, set by whoever runs it. It is not the A2A version. What the source says: “The version of the agent.” Source: [A2A specification](https://a2a-protocol.org/latest/specification/).
- "capabilities". In our words: Optional A2A features the agent supports. This one supports neither streaming nor push notifications. Required. What the source says: “A2A Capability set supported by the agent.” streaming: “Indicates if the agent supports streaming responses.” pushNotifications: “Indicates if the agent supports sending push notifications for asynchronous task updates.” Source: [A2A specification](https://a2a-protocol.org/latest/specification/).
- "defaultInputModes". In our words: What kinds of content the agent accepts and returns, written as media types. text/plain means plain text. What the source says: “The set of interaction modes that the agent supports across all skills. This can be overridden per skill. Defined as media types.” defaultOutputModes: “The media types supported as outputs from this agent.” Source: [A2A specification](https://a2a-protocol.org/latest/specification/).
- "skills". In our words: What the agent can do, one entry per skill, each with its own id, name and description. Required. What the source says: “Skills represent the abilities of an agent. It is largely a descriptive concept but represents a more focused set of behaviors that the agent is likely to succeed at.” id: “A unique identifier for the agent’s skill.” Source: [A2A specification](https://a2a-protocol.org/latest/specification/).
- "tags". In our words: Keywords for the skill, which a client or a catalogue can match on. What the source says: “A set of keywords describing the skill’s capabilities.” Source: [A2A specification](https://a2a-protocol.org/latest/specification/).

The specification prints this card in its section on preparing a card for signing, and the card has no signatures field. Agent Cards “MAY be digitally signed using JSON Web Signature (JWS)”, and “Clients SHOULD verify at least one signature before trusting an Agent Card”. Clients can find a card at https\://{server_domain}/.well-known/agent-card.json, in registries or catalogues, or through direct configuration. Source: [A2A specification](https://a2a-protocol.org/latest/specification/).

A skill has an id, a name, a description and tags, and the specification calls skills "largely a descriptive concept". Messages go to an address listed under `supportedInterfaces`, in one of the bindings the specification names: JSONRPC, GRPC or HTTP+JSON.

A card can be signed. Agent Cards "MAY be digitally signed using JSON Web Signature (JWS)", a standard way to sign a JSON document so a reader can check who produced it and that nobody changed it since. The specification adds that "Clients SHOULD verify at least one signature before trusting an Agent Card".

## WebMCP: tools inside the page

WebMCP's specification is a "Draft Community Group Report, 20 October 2026", "published by the Web Machine Learning Community Group", and "It is not a W3C Standard nor is it on the W3C Standards Track." The W3C publishes the web's standards; a community group works on a topic under its roof, and this report says itself that it is not one of those standards. Its editors are from Microsoft and Google.

The specification describes its tools as "JavaScript functions with natural language descriptions and structured schemas that can be invoked by agents, browser's agents, and assistive technologies." JavaScript is the language a web page runs in the browser. A page offers a tool by calling `document.modelContext.registerTool`, which "Registers a tool that agents can invoke." An agent, in the specification's terms, "is an autonomous assistant that can understand a user's goals and take actions on the user's behalf to achieve them", and a browser agent is one "provided by or through the browser", "for example, via an extension or plug-in".

The project's [README](https://github.com/webmachinelearning/webmcp/blob/main/README.md), its explainer, has a shop example: a dress shop whose page "has already registered tools to search and display products". The figure takes the first of those tools apart.

A WebMCP tool, registered by the page.

The first tool in the WebMCP README’s shop example, for a made-up dress shop at wildebloom.example, as the README prints it with its indentation reduced.

```js
await document.modelContext.registerTool({
  name: "get-dresses",
  description: "Returns an array of product listings containing id, description, price, and photo.",
  inputSchema: {
    type: "object",
    properties: {
      size: { type: "number", description: "Optional EU dress size to filter by." },
      color: { type: "string", description: "Optional color to filter by." }
    }
  },
  async execute({ size, color }) {
    const response = await fetchDresses(size, color);
    return response.json();
  }
});
```

Its parts:

- registerTool. In our words: The page’s own script makes this call while the page is open. The tool belongs to that page and exists only after the call. What the source says: WebMCP draft: “Registers a tool that agents can invoke.” It returns a rejected promise “if a tool with the same name is already registered, if the given name or description are empty strings, or if the inputSchema is invalid.” Source: [WebMCP draft](https://webmachinelearning.github.io/webmcp/).
- name. In our words: The name an agent uses to call the tool. Required. What the source says: “A unique identifier for the tool. This is used by agents to reference the tool when making tool calls.” Source: [WebMCP draft](https://webmachinelearning.github.io/webmcp/).
- description. In our words: What the tool does, in words, so the agent can decide whether to use it. Required. What the source says: “A natural language description of the tool’s functionality. This helps agents understand when and how to use the tool.” Source: [WebMCP draft](https://webmachinelearning.github.io/webmcp/).
- inputSchema. In our words: What the tool accepts, described in JSON Schema: here an optional size and an optional colour. What the source says: WebMCP draft: “A JSON Schema object describing the expected input parameters for the tool”. README: the agent sends “structured arguments matching the tool’s inputSchema”. Sources: [WebMCP draft](https://webmachinelearning.github.io/webmcp/) and [WebMCP README](https://github.com/webmachinelearning/webmcp/blob/main/README.md).
- execute. In our words: The function that runs when an agent calls the tool. It runs in the shopper’s browser, inside the page. What the source says: WebMCP draft: “A callback function that is invoked when an agent calls the tool.” README: “The browser mediates the call, invokes the tool’s execute callback with the provided arguments, and executes client-side logic on the page.” Sources: [WebMCP draft](https://webmachinelearning.github.io/webmcp/) and [WebMCP README](https://github.com/webmachinelearning/webmcp/blob/main/README.md).
- fetchDresses. In our words: The shop’s own code, which the README calls but does not show. In our reading, this is where a tool reuses what the page already does. What the source says: README, in its other example: “Reuse existing client-side application logic and update UI.” Source: [WebMCP README](https://github.com/webmachinelearning/webmcp/blob/main/README.md).

WebMCP is a Draft Community Group Report of 20 October 2026 and, in its own words, “not a W3C Standard nor is it on the W3C Standards Track.” The specification defines no file that lists a page’s tools: the tools exist once the page’s script has registered them. Agents written in JavaScript inside the page can ask for them with getTools(); the browser’s own agent “uses a different internal mechanism”. Sources: [WebMCP draft](https://webmachinelearning.github.io/webmcp/) and [WebMCP README](https://github.com/webmachinelearning/webmcp/blob/main/README.md).

The README describes a call in five steps. First the page registers its tools. "An agent connected to the page queries the browser to discover the active list of tools and their schemas." The agent requests a call with "structured arguments matching the tool's inputSchema". "The browser mediates the call, invokes the tool's execute callback with the provided arguments, and executes client-side logic on the page." Then the page's callback returns the result to the agent.

A tool can carry annotations. With `consequentialHint`, it "indicates that executing the tool will result in consequential actions that are significant, real-world, or non-reversible, ex: booking a flight, transferring money." With `readOnlyHint`, it "indicates that the tool does not modify any state and only reads data."

The specification has no well-known address and no manifest for a page's tools: they exist once the page's script has registered them. Its README says a declarative counterpart built on HTML forms "is being explored separately … but it is not part of the specification at this time", and that static manifests were set aside because they "prevent web developers from dynamically adding, updating, or removing tools". In our reading, a program that reads a page's HTML without running its scripts cannot see these tools. [How an AI agent reads a web page](https://storewalk.ai/blog/how-agents-read-a-page) covers the difference between the two.

One payment vendor documents an integration. [Stripe's agentic commerce documentation](https://docs.stripe.com/agentic-commerce) lists "Use WebMCP to complete Stripe payments in a browser: Build browser agents that discover and use structured tools in Stripe payment UIs." It shows one vendor's integration, not how widely WebMCP is used.

## Where they meet UCP, ACP and AP2

[UCP](https://ucp.dev/latest/specification/overview/) lists four transports a store can declare for its services: "rest, mcp, a2a, embedded". A transport, in our words, is a channel the protocol's own messages travel over. The overview says how each binding is defined: "REST: OpenAPI 3.x (JSON format)", "MCP: OpenRPC (JSON format)" and "A2A: Agent Card Specification". In our reading, a UCP store can offer its services as MCP tools or through an A2A agent, while UCP defines what the messages mean. [UCP explained](https://storewalk.ai/blog/ucp-explained) goes through the profile where these are declared.

ACP added an MCP binding in its 2026-04-17 release. The [binding file](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openrpc/openrpc.agentic_checkout.json) "Defines 5 MCP tools", each mapped one to one onto an ACP REST checkout operation, from `create_checkout_session` to `cancel_checkout_session`. The [binding document](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/docs/mcp-binding.md) calls MCP "a second transport binding for ACP, alongside REST", which "allows AI agents to invoke checkout operations as native MCP tool calls instead of constructing HTTP requests", and says "The binding is purely additive". It covers checkout only. Delegated payment is "a separate API surface served by a different party (payment provider, not merchant)", and "it should be addressed in a follow-up SEP". [ACP explained](https://storewalk.ai/blog/acp-explained) covers the checkout session itself.

AP2, the Agent Payments Protocol, is "available as an extension for the open-source Agent2Agent (A2A) protocol and Universal Commerce Protocol with more integrations in progress", according to its [home page](https://ap2-protocol.org/). Its [specification](https://ap2-protocol.org/ap2/specification/) says "AP2 operates as a security feature within a Commerce Protocol", and that catalog APIs, checkout updates and similar details "are outside the scope of AP2".

## What a store owner can ask today

The picker takes four questions one at a time. Each answer points to one specification, quotes what that specification says it is for, and gives its status. It does not recommend one.

MCP, A2A or WebMCP: what each question points to.

1. Do you want an AI agent to call tools on your server? Yes: points to MCP. “Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools.” Status: Current revision 2026-07-28. Source: [MCP specification](https://modelcontextprotocol.io/specification/latest). Status source: [MCP versioning](https://modelcontextprotocol.io/specification/versioning). No: A no here does not point to MCP.
2. Do you want agents to learn about your MCP server before they connect to it? Yes: points to MCP server cards. An optional MCP extension: “a standardized, self-contained format to describe MCP servers for pre-connection discovery”. Status: SEP-2127: Final, Extensions Track. Source: [SEP-2127](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2127-mcp-server-cards.md). Status source: [SEP-2127](https://modelcontextprotocol.io/seps/2127-mcp-server-cards). No: A no here does not point to MCP server cards.
3. Do you want to describe your own agent service to other agents? Yes: points to A2A agent cards. A2A “is an open standard designed to facilitate communication and interoperability between independent, potentially opaque AI agent systems”; its agent card is “a self-describing manifest for an agent”. Status: Latest released version 1.0.0. Source: [A2A specification](https://a2a-protocol.org/latest/specification/). No: A no here does not point to A2A agent cards.
4. Do you want tools to run inside your web page, in the shopper’s browser? Yes: points to WebMCP. “Web pages that use WebMCP can be thought of as Model Context Protocol servers that implement tools in client-side script instead of on the backend.” Status: Draft Community Group Report, 20 October 2026; not a W3C Standard. Source: [WebMCP draft](https://webmachinelearning.github.io/webmcp/). No: A no here does not point to WebMCP.

If your store runs on a platform, most of these are questions for the platform or for whoever builds the store.

- Does it run an MCP server for your store? At what address, and which tools does tools/list return to a caller that has not signed in?
- Does it publish an MCP server card, or an AI Catalog at `/.well-known/ai-catalog.json`? Both are optional, and the document that gives the catalogue's address is marked draft.
- If you run an A2A agent, open `https://your-domain/.well-known/agent-card.json`. The specification requires a server to make a card available, gives that address as one of three routes, and allows the card to be signed.
- If your store has a UCP profile at `/.well-known/ucp`, look at the transports declared under `services`. `mcp` and `a2a` are two of the four values.
- If your store supports ACP, does it offer the MCP binding as well as REST?
- Does any script on your pages call `document.modelContext.registerTool`? These tools exist only while the page's script runs, so a fetch of the HTML that does not run its scripts gets no registered tools, though the call itself may be visible in the source.

## What is not settled

- MCP's core specification defines no discovery file. Server cards are an optional extension marked Final, the document that gives the AI Catalog's address is marked draft, and the cards leave out tools on purpose.
- A2A's specification page says 1.0.0, and the latest GitHub release is v1.0.1. Signing an agent card is allowed, not required.
- WebMCP is a Draft Community Group Report and says it is not a W3C Standard. Its declarative API is outside the specification, and the specification defines no well-known address or manifest for a page's tools.
- ACP's MCP binding covers checkout only. Delegated payment over MCP is left to a later proposal.

Finding what a store offers is the third wall in [the hub](https://storewalk.ai/blog/why-agents-cant-buy), and [How agents discover what a store offers](https://storewalk.ai/blog/how-agents-discover-a-store) covers the well-known addresses that agent cards and AI Catalogs use.

## Sources

- [MCP specification](https://modelcontextprotocol.io/specification/latest)
- [MCP specification: versioning](https://modelcontextprotocol.io/specification/versioning)
- [MCP specification 2026-07-28: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)
- [MCP specification 2026-07-28: Discovery](https://modelcontextprotocol.io/specification/2026-07-28/server/discover)
- [MCP specification 2026-07-28: Authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)
- [MCP SEP-2127: Server Cards](https://modelcontextprotocol.io/seps/2127-mcp-server-cards)
- [MCP SEP-2127: Server Cards (source file)](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2127-mcp-server-cards.md)
- [MCP server-card extension: discovery (draft)](https://github.com/modelcontextprotocol/ext-server-card/blob/main/docs/discovery.md)
- [A2A specification](https://a2a-protocol.org/latest/specification/)
- [A2A protocol site](https://a2a-protocol.org/latest/)
- [A2A releases on GitHub](https://github.com/a2aproject/A2A/releases)
- [WebMCP, Draft Community Group Report](https://webmachinelearning.github.io/webmcp/)
- [WebMCP README](https://github.com/webmachinelearning/webmcp/blob/main/README.md)
- [Stripe docs: agentic commerce](https://docs.stripe.com/agentic-commerce)
- [UCP specification overview](https://ucp.dev/latest/specification/overview/)
- [ACP MCP binding (OpenRPC), 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openrpc/openrpc.agentic_checkout.json)
- [ACP: MCP transport binding for Agentic Checkout](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/docs/mcp-binding.md)
- [ACP changelog, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/changelog/2026-04-17.md)
- [AP2 home page](https://ap2-protocol.org/)
- [AP2 specification](https://ap2-protocol.org/ap2/specification/)

Last checked 22 Oct 2026