Naming Conventions

This section is advisory.

Naming Conventions

The agentic commerce protocols are structurally different, so a single wire format cannot apply everywhere. The LCP standard defines three conventions depending on the field type.

String Fields: The lcp: Prefix

For string fields, use the lcp: prefix with a type indicator:

lcp:{type}:{value}

Self-identifying — any parser checks startsWith("lcp:"), then reads the type to know how to resolve the value.

Parsing rule: Split on the first colon to get lcp (the namespace). Split on the second colon to get the type. Everything after the second colon is the value (which may itself contain colons, e.g., in URLs).

Structured JSON: The legalContext Key

For structured JSON fields where the carrier admits a structured object (a session metadata map, a task metadata block, an extension object), use a standard key — "legalContext" — with type and value fields:

{
  "legalContext": {
    "type": "sha256",
    "value": "0x7f83b165..."
  }
}

Raw Byte Fields

Where the carrier is a fixed-width byte string with no room for prefix or structure, the LCP reference is the raw atrHash bytes. The carrier's own conventions define how the value is interpreted; placement and length are specified in an external profile document or in the relevant per-protocol illustration.

MCP Resource URIs: The lcp:// Scheme

Where the carrier is an MCP resource URI scheme, deployments MAY use the lcp:// URI scheme to expose LCP records as readable resources. The lcp:// scheme is distinct from the lcp: prefix used in string fields above; the URI form is appropriate where the carrier expects a fully-qualified URI rather than a self-identifying string. See MCP Integration for indicative resource URI shapes such as lcp://legal-context/{domain} and lcp://agreement/{id}. The MCP stewards are invited to publish authoritative resource URI conventions.

Known Types

The type set is extensible and is not closed. Implementations SHOULD ignore types they do not recognize. Additional types MAY be defined by deployments; implementers are encouraged to publish type extensions in their own documentation rather than canonizing them in this standard.