phase: [1] status: Publication-ready (PR) draft — composition reference authored: 2026-05-21 authority: standards/webgcporg/CLAUDE.md (engineer-to-engineer prose; peer-documents rule) publishes_to: webgcp.org/composition/ (proposed path; deploy when ready) license: spec text CC-BY-4.0; schemas + fixtures Apache-2.0

External supporting protocols — paired with webGCP

Audience: implementers asking "if I already use MCP / WebMCP / AP2 / x402 / A2A, where does webGCP fit?" + standards-body reviewers checking webGCP's composition claims against the actual external specs.

TL;DR. webGCP is the protocol layer between discovery and settlement. It composes with — does not replace — the major-vendor wire standards. This document gives the wire-level pairing for each one.

Audit history (2026-05-21). First-publish version of this doc carried per-cell MUST/SHOULD claims in §9 that were not all backed line-by-line by source authority. Audit pass on 2026-05-21 tightened claims to one of three states: (a) cite the specific source MUST in v0.1 or v0.2-candidate, (b) downgrade to SHOULD/MAY where the source only implies, or (c) flag explicitly as v0.2+ candidate scope (not yet v0.1 normative). No claim in this doc adds new authority; every assertion either cites a normative MUST in source or is marked as composition guidance.

0. The composition principle

webGCP layers. It does not rebuild upstream.

Layer Owner Concern
Discovery DNSAID / SEP-1649 / WebMCP "Where is the agent?"
Transport MCP / WebMCP "How do I call it?"
Protocol webGCP "What does the call carry?"
Settlement x402 V2 "How is it paid for?"
Authorization AP2 "Who authorized this invocation?"
Cross-vendor agent fabric A2A "How do agents talk to each other?"

Each row is an existing standard; webGCP is the protocol row. The pairings below show how the layers meet.

The locked positioning frame: "building the registry, settlement, and reputation infrastructure that the MCP ecosystem currently lacks" (per brainstorming/arch/session-research-2026-05-13.md §8). Every pairing in this doc reflects that frame.

1. MCP × webGCP

What MCP specifies

Model Context Protocol — Anthropic Foundation, governance Jan 2026. Five-vendor co-governance. The callable transport for AI tools: tools/list, tools/call, resources/read, prompts/get, sampling/createMessage. JSON-RPC over stdio or HTTP+SSE.

What webGCP adds when paired

MCP defines how to call; webGCP defines what's in the response body. An MCP tools/call to a webGCP-conformant server returns a typed bundle with applicability gating, provenance _meta, idempotency-key honoring, ACL-at-retrieval (absent-not-masked), and content-addressed identifiers.

Wire example

MCP request (standard MCP):

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "local_search",
    "arguments": {
      "query": "refund policy for retail orders",
      "idempotency_key": "ik_2026-05-21_a3b4c5"
    }
  }
}

MCP response carrying a webGCP bundle:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [{
      "type": "text",
      "text": "<webGCP bundle below>"
    }],
    "_meta": {
      "webgcp": {
        "kb_id": "urn:webgcp:myparallel:skill:refund-triage-v3",
        "kb_version": "v3.2.1",
        "manifest_hash": "sha256-7c2f...",
        "bundle_hash": "sha256-9d1a...",
        "provenance": {
          "source_uri": "urn:webgcp:myparallel:knowledge:refund-policy-2024q3",
          "freshness": "2026-05-20T14:00:00Z",
          "content_origin": "first-party"
        },
        "applicability": "in_scope"
      }
    }
  }
}

The _meta.webgcp block is what an MCP server adds when it implements webGCP. Everything outside that block is standard MCP. An MCP client that doesn't know webGCP can still consume the call — it just gets the content[].text and ignores _meta.

Conformance

Where in catalog1

2. WebMCP × webGCP

What WebMCP specifies

WebMCP — W3C Community Group draft (Apr 2026). A manifest pattern for advertising MCP server availability on a web property. Four-method API: registerTool, unregisterTool, provideContext, requestUserInteraction. The web page hosts (or links to) an MCP server; the manifest tells crawlers + agents where it is.

What webGCP adds when paired

WebMCP says "there's an MCP server here." webGCP says "and here's the typed protocol it speaks." A WebMCP-discoverable server can also be webGCP-conformant if it publishes the descriptor at .well-known/webgcp + carries the §5 bundle contract.

Wire example

WebMCP manifest (standard):

<link rel="webmcp" href="https://example.com/webmcp/manifest.json">

The manifest at that URL:

{
  "$schema": "https://webmcp.org/manifest/v0.1.json",
  "name": "example-refund-agent",
  "tools": [
    {
      "name": "local_search",
      "endpoint": "https://example.com/mcp",
      "description": "Refund policy retrieval"
    }
  ],
  "webgcp": {
    "spec_version": "v0.1",
    "descriptor": "https://example.com/.well-known/webgcp",
    "level": "L1",
    "features": ["applicability_gating", "provenance_meta", "idempotency"]
  }
}

The webgcp block in the manifest is the opt-in pairing: any WebMCP consumer that knows webGCP can route to the typed protocol; consumers that don't, see a regular MCP tool.

Conformance

Where in catalog1

3. SEP-1649 × webGCP

What SEP-1649 specifies

SEP-1649 is the MCP Server Discovery Convention — a .well-known/mcp.json route on any host advertising "I have an MCP server here." Reuses the IETF .well-known URI scheme.

What webGCP adds when paired

SEP-1649 advertises an MCP server's existence at /.well-known/mcp.json; webGCP advertises the typed-protocol server's existence at /.well-known/webgcp. Both descriptors can coexist on the same host — they describe the same server from two perspectives.

Wire example

SEP-1649 at https://example.com/.well-known/mcp.json:

{
  "name": "example-refund-agent",
  "version": "v3.2.1",
  "tools": [
    {
      "name": "local_search",
      "endpoint": "https://example.com/mcp"
    }
  ]
}

webGCP at https://example.com/.well-known/webgcp:

{
  "name": "example-refund-agent",
  "role": "webgcp-server",
  "spec_version": "v0.1",
  "kbs": [
    {
      "kb_id": "urn:webgcp:example:skill:refund-triage-v3",
      "version": "v3.2.1"
    }
  ],
  "endpoints": {
    "query": "https://example.com/mcp",
    "manifest": "https://example.com/webgcp/manifest"
  },
  "conformance_level": "L1"
}

The two descriptors share the endpoints.query URL — same MCP server, two discovery surfaces.

Conformance

Where in catalog1

4. AP2 × webGCP (Commerce Layer; v0.2+)

What AP2 specifies

Agent Payments Protocol — Linux Foundation x402 working group. Mandate-signing protocol for agent payments. A mandate_ref is an EdDSA-signed authorization from the principal (the user or org) to the agent, scoped to a payment or class of payments.

What webGCP adds when paired

webGCP v0.2 receipts (Commerce Layer per ADR-0001) carry the AP2 mandate reference in the invoker block. webGCP records that an invocation happened; AP2 records who authorized it. They compose: per v0.2-candidate §5.12 receipt schema, the invoker.mandate_ref field references an AP2 mandate. The MUST is on receipt emission at L2+, not on AP2 per se — but if you emit receipts (L2+ MUST), the schema includes AP2 fields.

Wire example

webGCP v0.2 receipt fragment (per webgcp-v02-candidate.md §5.12):

{
  "receipt_id": "urn:webgcp:receipt:sha256-abc...",
  "issuer": "urn:webgcp:server:example.com",
  "issuer_sig": "<EdDSA over receipt body>",
  "request": {
    "kb_id": "urn:webgcp:example:skill:refund-triage-v3",
    "invoker": {
      "principal_id": "urn:user:alice@example.com",
      "mandate_ref": "urn:ap2:mandate:m_2026-05-21_abc123",
      "ap2_signature": "<EdDSA signature over mandate body — verifiable independently>"
    }
  },
  "response": { "...": "..." },
  "settlement": { "...": "..." }
}

The invoker.mandate_ref is a URN that resolves to the AP2 mandate; the ap2_signature is the EdDSA proof. Anyone can verify: fetch the mandate, verify the signature against the principal's known key, confirm the invocation was authorized.

Conformance

Where in catalog1

5. x402 V2 × webGCP (Commerce Layer; v0.2+)

What x402 V2 specifies

x402 V2 — Linux Foundation. HTTP 402 + stablecoin settlement. Payment URIs encode (facilitator, asset, amount, payer); facilitators (Circle, self-hosted) confirm the payment.

What webGCP adds when paired

webGCP v0.2 receipts carry a settlement.x402_uri field with a v2 payment URI. Settlement is out-of-band: the server records the URI; the payer satisfies it via their wallet; the facilitator confirms. webGCP records that it happened; x402 is the wire-level payment.

Wire example

webGCP v0.2 receipt settlement block:

{
  "settlement": {
    "x402_uri": "x402:base:usdc:0xfc3b62...?amount=100&payer=urn:user:alice",
    "amount_nano_usdc": 100,
    "facilitator": "circle",
    "facilitator_confirmation": {
      "tx_hash": "0x4a7c...",
      "confirmed_at": "2026-05-21T14:23:00Z"
    }
  }
}

The x402_uri is the v2 payment URI; the facilitator_confirmation block records the on-chain confirmation. webGCP does not re-specify x402; it embeds the URI and records the result.

Compile-once / serve-many economics (resolves §12 #7 from v0.1): when a KB version is published once but served N times, each invocation's receipt records amount_nano_usdc. Authorship economics (refactor-author royalty per webGCP-network.md N7) is a roll-up at the receipt batch level, not per-receipt; specified at Commerce Layer §5.13.

Conformance

Where in catalog1

6. A2A × webGCP

What A2A specifies

Agent-to-Agent — Google. Cross-vendor agent fabric over the Vertex AI ecosystem. Agent cards (descriptors); message passing; capability discovery; auth federation. Companion to AP2 (which lives in the same Google repo).

What webGCP adds when paired

A2A is the cross-vendor agent fabric; webGCP is the typed-protocol the discovered agent speaks. An A2A-discoverable agent can also be webGCP-conformant if its agent card declares the webGCP spec version + descriptor path.

Wire example

A2A agent card fragment (standard):

{
  "schema_version": "v1",
  "name": "example-refund-agent",
  "description": "Refund policy retrieval and triage",
  "capabilities": [
    {
      "name": "local_search",
      "endpoint": "https://example.com/a2a"
    }
  ],
  "extensions": {
    "webgcp": {
      "spec_version": "v0.1",
      "descriptor": "https://example.com/.well-known/webgcp",
      "level": "L1"
    }
  }
}

The extensions.webgcp block is the opt-in pairing, mirroring the WebMCP manifest pattern. An A2A consumer that knows webGCP routes to the typed protocol; consumers that don't, see a regular A2A capability.

Conformance

Where in catalog1

7. DNSAID × webGCP

DNSAID is a draft IETF spec (draft-mozleywilliams-dnsop-dnsaid-01, March 2026) — not yet adopted. webGCP v0.1's normative DNS-discovery MUST is at _webgcp.<host> SVCB (§5.1.1), NOT at DNSAID's _agents.<host>.

v0.1 §8.4 is "Forbidden federation behaviors", NOT a DNSAID profile. (Prior version of this doc cited "v0.1 §8.4 dual-publication" — that was a transcription error; corrected 2026-05-21.) The DNSAID composition pattern lives in ../positioning-dnsaid.md as a proposal, NOT in the v0.1 frozen spec.

Proposed dual-publication pattern (per positioning-dnsaid.md; not v0.1 normative):

; webGCP-native namespace (v0.1 §5.1.1 — MUST at L0+)
_webgcp.example.com.        SVCB  1  example.com.

; DNSAID-compliant namespace (proposed; awaits DNSAID adoption)
webgcp._agents.example.com. SVCB  1  example.com.

Conformance. webGCP servers MAY dual-publish at the DNSAID name as cheap insurance for IETF adoption. No webGCP MUST currently requires DNSAID. If DNSAID gets adopted by IETF DNSOP, future webGCP versions may add a SHOULD; today it's purely optional.

8. Composition matrix

The full picture, all seven pairings (every claim cites or downgrades to MAY):

External Layer What it owns What webGCP adds What v0.1 / v0.2-candidate actually says
MCP Transport tools/call JSON-RPC Typed bundle + _meta.webgcp in response v0.1 §1.3: "composes with"; no MUST. v0.2-candidate §1.5 Property 3: nodes expose contract per MCP/WebMCP (OR) at L1+ — implies L1+ SHOULD; v0.2+ scope.
WebMCP Discovery (web) <link rel="webmcp"> manifest webgcp block in manifest v0.1 §7.3: conditional MUST on webmcp_origin block when KB originates from WebMCP page. No level-based MUST/SHOULD.
SEP-1649 Discovery (.well-known) .well-known/mcp.json Sibling descriptor at .well-known/webgcp v0.1 §5.1: MUSTs webGCP's own descriptor at .well-known/webgcp at L0+. SEP-1649's .well-known/mcp.json itself is MAY at all levels.
AP2 Authorization mandate_ref + EdDSA signature invoker.mandate_ref in receipts (v0.2+) v0.1 §1.3: "consumes AP2 assertions in invoker identity field" — composition language, no MUST. v0.2-candidate §5.12: L2+ MUST emit receipts (unconditional); receipts include AP2 fields. v0.2+ scope.
x402 V2 Settlement Payment URI + facilitator confirmation settlement.x402_uri in receipts (v0.2+) v0.1 §1.3: "settlement-agnostic; carries x402 references when present" — permissive. v0.2-candidate §5.12 + §5.14: L0 MAY, L1 SHOULD if paid, L2+ MUST emit receipts unconditionally. v0.2+ scope.
A2A Cross-vendor fabric Agent card + message passing extensions.webgcp block in agent card NOT MENTIONED in v0.1 or v0.2-candidate. All pairing in this doc is composition guidance, no normative basis. MAY at all levels.
DNSAID DNS discovery _agents.<host> SVCB Proposed dual-publication (positioning-dnsaid.md) v0.1 §5.1.1 MUSTs _webgcp.<host> SVCB at L0+. DNSAID dual-publication is a proposal in positioning-dnsaid.md, NOT v0.1 normative. MAY at all levels.

9. Conformance level cheat sheet

Each cell cites the source MUST or is downgraded to SHOULD/MAY. Cells marked v0.2+ are candidate-scope; v0.2 publication is gated per webgcp-v02-candidate.md §5.

webGCP level MCP WebMCP SEP-1649 (.well-known/mcp.json) AP2 (v0.2+) x402 (v0.2+) A2A DNSAID
L0 Local MAY MAY (cond.¹) MAY MAY MAY MAY MAY
L1 Manifest SHOULD² MAY (cond.¹) MAY MAY SHOULD if paid³ MAY MAY
L2 Governed SHOULD² MAY (cond.¹) MAY MUST receipt-include⁴ MUST receipt-emit³ MAY MAY
L3 Federated SHOULD² MAY (cond.¹) MAY MUST receipt-include + cross-verify⁴ MUST receipt-emit + cross-verify³ MAY MAY
L4 Anchored SHOULD² MAY (cond.¹) MAY MUST receipt-include⁴ MUST receipt-emit³ MAY MAY

Footnotes (source citations):

The one unconditional MUST in v0.1 (frozen): L0+ MUST publish .well-known/webgcp descriptor (§5.1) AND _webgcp.<host> SVCB (§5.1.1). These are webGCP's own MUSTs; they do not derive from any external standard. Listed here for completeness but they're webGCP-native, not pairings.

What v0.2-candidate ships normative (when published): L1+L2 with receipt-emit MUSTs (footnotes ²/³/⁴). L3+L4 are design targets for v0.3+.

L4 is the design target for v0.3+; v0.1 ships L0; v0.2-candidate sketches L1+L2 with explicit candidate flag.

10. Worked end-to-end pairing

A single L2 webGCP invocation, tracing through every external protocol it touches:

  1. Discovery (DNSAID + SEP-1649 + WebMCP). Client resolves _webgcp.example.com. SVCB → finds host. Or fetches https://example.com/.well-known/webgcp directly. Or reads <link rel="webmcp"> from the page and follows the manifest.
  2. Auth (AP2). Client (acting on behalf of urn:user:alice) signs an AP2 mandate authorizing the agent to spend up to $X for refund-triage queries this session.
  3. Transport (MCP). Client makes MCP tools/call to the webGCP server, including the mandate reference in the request envelope.
  4. Protocol (webGCP). Server returns a typed bundle: applicability gated (CEL), provenance _meta, idempotency-key honored, ACL-at-retrieval applied.
  5. Settlement (x402 V2). Server emits a v0.2 receipt with settlement.x402_uri → client pays via wallet → facilitator confirms.
  6. Receipt chain (webGCP §5.12). Server signs the receipt; chains to any upstream bundles composed; client retains the receipt; if the principal later exercises right-to-delete (§5.15), the deletion fans out through this chain.
  7. Reputation rollup (webGCP §5.13). This receipt contributes to the per-kb_id rollup at the L2 server; reputation is recomputable from receipts deterministically (anti-collusion).

Every layer composes; no layer reinvents another.

What this doc is NOT

Cross-references

Composition reference. Six external protocols, six pairings, one stable principle: webGCP layers, it does not compete. When in doubt, cite the external spec; when extending, use the explicit pairing pattern shown here.

Permanent URL: https://webgcp.org/composition/.
Source: rendered from external-protocols-paired-with-webgcp.md in the maintaining catalog. Spec text under CC-BY-4.0.
Last rendered: 2026-05-21.