Protocol Integration
How legal context references embed in existing agentic commerce protocols via extension mechanisms and spec contributions.
This section is advisory.
This section describes how legal context references can be embedded in existing agentic commerce protocols. No protocol requires core specification changes. All integrations use existing extension mechanisms.
Approach
The protocols are structurally different, so a single wire format cannot apply everywhere. The LCP standard provides three conventions:
lcp:prefix — for string fields, a self-identifying format:lcp:{type}:{value}legalContextJSON key — for structured JSON metadata, a standard key withtypeandvaluefields- Raw bytes — for constrained fields (e.g., TIP-20's 32-byte memo), the raw content hash with no prefix
See Naming Conventions for the full specification.
Per-Protocol Guides
Each protocol integration specifies the exact field to use, the format (string prefix, JSON key, or raw bytes), when in the protocol flow it is set, size constraints, and how the receiving party reads and resolves the value.
| Protocol | Integration Point | Format | Page |
|---|---|---|---|
| MPP | 402 challenge + receipt | lcp: string + JSON | MPP |
| ACP | Checkout extension | JSON | ACP |
| x402 | extensions field + response header | JSON + Header | x402 |
| UCP | Checkout extension metadata | JSON | UCP |
| Visa TAP | Request body with linked signature | JSON (signed) | Visa TAP |
| A2A | Agent Card + task metadata | JSON | A2A |
| MCP | Tool annotations + descriptions | JSON | MCP |
| AP2 | Alongside mandates (A2A transport or AP2 extension) | JSON | AP2 |
| Mastercard Agent Pay | Verifiable Intent Layer 2 | SD-JWT credential | Mastercard |
Design Principle
LCP is complementary to every protocol in this table. It provides the legal layer that each defers. The protocols handle payments, checkout, and fulfillment. LCP handles terms, verification, and dispute resolution. The integration patterns show exactly where these layers connect.