A protocol is an agreement about how software communicates. It is not an audience. Before choosing one, name the application that will consume it, the task it improves, and the way a customer gains access. The useful architecture is usually a small set of compatible interfaces around a reliable product.
The map
| Interface | The job it describes | The business question |
|---|---|---|
| OpenAPI | An HTTP API's operations, inputs, outputs, and authentication contract | Can a developer or agent understand our API? |
| MCP | Tools and context exposed to compatible AI applications | Which hosts will connect, and through what installation path? |
| WebMCP | Website functionality exposed through a supporting browser | Which supported browser workflow becomes easier? |
| A2A | Communication and task exchange between agents | Are we providing an actual agent service that others delegate to? |
| ACP | A checkout interface for compatible commerce participants | Is the intended buyer surface able to transact with us? |
| UCP | Commerce capabilities and interoperable business interactions | Which business and platform capabilities overlap? |
| AP2 | Evidence of authorization for agent-mediated payments | What was the agent authorized to buy or pay? |
| ARD | Publishing and finding descriptions of agentic resources | Which discovery consumer will ingest and retrieve our entry? |
These rows describe different layers, not competing brand names for one universal standard. The linked primary documentation defines their actual requirements. Google's protocol overview is a useful starting map; use the protocol's own versioned specification for implementation.
Start with the interface you already need
A software company may first need complete HTTP documentation, a small SDK example, and a consistent authentication path. MCP can then make a useful workflow available to a defined host ecosystem. A service business may need a reliable inquiry or booking page; publishing an agent card is unnecessary if there is no agent service behind it.
A merchant should separate product-data accuracy from transaction support. ACP's stated focus is compatible agent checkout. UCP describes business profiles and capabilities. Neither removes the merchant's responsibility for prices, stock, fulfillment, and valid authorization. A working payment interface does not itself explain why a buyer would discover your product.
Discovery is an overloaded word
Web search finds source pages. A catalog helps a host find integration metadata. A known MCP server describes its capabilities. A2A can describe an agent that another agent might contact. ARD describes a broader resource discovery layer. These are different starting points.
Ask what was known before the lookup. If the endpoint was already supplied, you tested capability retrieval. If the vendor was not named and the environment independently encountered it, you have evidence about distribution. This distinction prevents technically successful demos from becoming misleading acquisition claims.
Compatibility needs a named consumer
Chrome documents WebMCP as an origin-trial feature; retain a standard web fallback. MCP has versioned behavior and host-specific support. Merchant protocols also have account and participant requirements beyond a document conforming to a schema. “Supports the standard” is incomplete without a version, transport, authentication setup, and tested consumer.
Use a compatibility record with these fields: provider release, client release, protocol revision, transport, authentication method, task, expected result, actual result, and test date. Mark untested cells as unknown. Do not turn a supported schema field into a claim that every host implements it.
An investment rule
Build when a named group of customers can reach the interface, it removes a measured failure, and you can maintain it. Experiment when adoption is uncertain but a small prototype can answer the question. Defer when there is no consumer, no working product underneath, or a more basic access failure.
The goal is a customer completing a useful task. Protocol support is one means of reaching that goal. The software playbook and commerce guide translate this map into concrete decisions.
Primary sources
Put the next step to work.
Find your starting point