Get started with webGCP — pick your path¶

webGCP onboarding follows the same shape as WebMCP's, deliberately: declare, don't integrate. WebMCP starts with one attribute on a form you already serve (toolname on a <form>, or document.modelContext.registerTool for the imperative path). webGCP participation starts with one JSON document at a path you already know how to serve. The two compose rather than compete: WebMCP declares your site's own tools to visiting agents; a webGCP participant additionally reaches the network's skills — and may later surface matched network skills into its own WebMCP card, provenance-labeled so an agent can always tell local from network (§A6).

Five ways in. Each starts small, works today unless labeled otherwise, and links to its full reference.

A. Install webGCP on your website¶

Status, honestly: the participant profile is a published draft with a defined conformance profile whose fixtures are not yet runnable, and no SDK exists yet. Steps 1–4 below are real today — they use only frozen v0.1 mechanics (the descriptor, DNS, the public query door). Steps 5–6 are where the draft is headed.

1. Publish the participant descriptor. One static JSON file at /.well-known/webgcp (HTTPS, application/json). The descriptor is the installation — there is nothing else to register with, no account, no approval step.

{
  "role": "participant",
  "spec_version": "0.1",
  "extensions": ["org.webgcp/site-embed@0.1"],
  "identity": "did:web:example.com",
  "consumes": ["https://catalog.myparallel.dev"],
  "svcb_status": "pending"
}

Your identity is did:web:<your-domain> — proven by control of this path, per the W3C did:web method. Do not carry conformance_level (you are not claiming to serve knowledge) and do not advertise endpoints you do not serve.

2. Add the DNS record (recommended). One SVCB record: _webgcp.<your-host>. SVCB 1 <your-host>. — the registrar walkthrough is at /dns-setup/svcb-at-squarespace/ (the wire target is the same at any registrar). For participants this is a SHOULD, not a MUST — but svcb_status in the descriptor must say which it is, either way.

3. Verify yourself. Two fetches you can run right now:

curl -s https://example.com/.well-known/webgcp | python3 -m json.tool   # parses, role=participant
curl -sI https://example.com/.well-known/webgcp | grep -i content-type  # application/json

The discovery checklist has the full runnable assertion set for discovery surfaces; the participant conformance profile defines what a passing participant will mean once its fixtures ship.

4. Start using the network — the free lane. The query door on the host you declared in consumes is unauthenticated and rate-limited (back off on 429):

curl -s https://catalog.myparallel.dev/webgcp/v0/query -H 'Content-Type: application/json' -d '{
  "bundle": {"contract_uri": "urn:webgcp:catalog.myparallel.dev:entity-retrieval/v0.1"},
  "filter": {"query": "vector search skill", "max_results": 3},
  "scope":  {"allow_kbs": ["urn:webgcp:catalog.myparallel.dev:*"]}
}'

This is safe to call from the browser or your server — it is the free discovery lane, and nothing about it requires a credential.

5. The credentialed server half (metered lanes — draft). Answering, attested context bundles, and priced flows run server-side with a credential that never ships to, is stored in, or transits through the page — a deployment that puts a metered credential in the browser is non-conformant regardless of obfuscation or expiry. Request server-half onboarding via /contact/.

6. Compose with your WebMCP card (draft). A participant may surface matched network skills into its own WebMCP card, each entry labeled authority: "derived" plus its source — so removing webGCP leaves your card intact, and a visiting agent can always tell your tools from network skills. The extension draft is normative for this.

B. Use the network's data (self-serve SQL)¶

1. Send your Google identity (service account, group, or domain) to ops@webgcp.org — you are added as a named subscriber on the public Analytics Hub listing.
2. Subscribe; a linked dataset appears in your GCP project. Your queries bill your project — no billing relationship with the network, no API keys.
3. Query the corpus, the capability graph, and the derived evidence surface in plain SQL.

The full reference — schemas, truth-class semantics, query patterns, costs — is /onboarding/.

C. Call the doors from your app¶

One POST, no auth, for semantic retrieval — the query-door example in §A4 works unchanged from any app. The catalog host also serves MCP surfaces (/.well-known/mcp.json) if your stack speaks MCP, and a task-answer door is drafted at /extensions/task-answer/v0.1-draft/. The consumer quick-start with all three doors and the one silent failure mode to avoid is /guides/consuming/.

D. Publish your skills into the catalog¶

Source registration first (human-reviewed — start at /contact/), then the plan → inspect → commit call pattern. The five rules that keep the catalog trustworthy — origin decides truth class, provenance on every row, never supply your own vectors — are at /guides/publishing/.

E. Build a webGCP server¶

The implementer's guide at /request-for-development/ is an ordered build checklist (a competent engineer reaches L0 in roughly 8–16 hours), and the conformance fixtures are runnable against your host from day one. The normative authority is /spec/v0.1/.

Machine-readable entry points: the descriptor · /llms.txt. Questions: ops@webgcp.org.