webGCP as a webMCP profile — v0.2-profile (CANDIDATE)¶

Status: candidate-normative. This page defines the candidate architectural direction of webGCP: no longer a standalone protocol that composes with webMCP, but a profile of the webMCP family — the typed-context extension carried on webMCP's own surfaces. It was promoted from design-target on 2026-08-25, after its own promotion gates were measured closed against a live reference implementation running both surfaces. It is not normative: the frozen authority remains /spec/v0.1/, and normative publication of this profile is gated on a second, independent implementer. This URL hosts a candidate; the ratified profile will publish at a permanent versioned URL.

1. The inversion¶

Before (v0.1 + the v0.2 candidate): webGCP is the protocol row; webMCP is one of several optional discovery surfaces it "composes with." The pairing is a bolt-on webgcp{} block, MAY at every level; transport is deliberately neutral.

After (this profile): webMCP is the base standard; webGCP is a profile that rides webMCP's own extension points. There is no standalone webGCP surface to discover separately — a client that speaks webMCP discovers webGCP by reading its extension block; a client that doesn't sees a plain webMCP tool and degrades gracefully.

BASE STANDARD │ the webMCP family (manifest + document.modelContext + MCP JSON-RPC)
              │        │
PROFILE       │   webGCP = webMCP + the typed-context extension
              │        ├─ manifest:  tool entry + `webgcp{}` block          (discovery)
              │        ├─ browser:   document.modelContext descriptor ext    (in-page)
              │        └─ response:  tools/call result `_meta.webgcp` block  (the payload)
COMPOSES WITH │ x402 (settlement) · AP2 (authorization)  ← unchanged: composed, not based-on

"Composes with, does not compete" survives for settlement and authorization. It is dropped for webMCP only — webGCP no longer composes with webMCP; it is a profile of it.

Why. A standard's binding constraint is adoption. webMCP is a W3C Community Group draft (19 August 2026 Draft CG Report — an incubation, not a W3C standard) with a shipping browser implementation and browser-vendor engagement. An extension of an adopted base beats a new standalone standard on exactly that axis. The trade is webGCP's independence for webMCP's distribution.

2. The profile, defined¶

A webGCP server is a webMCP-family server that additionally honors the webGCP extension at three points — the same logical block (webgcp{} / _meta.webgcp) expressed in each surface's idiom.

2.1 Discovery — the webMCP manifest is the entry point¶

The webMCP manifest (linked from the web property, or carried in the server card) is the canonical discovery surface; each tool entry carries a webgcp{} block. The .well-known/webgcp descriptor is retained as a back-compat mirror — still served, still what the _webgcp.<host> SVCB record points at — but new implementers target the manifest.

// webMCP manifest — the canonical webGCP discovery surface (illustrative host)
{
  "name": "example-knowledge",
  "tools": [{
    "name": "create_attestation",
    "endpoint": "https://example.com/api/mcp",
    "description": "Create a verifiable attestation from readings",
    "webgcp": {
      "spec_version": "0.2-profile",
      "profile_of": "webmcp",
      "descriptor": "https://example.com/.well-known/webgcp",   // back-compat mirror
      "features": ["applicability_gating", "provenance_meta", "idempotency", "receipts"],
      "kb_id": "urn:webgcp:example:skill:attestation-v1",
      "kb_version": "v1.0.0"
    }
  }]
}

2.2 Browser — `document.modelContext` carries the extension¶

webMCP is browser-native, so a profiled tool registered in a page carries the extension on its descriptor, and the typed-context _meta.webgcp is available in the browser, not just server-side. (The API surface is document.modelContext; the navigator.modelContext spelling is the deprecated alias, removed at Chrome 150 — implementations should resolve through a single point that prefers the current surface.)

document.modelContext.registerTool({
  name: 'create_attestation',
  description: 'Create a verifiable attestation from readings',
  inputSchema: { /* … */ },
  _meta: {
    webgcp: { spec_version: '0.2-profile', profile_of: 'webmcp',
              kb_id: 'urn:webgcp:example:skill:attestation-v1' }
  },
}, { signal });   // AbortController unregisters

2.3 Response — `_meta.webgcp` is the typed-context payload¶

The response extension is the v0.1/v0.2 bundle _meta, promoted to the defining payload of the profile — identical whether the tool was invoked in-browser or via the MCP server:

{
  "content": [{ "type": "text", "text": "<typed bundle>" }],
  "_meta": {
    "webgcp": {
      "kb_id": "urn:webgcp:example:skill:attestation-v1",
      "kb_version": "v1.0.0",
      "bundle_hash": "sha256-…",           // content address of content[0].text
      "provenance": { "source_uri": "urn:webgcp:example:reading:…",
                      "freshness": "2026-08-25T00:00:00Z",
                      "content_origin": "first-party" },
      "applicability": "in_scope",
      "receipt_ref": null,                  // §5.12 receipts: MUST at L2+, MAY below
      "reputation": null                    // §5.13 projection when available
    }
  }
}

3. The degradation invariant (load-bearing)¶

Everything outside _meta.webgcp is valid webMCP. A webMCP-only client gets content[].text and ignores _meta. Conformance to webGCP never breaks conformance to webMCP — that is what "profile" buys and what "composes with" never could.

This is a measured property, not an assertion: the reference implementation passes a strip-and-validate checker (remove every webgcp block and _meta; the remaining surface must be a valid base webMCP manifest, tool list, and call result), and the checker itself ships negative controls proving it can fail. Implementers should hold themselves to the same discipline — a green result from an instrument that cannot report red is not evidence.

4. Re-leveled conformance (candidate)¶

The webMCP column moves from MAY-at-every-level to the spine. The webGCP-native surfaces (.well-known/webgcp, the _webgcp.<host> SVCB record) are retained as back-compat.

webGCP level	webMCP manifest	`webgcp{}` block	browser (`document.modelContext`)	`_meta.webgcp` on responses	receipts
L0 Reader	SHOULD	MUST-if-manifest	MAY	MUST (provenance + applicability)	MAY
L1 Compiled	MUST	MUST	SHOULD (if web-property)	MUST	SHOULD if paid
L2 Governed	MUST	MUST	SHOULD	MUST	MUST
L3 Federated	MUST	MUST	SHOULD	MUST + cross-verifiable	MUST + cross-verify
L4 Composable	MUST	MUST	SHOULD	MUST	MUST

Level names are the frozen v0.1 §4 names. This table is candidate text: no party may claim a level from it until its fixture set exists and passes — levels are fixture-backed claims, never self-assessments against a draft. The browser column is SHOULD only for nodes that are actually browser-embedded; a headless server has no page, which is conformant, not a gap — the manifest / server-card / agent-card path carries discovery for such nodes.

5. Substrate Property 3, revised¶

Property 3 (revised) — webMCP-family surfaces. Every node exposes a webMCP-family contract: a webMCP manifest entry advertising an MCP-callable endpoint (server-side) and/or a document.modelContext registration (browser-side), each carrying the webgcp{} profile block. The manifest is the canonical discovery surface; the .well-known/webgcp descriptor is a back-compat mirror.

The other substrate properties (content-addressed artifacts, typed URN nodes, payable invocations, the coordination/data-plane split) are unchanged — orthogonal to the transport binding. The prior "MCP or webMCP" OR-clause collapses: the webMCP family is the binding, with MCP JSON-RPC its server-side realization and document.modelContext its browser-side realization — two realizations of one base, not an OR.

6. Status, honestly¶

One reference implementation operates the full profile live: a webMCP manifest with webgcp{} blocks on every tool, an MCP server whose tools/call results carry _meta.webgcp, browser registration on the current API surface, and a passing degradation-invariant run. It is operated by the profile's authors — which is exactly why it is not enough for normative status.
Normative publication is gated on a second, independent implementer adopting the profile — the same bar the base standard's own ladder applies everywhere.
The webMCP dependency will be pinned at ratification to a specific draft (currently the 19 August 2026 Draft CG Report). webMCP is an incubating Community Group draft, not a W3C standard, and this page will track surface changes (the navigator.* → document.* rename happened inside one quarter; the profile assumes such churn will continue).
Open questions carried honestly: whether the .well-known/webgcp descriptor gets a deprecation horizon or stays a permanent mirror (default: permanent — it is cheap); and confirming the family framing at L3, where cross-server receipt verification rides the MCP realization, not the browser (it does — documented so the browser-native framing is not misread as "everything is in the browser").

Questions and second-implementer interest: /contact/ · ops@webgcp.org.

Candidate URL: https://webgcp.org/spec/v0.2-profile/ — the ratified profile will publish at a permanent versioned URL.
Source: rendered from webgcp-v02-profile-public.md in the maintaining catalog. Spec text under CC-BY-4.0.
Last rendered: 2026-08-25.