A2A: the store's agent

A2A: the store's agent

Some stores put an agent of their own in front of checkout. UCP Playground can send a run's checkout to that store agent over A2A, or send each message yourself in Inspect, and records every message each way.

What A2A is in UCP

A2A (Agent2Agent) is a protocol for agents to talk to each other in messages. UCP's A2A binding uses it for checkout: the buyer's agent sends checkout actions to the store agent, and the store agent answers with the checkout. Search and product lookup aren't part of the binding, so they stay on the store's MCP or REST.

  • The UCP profile lists a dev.ucp.shopping service with "transport": "a2a". Its endpoint is the store agent's agent card, usually at /.well-known/agent-card.json.
  • The agent card names the store agent, the A2A versions and JSON-RPC endpoint it serves, and UCP's extension, https://ucp.dev/{version}/specification/reference.
  • Each message turns the extension on with a header: X-A2A-Extensions over A2A 0.3, A2A-Extensions with A2A-Version: 1.0 over 1.0. It also carries UCP-Agent, signed as on MCP and REST.
json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "message/send",
  "params": {
    "message": {
      "role": "user",
      "kind": "message",
      "messageId": "3c7f199e-7f78-43ac-a5b3-c58411fc3272",
      "parts": [
        {
          "kind": "data",
          "data": {
            "action": "create_checkout",
            "line_items": [
              { "item": { "id": "bouquet_roses" }, "quantity": 1 }
            ]
          }
        }
      ]
    }
  }
}

A create_checkout message over A2A 0.3, as the Playground sent it to our test store. The store agent's reply carries the checkout in a data part named a2a.ucp.checkout.

Run one

On Runs, choose a store whose UCP profile lists A2A. Before you send, Runs reads the agent card and says what it found: the store agent's name, the A2A versions it offers and UCP's extension. Then open the How the agent reaches the store pill. Under UCP · how checkout goes pick Store agent · A2A 0.3, or A2A 1.0 when the card offers it. The pill reads UCP · A2A 0.3. MCP stays the default, and your choice is remembered with your other run settings.

A card that can't be used is shown struck out with the reason, for example a card without UCP's extension, or one that gives a UCP release date as its protocolVersion. A run never starts against it.

The agent searches over MCP (or REST). Its five checkout tools, create_checkout, update_checkout, get_checkout, cancel_checkout and complete_checkout, become messages to the store agent: one data part {"action": …} with the same fields as the REST binding's bodies, and the payment as a second data part, a2a.ucp.checkout.payment, on complete_checkout. When the store's MCP lists those tools, the agent sees the store's own descriptions, so a run over A2A differs from one over MCP only in how checkout travels.

The Playground passes the store agent's contextId back on every message, keeps a task's taskId until the task ends, and resends a message once with the same messageId after a 502, 503 or 504 or a dropped connection.

What you see

  • Chat: unchanged. The buyer sees the same messages, product cards, checkout and order as over MCP.
  • Trace: the agent card read is a Discovery line. The messages of one conversation (one contextId) sit under one heading, Conversation with the store agent, with the A2A version and method. A line reads as the action and the answer, such as update_checkout → ready_for_complete; a message sent again with the same messageId is tagged resent. Open a line to see where it went, its ids, the headers that turned A2A and UCP on, and the parts each way.
  • Discovery and negotiation: the agent card beside the UCP profile, the A2A versions offered and the one used, and whether the extension header activated UCP's extension. Show the card opens its endpoint, versions, streaming and push, sign-in and capabilities.
  • Info: the checkout and search transports, the A2A version, the agent card and the conversation.

Send messages yourself in Inspect

In Inspect, choose A2A under Calls go over, and its version. Checkout actions go to the store agent; search and product lookup go over MCP.

  • Forms: each action has a form, with the payment part as a toggle on complete_checkout. You can also send a plain text message.
  • Headers: the headers that turn A2A and UCP on are shown and can be switched off, so you can watch the store agent refuse a message without them (-32008), or ask for a version it doesn't speak (-32009).
  • The conversation is kept between calls. New conversation starts another, and Send again resends the last messageId. A Conversation tab shows the messages each way.
  • Discovery shows the agent card, readable or as received, with the checks the Playground makes before sending to it.

Try it on our test store

flowers-a2a.ucpsandbox.com is a Retail test store with a store agent. Its card offers A2A 0.3 and, asked with A2A-Version: 1.0, A2A 1.0, with UCP's extension required. Catalogue search is on its MCP and REST. It takes test cards only and nothing ships.

Tip

Run the same task with the same model twice on this store, once over MCP and once to the store agent, and compare the two runs: the steps, the answers and where each one ends.

What is recorded

Every message is kept whole with the run: the JSON-RPC request and reply, the headers, the message, context and task ids, and how many times it was sent. The agent card is kept as read. Secrets are shown as prefixes, and buyer details are redacted on shared pages. See Transport failures for what a refusal means.

Something wrong on this page?