Compose discovery with enrollment and payment

Division of responsibility

An Agent can encounter several protocols and integration surfaces after discovery. Each one answers a different question and remains authoritative for the behavior it defines.

The table deliberately includes more than protocols. An ODP Action describes a subsequent operation, MCP exposes a separate tool-oriented integration surface, and the target application executes the selected operation. ODP advertises these relationships without taking authority from the mechanism that defines each exchange.

Three layers working together

A protected, paid operation can combine three steps: discover it with ODP, obtain Service access with AEP, and satisfy its live payment requirement.

Advertisement versus enforcement

ODP provides advance signals, while the endpoint handling a request enforces its current requirements.

Advertising MPP or x402 does not mean every endpoint requires payment. An Offering's Price Preview also does not replace a live payment challenge.

Enrollment

Advertising AEP tells an Agent that the Service supports Agent enrollment.

The enrollment protocol independently defines Agent identity, enrollment, approval, credential grants, credential status, and revocation. ODP neither reproduces its Service Document nor selects a credential grant type.

Payments

A Service can advertise MPP, x402, or both through protocols.payments. It can also describe its preference, whether Service authentication is required first, and human-consumable compatibility options such as InFlow, Solana, Base, or Tempo.

These are discovery signals. The payment protocol remains authoritative for the actual method, network, asset, amount, and settlement requirements. See Pricing and payments for the boundary between an ODP Price Preview and live payment enforcement.

Trust protocols

A Service can advertise support for Visa Trusted Agent Protocol (TAP). This tells Agents that the Service can process TAP signals where they apply.

The advertisement does not prove Service ownership, authorize disclosure of consumer information, or replace TAP's request validation.

MCP and OpenAPI

A Service can advertise remote MCP Streamable HTTP endpoints through the Service Document's mcp array. MCP defines its tools, resources, prompts, authorization, and version negotiation. An MCP endpoint is not an ODP operation or Action.

An Action can use OpenAPI 3.1 when it needs a complete interface description. The Service Document can locate a default document through http.openapi, while an Action can override it. OpenAPI enriches the Action but is not required for basic ODP navigation or for expressing ODP authentication and payment semantics.

Common compositions

The following patterns illustrate common paths rather than an exhaustive list. A Service combines only the access and payment steps required by the selected Action and its live response.

Next steps