Agent Protocols
PEAC provides mappings for major agent communication protocols. Each mapping is a pure transform -- it takes protocol-specific input and produces a standardized PEAC extension object that you attach to a receipt.
Supported protocols
| Protocol | Package | Description | Status |
|---|---|---|---|
| MCP | @peac/mappings-mcp | Model Context Protocol (tool calls, resources) | Stable |
| ACP | @peac/mappings-acp | Agentic Commerce Protocol (commerce evidence) | Stable |
| A2A | @peac/mappings-a2a | Agent-to-Agent metadata and Agent Card discovery (v1.0.0 compatible) | Stable |
| TAP | @peac/mappings-tap | Visa Trusted Agent Protocol | Stable |
| UCP | @peac/mappings-ucp | Universal Commerce Protocol | Stable |
| RSL | @peac/mappings-rsl | Rights Specification Language | Stable |
| AIPREF | @peac/mappings-aipref | IETF AI Preferences vocabulary | Stable |
MCP (Model Context Protocol)
Map MCP tool calls to PEAC receipts. The mapping captures tool identity, call arguments (hashed for privacy), result metadata, and timing information.
pnpm add @peac/mappings-mcp
import { fromMcpToolCall } from '@peac/mappings-mcp';
const evidence = fromMcpToolCall({
toolName: 'search',
toolServer: 'https://tools.example.com',
arguments: { query: 'AI safety' },
result: { hits: 42 },
});
The mapping extracts:
- Tool identity -- tool name and server origin
- Call arguments -- hashed by default for privacy
- Result metadata -- response shape and size
- Timing -- call duration and timestamps
MCP Server
The @peac/mcp-server package is a complete MCP server that exposes PEAC verification, inspection, and issuance as MCP tools. See the MCP Server guide for setup and usage.
ACP (Agentic Commerce Protocol)
Map ACP session lifecycle and payment observation events to PEAC receipts. The mapping enforces a strict two-function boundary: session lifecycle evidence is separate from payment observation evidence.
pnpm add @peac/mappings-acp
import { fromACPSessionLifecycleEvent } from '@peac/mappings-acp';
// Session/access evidence only
const sessionEvidence = fromACPSessionLifecycleEvent({
sessionId: 'session_abc',
event: 'completed',
});
import { fromACPPaymentObservation } from '@peac/mappings-acp';
// Commerce evidence requires explicit observed_payment_state
const paymentEvidence = fromACPPaymentObservation({
sessionId: 'session_abc',
observed_payment_state: 'settled',
});
A2A (Agent-to-Agent Protocol)
Carry verifiable evidence through A2A metadata in TaskStatus, Message, and Artifact objects. The mapping uses the Evidence Carrier Contract to attach receipt references and JWS signatures to A2A interactions. Compatible with A2A v1.0.0 and v0.3.0 via a dual-version transition normalizer.
pnpm add @peac/mappings-a2a
import { extractA2aCarrier, attachA2aCarrier } from '@peac/mappings-a2a';
// Attach evidence to an A2A artifact
const artifact = attachA2aCarrier(originalArtifact, {
receipt_ref: 'sha256:abc123...',
receipt_jws: 'eyJhbGciOiJFZERTQSIs...',
});
// Extract evidence from an A2A message
const carrier = extractA2aCarrier(incomingMessage);
Agent Card Discovery
A2A agents advertise PEAC support via the Agent Card capabilities.extensions array:
{
"capabilities": {
"extensions": [
"https://www.peacprotocol.org/ext/traceability/v1"
]
}
}
See the A2A integration page for the full discovery flow and metadata examples.
How mappings work
Mappings are pure functions with no I/O, no side effects, and no dependencies on protocol SDKs. They take protocol-specific input and return a PEAC extension object. This makes them safe to run in any environment -- server, edge, or browser.
The data flows through three stages:
Protocol event
|
v
Mapping function (pure transform)
|
v
PEAC extension object
|
v
Receipt (via issue or issueWire02)
Extension objects use reverse-DNS namespaced keys. In Wire 0.2, extensions are top-level under extensions:
{
"extensions": {
"org.peacprotocol/correlation": {
"trace_id": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4",
"workflow_id": "mcp-tool-call-123"
}
}
}
Extension registry
PEAC maintains advisory registries for tool call metadata. These registries define standard vocabularies so that different implementations describe the same operations consistently.
toolcall_op_types-- types of tool call operations (read,write,execute,query,subscribe)toolcall_resource_types-- types of resources accessed (api,database,file,network,compute)
See Registries for the full registry specification.