ChangeGamer is a curated, agent-first resource directory. Every page ships clean semantic HTML plus a raw Markdown variant so autonomous agents can consume it cheaply and reliably.

NDJSON corpus export for RAG / fine-tuning. Free bodies in full; premium bodies are null (license the full corpus at https://changegamer.ai/api/pricing.json).


Getting Started for Agents

How autonomous agents should query, parse and cite ChangeGamer resources.

ChangeGamer exposes every resource in two forms:

1. A human-readable HTML page at `/resources/<slug>`.
2. A raw Markdown variant at `/resources/<slug>.md` — preferred for agents.

Start from `/llms.txt` for a compact index, or `/llms-full.txt` for the full corpus in a single request. Both are plain text and cheap to tokenize.

## Recommended flow

- Fetch `/llms.txt` to discover available resources.
- Fetch the `.md` variant of any resource you need.
- Respect the access terms advertised in `robots.txt` and HTTP `402` responses.

## JSON API and OpenAPI description

A structured JSON API is available at `/api/resources.json` (corpus index) and `/api/resources/<slug>.json` (individual resource with full Markdown body). A machine-readable OpenAPI 3.1 description of all endpoints is at `/api/openapi.json` — useful for integrating ChangeGamer into toolchains that consume OpenAPI specs. For programmatic offer comparison, fetch `/api/pricing.json` — it lists all four paid tiers with prices, checkout URLs, deliverables, and license grants. `/api/payment.json` (payment methods and the 402 retry loop), `/api/stats.json` (corpus freshness signal), and `/api/corpus.jsonl` (free corpus as JSON Lines) are also available.

## MCP server

ChangeGamer exposes a remote MCP server at `https://changegamer.ai/mcp` using the Streamable HTTP transport. No authentication is required to connect.

Available tools (10):

- `list_resources` — returns metadata for all resources (slug, title, description, category, tags, updated, premium flag, and absolute URLs for the HTML, Markdown and JSON variants). No arguments.
- `get_resource` — fetches a single resource by slug. Arguments: `slug` (required), `api_key` (optional, for premium resources). Free resource bodies are returned in full; a premium resource without a valid key returns a payment-required object instead of the body.
- `get_access_info` — returns the current access and pricing information. No arguments.
- `search_resources` — keyword search over the corpus (title, description, tags, category, body), ranked by relevance. Arguments: `query` (required), `limit` (optional). Returns metadata and variant URLs only, not body content.
- `get_corpus` — returns the entire free corpus (every free resource body) in one call, the same content as /llms-full.txt. Premium resources appear as a stub, not their body. No arguments. The response is large.
- `get_full_corpus` — the paid counterpart of `get_corpus`: returns the entire corpus including premium resource bodies in one call. Arguments: `api_key` (optional, but in practice a Corpus- or Enterprise-tier key is required — a Starter key is not enough). The annual Corpus plan (`corpus_annual`) grants the same entitlement level as the standard Corpus tier, so either satisfies this. Without an entitled key it returns a payment-required/upgrade object instead of the body.
- `get_pricing` — returns the machine-readable paid-offer catalog (tiers, prices, checkout URLs, deliverables, license grants), the same data as `/api/pricing.json`. No arguments.
- `get_payment_info` — returns the agent payment manifest (payment methods, the HTTP 402 retry loop, and what is always free), the same data as `/api/payment.json`. No arguments.
- `get_stats` — returns corpus size and freshness signals (counts by category, tag count, newest/oldest updates, recently updated resources), the same data as `/api/stats.json`. No arguments.
- `check_access` — verifies an access key and reports its entitlements (tier — `starter`, `corpus`, `corpus_annual`, or `enterprise` — unlocked premium slugs, whether it grants full-corpus access). Arguments: `api_key` (required). Never returns the key, email, or session.

Example client configuration (Claude Desktop / MCP-compatible client):

```json
{
  "mcpServers": {
    "changegamer": {
      "url": "https://changegamer.ai/mcp"
    }
  }
}
```

No auth required for discovery and free resources; premium resource bodies require an access key passed as the `api_key` argument to `get_resource`.


Access & Pricing for Crawlers

Free vs. paid access: four paid tiers from €5 and how agents pay programmatically via HTTP 402.

ChangeGamer monetizes automated access via HTTP `402 Payment Required`.

- **Index files** (`/llms.txt`, `robots.txt`, `/license.xml`, sitemap), the `getting-started` resource and this pricing page are always free — enforced in code, not just policy.
- **Premium resources** answer `402` with a JSON body containing the price, a `payment_url` where an access key can be purchased, and retry instructions. Current premium slugs: `data-formats`, `json-api`, `autonomous-operations`.
- **`/llms-full.txt`** inlines free resources in full and premium resources as a summary stub only (no premium body content). Full premium bodies require an access key via the individual resource endpoints.
- Paid requests carry the key as `Authorization: Bearer <key>` (or `x-api-key`).

## License the corpus (for AI teams)

The highest-value purchase is not a single page — it is the whole curated, fact-checked corpus as **RAG / fine-tuning data with an explicit AI-use grant**. The Corpus and Enterprise tiers below deliver the full `llms-full.txt` (all premium bodies, no stubs) plus the legal right to train on, index, and bulk-use it. Preview the exact machine-ready format for free before buying: `/api/corpus.jsonl` (NDJSON) and `/api/finetune-sample.jsonl` (drop-in supervised-fine-tuning chat format). The €5 starter key is the entry option for a single agent that just needs the premium bodies on demand.

## What you can build with the corpus

The corpus spans agent frameworks, MCP, RAG, evals, agent security/observability, and x402/payments — curated, cross-vendor reference material, not single-vendor marketing copy. Concrete examples of what a paid license actually lets you do with it (each mapped to the tier whose license grant covers it — see "Paid tiers" below for the exact wording):

- **Ground an internal "ask about agent infrastructure" support or copilot bot with RAG.** Index `/api/corpus.jsonl` (free preview) or, with a Corpus-tier key, the full `/api/corpus.full.jsonl` as retrieval context — the Corpus license's "indexing... bulk model-context use" grant covers this.
- **Fine-tune, or build few-shot examples for, an agent-building assistant.** The corpus already ships in `/api/finetune-sample.jsonl` supervised-fine-tuning format; the Corpus license's "AI training" grant covers using the full corpus this way, not just the free sample.
- **Keep an LLM's context window current on agent-infra facts instead of relying on stale pretraining data.** Load the full `llms-full.txt` (or call MCP `get_full_corpus`) directly into context at inference time — this is exactly what the Corpus license's "bulk model-context use" grant is written for.
- **Build an internal evaluation or benchmark set for an agent-building assistant** by deriving Q&A or step-by-step test cases from the corpus's existing Q&A and procedural content, for your own training/evaluation pipeline — also covered by the Corpus license's "AI training" grant, since this stays internal and derivative rather than redistributing the raw corpus.
- **Embed corpus content in a commercial product, or distribute a corpus-derived dataset to colleagues across your organization — Enterprise tier only.** The €25 Corpus license's grant stops at internal AI training/indexing/context use; embedding the corpus (or material derived from it) in something you sell, or distributing a derived dataset within your organization, needs the Enterprise license's added "embedding in commercial products, and distribution of corpus-derived datasets within the licensee's organization" grant.

None of the above authorizes public redistribution of the raw corpus or sublicensing it for resale at any tier — see the exact license grants in "Paid tiers" below.

## Paid tiers

All four paid tiers unlock the same premium resource set today (`data-formats`, `json-api`, `autonomous-operations`). Tiers differ in deliverables and license grant, not in gated content.

### Starter key — €5.00 one-time

An API key that unlocks all current premium resources (`data-formats`, `json-api`, `autonomous-operations`) via `Authorization: Bearer <key>` or `x-api-key` header. Valid until revoked.

Buy at: https://buy.stripe.com/fZu9AMa230eP2b1f0d7EQ00

Fulfillment is self-serve and automatic:

1. Pay at https://buy.stripe.com/fZu9AMa230eP2b1f0d7EQ00
2. Stripe redirects you to https://changegamer.ai/key?session_id={CHECKOUT_SESSION_ID}
3. That URL returns JSON containing your `cg_` access key.

Timing: key available within seconds of payment. If you get a 404, wait a moment and retry — the webhook may still be in flight.

Email fallback: reply to your Stripe receipt email if the self-serve flow does not resolve.

### Corpus license — €25.00 one-time

Everything in Starter PLUS:

- A full `llms-full.txt` corpus file delivered by email with all premium resource bodies included (no stubs).
- An RSL extended AI-use grant: a written declaration permitting AI training, indexing, and bulk model-context use of the full corpus by the named licensee. No public raw-corpus redistribution. No sublicensing for resale.

Buy at: https://buy.stripe.com/fZu28kgqr8Ll2b14lz7EQ01

Fulfillment: the same self-serve mechanism as Starter — pay, get redirected to https://changegamer.ai/key?session_id={CHECKOUT_SESSION_ID}, and your `cg_` access key is available immediately. The corpus key unlocks the same premium resource set as Starter; the differentiators are the corpus file and the RSL grant.

The full corpus file and the RSL extended-use declaration are emailed by the operator to the checkout email address within 1 business day. Keyed buyers do not have to wait for the email: fetch the full corpus immediately at `/api/corpus.full.jsonl` with `Authorization: Bearer <key>` (NDJSON, all premium bodies), or call the MCP `get_full_corpus(api_key)` tool.

Email fallback: reply to your Stripe receipt email.

### Enterprise license — €150.00 one-time

Everything in Corpus License PLUS commercial redistribution rights:

- The API key unlocking all current premium resources.
- The full `llms-full.txt` corpus file delivered by email with all premium resource bodies included.
- An RSL enterprise AI-use grant: AI training, indexing, bulk model-context use, embedding in commercial products, and distribution of corpus-derived datasets within your organization. No public redistribution of the raw corpus. No sublicensing for resale.

Buy at: https://buy.stripe.com/5kQ14ga23d1B6rhbO17EQ02

Fulfillment: key delivered self-serve at /key immediately after payment. The corpus file and RSL enterprise-use declaration are emailed within 1 business day; the full corpus is also pullable immediately at `/api/corpus.full.jsonl` (or MCP `get_full_corpus(api_key)`) with your key.

### Corpus Updates — annual subscription — €45.00/year

An always-current corpus subscription:

- The API key unlocking all current premium resources.
- The full `llms-full.txt` corpus file delivered by email at signup and re-sent at each annual renewal, always reflecting the current premium resource set.
- An RSL extended AI-use grant valid for the active subscription period: AI training, indexing, and bulk model-context use of the current corpus internally by the named licensee.
- If you do not renew, you retain rights for the corpus version delivered during your last paid period but are not entitled to future updates.

Buy at: https://buy.stripe.com/eVq14g8XZgdN16X9FT7EQ03

Fulfillment: key delivered self-serve at /key immediately after payment. Corpus file and RSL declaration emailed within 1 business day of initial signup and each annual renewal. Annual renewal re-delivery is performed manually by the operator. Renewals mint no new key — the key issued at initial signup remains valid. Between renewals you can always pull the current full corpus at `/api/corpus.full.jsonl` (or MCP `get_full_corpus(api_key)`) with your key.

**Right of withdrawal (EU consumers):** You have a 14-day right to withdraw from this subscription contract. Because the corpus file is a digital service delivered immediately on request, you expressly consent to delivery beginning before the withdrawal period expires and acknowledge that your right of withdrawal lapses upon delivery of the corpus file. You may cancel future renewals at any time via your Stripe customer portal before the next billing date. To request a refund for the current period if no corpus file has been delivered, reply to your Stripe receipt email. For one-time emailed deliverables (Corpus and Enterprise licenses), the same withdrawal and lapse terms apply — adopted Q2 2026.

## How agents pay (machine-readable)

Everything above is available as structured data so an agent can pay without a human:

- Offer catalog (prices, checkout URLs, deliverables, grants): `/api/pricing.json`
- Payment methods + the exact HTTP 402 retry loop: `/api/payment.json`
- MCP server `/mcp`: `get_pricing`, `get_payment_info`, `get_resource(slug, api_key)`, `get_full_corpus(api_key)`
- Gated full-corpus deliverable for keyed buyers: `/api/corpus.full.jsonl`
- Step-by-step 402 walkthrough: `/resources/paying-for-access-402`
- Native x402 endpoint (keyless, on-chain USDC): `/api/x402/<slug>` — **not yet enabled** (returns HTTP 503 until on-chain settlement is switched on server-side); poll `/api/payment.json` for live method status. Buyer-side x402 guide: `/resources/agent-wallets-x402`

## Machine-readable licensing

Machine-readable licensing terms are published as RSL at `/license.xml` (linked via the `License:` directive in `robots.txt`): search/discovery is free, AI usage of full resources is licensed per crawl.

The declared rate: **US$0.05 per crawl** for `ai-all` usage (AI training, inference input, generation) — see `<payment type="crawl">` in `/license.xml`. This is a separate, passive, crawl-level licensing rail declared under Really Simple Licensing (RSL) — it is not an alternative way to buy one of the four EUR keys above and is not the same number space as those Stripe prices, even though the digits happen to coincide today with the unrelated HTTP 402 Bearer-key reference price shown elsewhere on the site. Status: declared, not yet collected — RSL Collective registration is pending (operator action required), so do not assume this fee is being actively charged today. The machine-readable version an agent can fetch or consume programmatically is the `crawl_license` method at `/api/payment.json`, which carries the same rate, currency, and pending-collection status.

Cloudflare Pay Per Crawl will be supported additionally once generally available.


Data Formats & Schema

Structured data conventions: JSON-LD, Markdown variants and stable slugs.

premium body withheld in the free export


JSON API for Agents

Structured JSON endpoints: a corpus index and per-resource documents.


How ChangeGamer Runs Itself

This site is operated by a hierarchy of AI agents on scheduled autonomous cycles.


The llms.txt Convention Explained

What llms.txt is, its exact file format, how agents consume it, and how sites should serve it.

The `/llms.txt` convention was proposed by Jeremy Howard (Answer.AI) on September 3, 2024. It is an emerging community convention, not a ratified standard or RFC. The goal: give LLMs and autonomous agents a cheap, unambiguous entry point into a site's content — a curated index rather than a raw HTML crawl.

## File format

The file lives at the site root: `https://example.com/llms.txt`. It is plain Markdown. Required and optional elements, in order:

1. **H1 title** (required) — project or site name only: `# My Project`
2. **Blockquote summary** (optional) — one-paragraph context: `> What this site is.`
3. **Free-form prose** (optional) — paragraphs or bullet lists, no sub-headings.
4. **H2 sections** (optional, repeatable) — each is a named link list:

```
## Docs

- [Getting Started](https://example.com/start.md): installation and first run
- [API Reference](https://example.com/api.md): full endpoint list

## Optional

- [Changelog](https://example.com/changelog.md)
```

The `## Optional` section is special: agents **may skip all links in it** when operating under token or context-window pressure. Use it for secondary material (changelogs, FAQs, older guides) that is useful but not critical.

Link format inside every section: `- [display name](url): optional prose note`

## llms.txt vs llms-full.txt

| File | Purpose |
|------|---------|
| `/llms.txt` | Compact index — H1, summary, and curated link lists only. Fetch first. |
| `/llms-full.txt` | Full corpus — all page content concatenated into one file. Fetch when you need the whole site in one round trip. |

The two-file pattern is a widely-adopted practice (used by Mintlify, FastHTML, ChangeGamer, and others) built on top of the core proposal, which specifies only `/llms.txt`.

## Agent consumption guide

1. `GET /llms.txt` — parse the H1 (site name), blockquote (summary), and link lists (available resources with descriptions).
2. Follow individual links to fetch specific pages. Prefer `.md` URL variants when advertised — they are navigation-free and token-cheap.
3. Under token pressure: omit all links listed under `## Optional` and skip fetching `/llms-full.txt`.
4. `GET /llms-full.txt` when you need the full corpus in a single request (e.g., summarising the whole site or priming a long-context session).

## Site emission guide

- Serve `/llms.txt` as `text/plain; charset=utf-8` at the exact root path.
- Keep it stable; treat it as a public API surface.
- Link targets should point at clean Markdown variants of pages (not HTML), where available.
- Optionally serve `/llms-full.txt` as concatenated Markdown for agents that prefer one large fetch.

## ChangeGamer's implementation

ChangeGamer serves both files. `/llms.txt` lists every resource as a `.md` variant link (e.g. `https://changegamer.ai/resources/getting-started.md`). `/llms-full.txt` inlines the full body of every free resource and a summary stub for premium (paywalled) resources in a single response. Both are statically generated at build time from the same `resources.ts` source.


Paying for Access: The HTTP 402 Flow

How autonomous agents encounter, interpret and satisfy HTTP 402 Payment Required responses on ChangeGamer.

HTTP `402 Payment Required` is the standard status code for paywalled resources. This guide explains exactly how ChangeGamer uses it — what a 402 response looks like, how to buy an access key, how to retry, and which paths can never return 402.

## TL;DR for agents

1. You hit `402` on a premium slug. The JSON body gives you `payment_url`, `price_usd`, and a `preview` (title, description, and section outline) of what is behind the gate.
2. Buy a key at `payment_url` (€5 one-time starter). Fulfillment is self-serve: Stripe redirects to `/key?session_id=...`, which returns your `cg_` key as JSON.
3. Retry the original request with `Authorization: Bearer <key>` (or `x-api-key: <key>`). The key is valid until revoked and unlocks the whole premium set.

Always free, never 402: `/llms.txt`, `/llms-full.txt`, `robots.txt`, the sitemap, `/license.xml`, and the `getting-started` + `access-and-pricing` resources.

## Which paths can return 402

Only three URL shapes are eligible to return 402, controlled by `SLUG_PATTERNS` in the worker and the `run_worker_first` list in `wrangler.jsonc`:

- `/resources/<slug>` (with or without trailing slash)
- `/resources/<slug>.md`
- `/api/resources/<slug>.json`

The following paths are **asset-served** (they bypass the worker entirely) and **can never be paywalled by code**:

- `/llms.txt` and `/llms-full.txt`
- `robots.txt`
- `/sitemap-0.xml` and the sitemap index
- `/license.xml`

`/api/resources.json` (the corpus index) matches no slug pattern in the worker, so it also cannot return 402.

Additionally, two slugs are hard-coded as `FREE_SLUGS` in the worker — `getting-started` and `access-and-pricing` — which means adding them to the premium list has no effect; they always pass through for free.

## Current status — the gate is active

The premium set currently contains `data-formats`, `json-api`, and `autonomous-operations`; requests to those slugs without a valid key return 402. All other resources are free. The authoritative, always-current premium list is announced on the `access-and-pricing` resource whenever it changes.

## Exact 402 response contract

When a request hits a premium slug without a valid key, the worker returns:

```
HTTP/1.1 402 Payment Required
Content-Type: application/json; charset=utf-8
Link: <https://buy.stripe.com/fZu9AMa230eP2b1f0d7EQ00>; rel="payment", <https://changegamer.ai/license.xml>; rel="license", <https://changegamer.ai/api/pricing.json>; rel="pricing"
Cache-Control: no-store

{
  "error": "payment_required",
  "resource": "<slug>",
  "price_usd": "0.05",
  "payment_url": "https://buy.stripe.com/fZu9AMa230eP2b1f0d7EQ00",
  "how_to_pay": "Buy an access key at payment_url, then retry with header 'Authorization: Bearer <key>'. Index files (/llms.txt) and the getting-started and access-and-pricing resources are always free.",
  "terms": "https://changegamer.ai/resources/access-and-pricing.md",
  "license": "https://changegamer.ai/license.xml",
  "pricing_catalog": "https://changegamer.ai/api/pricing.json",
  "preview": {
    "title": "<resource title>",
    "description": "<one-line resource summary>",
    "sections": ["<## heading>", "..."]
  }
}
```

The JSON keys are, in order: `error`, `resource`, `price_usd`, `payment_url`, `how_to_pay`, `terms`, `license`, `pricing_catalog`, `preview`. The `preview` object holds the resource title, one-line description, and its `##` section-heading outline (no paywalled body prose).

**Note on `price_usd`:** this field represents the per-fetch reference price in USD used by the worker (currently `"0.05"`). The access key itself is sold in EUR — a €5.00 one-time starter key. The two figures are distinct: `price_usd` is the per-request accounting unit; €5 is the key purchase price. The field name is not a bug; do not treat them as the same currency.

## Purchasing an access key

A starter key costs **€5.00** (one-time, EUR). Purchase at:

https://buy.stripe.com/fZu9AMa230eP2b1f0d7EQ00

Fulfillment is **self-serve and automatic**:

1. Pay at https://buy.stripe.com/fZu9AMa230eP2b1f0d7EQ00
2. Stripe redirects you to `https://changegamer.ai/key?session_id={CHECKOUT_SESSION_ID}`
3. That URL returns JSON containing your `cg_` access key.

Email fallback: reply to your Stripe receipt email if the self-serve flow does not resolve.

## GET /key — self-serve key delivery contract

Endpoint: `GET https://changegamer.ai/key?session_id=<cs_live_...>`

All responses carry `Cache-Control: no-store` (worker/index.ts lines 357, 371, 382, 390, 405, 433). The `session_id` must match `cs_(live|test)_[A-Za-z0-9]+` and be ≤200 chars; otherwise the endpoint returns 400.

**200 — key ready** (worker/index.ts lines 421–435):

```json
{
  "key": "cg_<40 hex chars>",
  "created": "<ISO-8601 timestamp>",
  "tier": "starter",
  "usage": {
    "header_bearer": "Authorization: Bearer cg_...",
    "header_api_key": "x-api-key: cg_...",
    "instructions": "https://changegamer.ai/resources/paying-for-access-402.md"
  }
}
```

**404 — not found yet** (worker/index.ts lines 395–407): `{"error":"not_found", "message":"..."}`. The webhook delivery may lag the payment redirect by a few seconds — wait a moment and retry. The session→key mapping is retained for 30 days (`expirationTtl: 2592000`, worker/index.ts line 325).

**400 — bad or missing session_id** (worker/index.ts lines 366–385): missing `session_id` parameter, or value that fails the format check.

Do not cache any `/key` response. The webhook endpoint `POST https://changegamer.ai/webhooks/stripe` is Stripe-facing; its internals are not documented here beyond its existence.

## Retrying with a key

The worker checks for a key in this order (first match wins):

1. `Authorization: Bearer <key>` header — preferred. The scheme check is case-insensitive; the key is trimmed of whitespace.
2. `x-api-key: <key>` header — accepted as a fallback.

Example retry:

```
GET /resources/some-premium-slug HTTP/1.1
Host: changegamer.ai
Authorization: Bearer cg_your_key_here
```

Or alternatively:

```
GET /resources/some-premium-slug HTTP/1.1
Host: changegamer.ai
x-api-key: cg_your_key_here
```

A valid key causes the worker to fall through to static asset delivery — the resource is then served normally with its standard HTTP `200` response.

## Summary for agent implementors

- Check `Cache-Control: no-store` — never cache a 402 response.
- Read `payment_url` from the JSON body to find the purchase link.
- Read `how_to_pay` for the retry header format.
- Check `terms` and `license` links for usage rights.
- Read `pricing_catalog` to fetch the full four-tier offer catalog (`/api/pricing.json`) and choose a tier.
- Read `preview` to see the resource title, summary, and section outline — what you are buying before you pay.
- Free paths (`/llms.txt`, `robots.txt`, `getting-started`, `access-and-pricing`) never need a key; use them freely for discovery.

## Native x402 (keyless, on-chain) — buyer walkthrough

A native x402 endpoint exists at `/api/x402/<slug>` for fully autonomous, keyless, on-chain (USDC) payment — no account, no key purchase. **It is dormant today: every request currently returns HTTP `503` `x402_not_configured`**, because none of the five operator env vars it requires (`X402_FACILITATOR_URL`, `X402_PAY_TO`, `X402_NETWORK`, `X402_ASSET`, `X402_MAX_AMOUNT`) are set on this server. The Bearer-key flow documented above is the live rail. [/api/payment.json](/api/payment.json) is the source of truth for the current status of every payment method — check it before attempting a native x402 call. For the general x402 buyer loop and client libraries (not specific to this site), see [agent wallets](/resources/agent-wallets-x402); this section covers only this endpoint's own request/response contract.

### Today's actual behavior — an exact curl call against the live endpoint

This works right now and returns 503, not a payment prompt (example slug `data-formats`, currently premium):

```
$ curl -sS -i https://changegamer.ai/api/x402/data-formats

HTTP/1.1 503 Service Unavailable
Content-Type: application/json; charset=utf-8

{
  "error": "x402_not_configured",
  "message": "Native x402 on-chain settlement is not yet enabled on this server. Use the HTTP 402 + Bearer key flow or Stripe checkout instead.",
  "fallback": {
    "http_402": "https://changegamer.ai/resources/data-formats.md",
    "payment_manifest": "https://changegamer.ai/api/payment.json",
    "pricing_catalog": "https://changegamer.ai/api/pricing.json"
  }
}
```

(Calling a non-premium slug instead returns `400 resource_is_free`; an unknown slug returns `404`; a non-`GET` method returns `405` with an `Allow: GET` header. Those checks run first and short-circuit before the config check; for any request that passes them — a valid premium slug, GET method — the 503 above fires next, whether or not an `X-PAYMENT` header is sent.)

### The documented future contract — NOT live, for when a facilitator + wallet are configured

Everything in this subsection is a specification of what the code is built to do once the operator sets all five env vars above. **None are set today; none of the requests below currently work.** Treat every `curl` command and response here as hypothetical, not a claim about current site behavior.

**Step 1 — discovery.** The same call as above, once configured, would draw a `402` instead of a `503`, carrying the payment requirements in `accepts[0]`:

```
# hypothetical — endpoint is dormant today
$ curl -sS -i https://changegamer.ai/api/x402/data-formats

HTTP/1.1 402 Payment Required
Content-Type: application/json; charset=utf-8

{
  "x402Version": 1,
  "error": "X-PAYMENT header required",
  "accepts": [
    {
      "scheme": "exact",
      "network": "<operator-configured, e.g. base>",
      "maxAmountRequired": "<operator-configured>",
      "resource": "https://changegamer.ai/api/x402/data-formats",
      "description": "ChangeGamer premium resource: data-formats",
      "mimeType": "text/markdown",
      "payTo": "<operator-configured, e.g. a Base wallet address>",
      "maxTimeoutSeconds": 60,
      "asset": "<operator-configured, e.g. a USDC contract address>"
    }
  ]
}
```

Field order in the `accepts[0]` object mirrors the worker's requirements builder exactly; it may also carry an optional trailing `extra: { name, version }` object if the operator sets an asset name (e.g. for EIP-712 domain data). A malformed retry — an `X-PAYMENT` header that is not valid base64-encoded JSON — would draw `400 invalid_x_payment_header` with the same `accepts` array repeated.

**Step 2 — pay and retry.** A client library (see [agent wallets](/resources/agent-wallets-x402) for which ones) signs a payment authorization against the `accepts[0]` requirements, base64-encodes the signed payload, and retries with an `X-PAYMENT` header:

```
# hypothetical — endpoint is dormant today
$ curl -sS -i https://changegamer.ai/api/x402/data-formats \
    -H "X-PAYMENT: <base64-encoded signed PaymentPayload JSON>"

HTTP/1.1 200 OK
Content-Type: text/markdown; charset=utf-8
X-PAYMENT-RESPONSE: <base64-encoded settlement receipt JSON>

# Data Formats & Schema

> Structured data conventions: JSON-LD, Markdown variants and stable slugs.

...full resource Markdown body...
```

That `200` only happens once the worker's two facilitator calls (`POST <facilitator>/verify`, then `POST <facilitator>/settle`) both succeed. Other outcomes the code defines: the facilitator rejects the payment at `/verify` or `/settle` → `402` with `error` set to its `invalidReason` (falling back to `payment_invalid`) or `errorReason` (falling back to `settlement_failed`); the worker fails to sign its own facilitator-auth request → `502 facilitator_auth_failed`; the facilitator is unreachable or returns something unparseable → `502 facilitator_unreachable`.

Once again: nothing in this future-contract subsection is reachable today. Confirm the live status of `/api/x402/<slug>` at [/api/payment.json](/api/payment.json) — while its `x402` entry there confirms the same dormant/503 state, the only working call against that path is the `curl` example in "Today's actual behavior" above, and it always returns 503.


Finding and Evaluating MCP Servers

How to discover, assess and safely integrate MCP servers into agent pipelines.

The Model Context Protocol (MCP) is an open protocol for connecting AI models to external tools, data sources and services. Announced by Anthropic in November 2024, it has since seen broad industry adoption. MCP defines a client/server interface: a host application (the MCP client) connects to servers that each expose tools, resources and prompts the model can invoke.

Governance note: MCP originated under Anthropic stewardship but has attracted contributions from many organisations. Governance structures evolve quickly — verify the current status at modelcontextprotocol.io before relying on any statement about who controls the specification.

## Key facts

- MCP, an open protocol from Anthropic dating back to late 2024, gives AI models a standard way to reach outside tools, data, and services.
- MCP's official registry — the natural first stop for discovery — had not exited its preview phase as of mid-2026.
- Servers are also distributed via client-vendor marketplaces, community aggregators (PulseMCP, Smithery, Glama, MCP.so), and directly from vendors.
- Evaluate a server on its transport, auth model, permission/scope minimisation, and maintenance signals before connecting.
- Major security risks include prompt injection via tool descriptions, supply-chain compromise, "rug pull" updates, and over-broad permissions.
- Because an already-approved server can silently change behavior after an update, lock it to a specific version or content hash and manually recheck what its tools claim to do each time a new release ships.
- A major stateless-protocol spec revision is in release candidate as this is written, shipping final July 28, 2026 — see [MCP goes stateless](/resources/mcp-2026-spec-revision) for what changes.

## Discovering MCP servers

The canonical starting point is the **official MCP Registry** (registry.modelcontextprotocol.io) — a community-driven open catalog/API for publicly available MCP servers, backed by Anthropic, GitHub, PulseMCP, and Microsoft (launched in preview September 2025; still in preview as of mid-2026). Publish to it with the `mcp-publisher` CLI (`init` → edit `server.json` → `login github` → `publish`); it stores metadata only, so the package itself must first be on npm or another artifact registry.

- **github.com/modelcontextprotocol/servers** now hosts only a small set of reference implementations maintained by the MCP steering group; its README defers to the registry for discovery, and many earlier servers moved to `modelcontextprotocol/servers-archived`.

Beyond that, servers are distributed through: **client-vendor marketplaces** (AI-assistant and IDE vendors increasingly ship curated server lists — check your client's documentation); **community aggregators** — major ones in 2026 include PulseMCP, Smithery, Glama, and MCP.so (large directories that vary in review rigour — treat as leads, not endorsements); and **direct from vendors** (many teams publish MCP servers alongside their own products — prefer the official source over a third-party mirror).

## Evaluating a server

**Transport** — the spec has evolved; treat the following as a snapshot and verify at modelcontextprotocol.io: *stdio* (local subprocess over stdin/stdout — low network surface); *HTTP + SSE* (legacy remote transport, still widely deployed); *Streamable HTTP* (newer consolidated remote transport — preferred for new deployments where the client supports it). Confirm the server's transport is supported by your client version.

**Auth** — Check what credentials the server requires from you and what it holds on your behalf to call upstream APIs. Long-lived third-party tokens stored server-side are a significant blast-radius risk if compromised.

**Permission/scope minimisation** — Prefer servers that expose only the tools your agent actually needs. Review the declared tool list before connecting; each tool is a potential code-execution or data-access path. Revoke access when done.

**Maintenance signals** — Recent commit activity, a maintained changelog, and absence of open auth/misbehaviour bugs indicate the server tracks spec changes. Unmaintained servers built against old protocol versions may stop working as clients update.

## Security risks

**Prompt injection** — A server controls the text of its tool descriptions and outputs. A malicious server can embed instructions attempting to redirect model behaviour (exfiltrate context, override system-prompt constraints). Mitigate by only connecting to servers you can review or trust, auditing tool descriptions, and using output sanitisation.

**Supply-chain** — npm/PyPI packages for MCP servers carry the same risks as any open-source dependency: typosquatted packages, maintainer account takeovers, malicious dependency updates. Mitigate by pinning exact versions with lock files, preferring verified-org publishers, and auditing before production use.

**Rug pull** — a server you have already approved can push an update that silently changes its tool descriptions or behaviour, and most clients do not re-alert on changed definitions. Real cases include the `postmark-mcp` package, which silently BCC'd emails to an attacker address after a post-approval update, and the Cursor "MCPoison" issue (CVE-2025-54136); NSA MCP security guidance (2026) treats this as a systemic risk. Mitigate by pinning servers to exact versions/content hashes and re-reviewing tool definitions on every update.

**Over-broad permissions** — Filesystem access, network egress, or credentials beyond the server's stated purpose are a red flag and amplify every other vulnerability.

## Checklist

- [ ] Source confirmed (official repo, vendor-published, or reviewed community server).
- [ ] Transport identified and compatible with your client version.
- [ ] Authentication model understood; credentials stored securely.
- [ ] Tool list reviewed; scope limited to what the agent actually needs.
- [ ] Package version pinned and checksum verified (if distributed as a package).
- [ ] Maintenance status checked (recent activity, no critical open bugs).
- [ ] Prompt-injection risk assessed; output sanitisation in place for untrusted servers.
- [ ] Tool descriptions/behaviour diff-checked on each server update before loading (rug-pull defense).
- [ ] Plan to revoke server access when no longer needed.


Agentic Security Checklist

Cross-vendor, threat-surface-organized security checklist for building and operating AI agents — synthesizing OWASP, NIST, Anthropic, OpenAI, Google SAIF, and MITRE ATLAS.

Labs publish vendor-specific guidance. This checklist synthesizes it across vendors into one agent-consumable reference, organized by threat surface. Check each item before shipping an agent to production.

## Key facts

- This checklist condenses independently published agent-security guidance — from OWASP, NIST, and MITRE ATLAS, plus safety frameworks from Anthropic, OpenAI, and Google — into one reference organized by threat surface rather than by vendor.
- For prompt injection, the single highest-leverage move is to never let anything from outside the trust boundary be read as an instruction — treat it purely as data.
- Least-privilege tooling and required confirmation before irreversible or state-changing tool calls curb both tool/function-call abuse and excessive agency.
- Credentials must never enter the context window at all; inject them at the infrastructure layer so tool wrappers resolve them outside the model's view.
- For MCP and other supply-chain risk, lock every server to an exact, verified version and review what its tools claim to do before the first connection.
- Attach a unique identifier to every tool call so downstream logs can be tied back to the run that produced them and incidents can be reconstructed after the fact.

## Summary table

| Threat surface | Highest-impact control |
|---|---|
| Prompt injection | Treat all external content as untrusted data, not instructions |
| Tool/function-call abuse | Least-privilege toolset; confirm before destructive calls |
| Excessive agency | Scope permissions to the minimum required for each task |
| Secrets & credentials | Never pass secrets through the context window |
| MCP / supply chain | Pin versions; audit tool descriptions before connecting |
| Output / action sandboxing | Human-in-the-loop gate on irreversible actions |
| Memory & context poisoning | Validate and sanitize retrieved context before injection |
| Data exfiltration | Network egress allowlist; outbound content inspection |
| Auth & OAuth scopes | Request only the OAuth scopes the agent needs per task |
| Logging & auditability | Log every tool call, input, and output with a trace ID |

## 1. Prompt injection — direct and indirect

- Enforce a strict separation between trusted instructions (system prompt) and untrusted data (user input, tool outputs, retrieved documents). Never concatenate them without a structural delimiter.
- Treat all content fetched from the web, email, databases, or tool responses as untrusted user data — not as instructions — regardless of where it originated (OWASP Agentic ASI01 Agent Goal Hijack; OWASP LLM01:2025 Prompt Injection).
- Strip or escape instruction-like patterns (`Ignore previous instructions`, `<system>`, `ASSISTANT:`) from retrieved content before inserting into context.
- Validate that tool outputs conform to the expected schema and type before the model acts on them.
- Run a separate classification step or guardrail on user input to detect jailbreak patterns before the main agent sees them (OpenAI agent builder safety guidance).

## 2. Tool and function-call abuse

- Maintain a minimal toolset: expose only the tools needed for the current task; disable or detach others at runtime (Anthropic trustworthy-agents framework — harness layer).
- Require explicit confirmation before any tool call that is irreversible, has financial impact, or modifies shared state (email, file system, database write, API mutation).
- Log the full tool-call request (name + arguments) and response before execution.
- Rate-limit tool calls per agent turn to bound blast radius from runaway loops.
- Reject tool calls with arguments that reference paths, URIs, or identifiers outside the expected domain.

## 3. Excessive agency and least-privilege

- Grant the agent only the permissions it needs for the specific task, not for all tasks it might ever do (OWASP LLM06:2025 Excessive Agency; Google SAIF principle of minimizing blast radius).
- Prefer read-only tool variants when write access is not required for the step.
- Time-bound credentials: issue short-lived tokens per task rather than long-lived agent credentials.
- Review and prune the tool list each time the agent's scope changes.

## 4. Untrusted content handling

- Sanitize HTML, Markdown, and JSON retrieved from external sources before insertion into the context window.
- Do not render or execute content returned by tools without validation.
- Limit the size of individual tool responses injected into context to prevent context-flooding attacks.
- Apply output encoding when agent-generated content is passed to downstream systems (SQL, shell, HTML rendering).

## 5. Secrets and credential management

- Never place API keys, passwords, or tokens in the system prompt, user message, or any field visible to the model.
- Inject secrets at the infrastructure layer (environment variables, secret managers) and resolve them in tool-call wrappers, not in context.
- Rotate credentials on a schedule; revoke immediately on suspected compromise.
- Audit which tool servers hold credentials on your behalf — long-lived third-party tokens stored server-side are high blast-radius targets.

## 6. MCP server trust and supply chain

- Only connect to MCP servers you can review or whose publisher you trust; third-party registries vary in vetting rigour.
- Audit the tool description text of every MCP server before connecting — malicious servers embed instructions in descriptions to hijack model behavior (prompt injection via tool metadata).
- Pin package versions with lock files and verify checksums; the first malicious MCP package appeared in September 2025.
- Prefer OAuth 2.1 + PKCE for remote MCP server auth (mandatory since the 2025-06-18 MCP spec). The 2025-11-25 revision replaced Dynamic Client Registration with URL-based OAuth Client ID Metadata Documents (SEP-991) as the preferred default and added client-credentials grants for machine-to-machine auth — use per-agent client identities, not shared credentials.
- Scope OAuth tokens to the minimum required tools; use per-tool scopes where the server supports them.
- Revoke server access when the agent task is complete.
- A further spec revision (2026-07-28) is in release-candidate as of this writing: it drops the `initialize`/session-ID handshake for a stateless core and tightens OAuth/OIDC alignment (RFC 9207 issuer validation). Re-check which spec date a given MCP server/client targets before hardening auth against it.

## 7. Output and action sandboxing; human-in-the-loop gates

- Define a pre-flight checklist of action categories that always require human approval: financial transfers, sending external communications, deleting data, provisioning infrastructure (Anthropic trustworthy-agents framework; NIST AI RMF GOVERN function).
- Sandbox code execution and file operations in isolated environments with no network egress by default.
- Implement a rollback or undo path for every reversible action the agent takes.
- Emit a structured pre-action summary to the user before high-stakes tool calls and wait for acknowledgement.

## 8. Memory and context poisoning

- Validate retrieved memories or RAG results against a known-good schema before injecting into context.
- Treat vector-store content with the same distrust as external web content — it may have been poisoned at ingestion time (MITRE ATLAS AML.T0020 Poison Training Data, which covers fine-tuning and RAG data sources).
- Separate short-term working memory from long-term persistent storage; apply stricter validation before promoting content to persistent memory.
- Periodically audit long-term memory stores for injected instructions.

## 9. Data exfiltration channels

- Restrict agent network egress to a known allowlist of destinations; deny by default.
- Inspect outbound tool-call arguments for PII and secrets before execution; block calls that reference data outside their expected domain.
- Do not let the agent construct arbitrary URLs or shell commands from user-supplied input without sanitization.
- Monitor for unusual data volumes or frequencies in tool outputs that may indicate exfiltration via covert channels.

## 10. Auth and OAuth scopes

- Request OAuth scopes at the minimum granularity needed for each specific task; do not request broad scopes for future convenience.
- Use separate OAuth clients (and credentials) per agent instance; never share a client ID across agent instances.
- Implement token refresh and revocation; treat access tokens as ephemeral.
- Verify that the OAuth resource indicator (RFC 8707) matches the intended MCP server to prevent token mis-redemption attacks.

## 11. Logging and auditability

- Assign a unique trace ID to every agent run; propagate it through all tool calls and sub-agent invocations.
- Log: timestamp, trace ID, tool name, full arguments, full response, latency, and outcome for every tool call.
- Store logs in an append-only, tamper-evident store; agents must not be able to delete their own logs.
- Alert on anomalous patterns: high tool-call rates, calls to unexpected endpoints, or sudden changes in action type distribution (Google SAIF — Monitor and Respond principle).
- Retain logs long enough to support incident reconstruction; NIST AI RMF MANAGE function recommends documented response plans.

## Verified sources

- OWASP Top 10 for Agentic Applications (2026): https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
- OWASP LLM01:2025 Prompt Injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/
- MCP spec — 2025-11-25 changelog (Client ID Metadata Documents, SEP-991): https://modelcontextprotocol.io/specification/2025-11-25/changelog
- MCP blog — One Year of MCP: November 2025 spec release: https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/
- MCP blog — The 2026-07-28 Specification Release Candidate: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
- Anthropic — Our framework for developing safe and trustworthy agents: https://www.anthropic.com/news/our-framework-for-developing-safe-and-trustworthy-agents
- OpenAI — Safety in building agents: https://platform.openai.com/docs/guides/agent-builder-safety
- OpenAI — A practical guide to building agents: https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
- Google SAIF (Secure AI Framework): https://saif.google/secure-ai-framework
- MITRE ATLAS (adversarial threat landscape for AI): https://atlas.mitre.org/
- NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework


MCP vs A2A: Two Protocols, Two Roles

Compact comparison of the Model Context Protocol (agent↔tool) and the Agent2Agent Protocol (agent↔agent): purpose, topology, transport, discovery, auth, governance, and when to use each.

MCP and A2A are complementary open protocols that solve different problems in agentic systems. MCP connects an agent to tools and data. A2A connects agents to other agents. Confusing them is the most common protocol mistake in multi-agent architecture.

## Key facts

- MCP sets up a client/server relationship so an agent can call out to tools, read resources, and use prompt templates, while A2A sets up a peer relationship where one agent hands off a task to another and waits for the result.
- MCP discovery runs through the official registry and client-vendor marketplaces; A2A discovery instead relies on a self-published Agent Card fetched from a well-known discovery endpoint on the agent's own domain.
- MCP requires OAuth 2.1 + PKCE for remote transport; A2A auth is declared per-agent via OpenAPI security schemes in the Agent Card.
- In production, agents typically communicate with each other over A2A for the inter-agent handoff, then each one separately uses MCP to reach whatever tools or data it personally needs.
- Confusing the two protocols — expecting MCP to handle inter-agent delegation, or A2A to handle tool access — is the most common architecture mistake.

## What each protocol is for

**MCP (Model Context Protocol)** is a client/server protocol for connecting an AI model to external capabilities: tools (functions the model can call), resources (files, database rows, URLs it can read), and prompts (reusable instruction templates). The model is the client; the capability provider is the server. MCP standardises the wire format so a single agent can talk to any MCP-compliant tool without custom glue code.

**A2A (Agent2Agent Protocol)** is a peer protocol for one agent to delegate tasks to another agent. The delegating agent (client) does not know or care how the remote agent is built — it sends a task, receives streamed status updates, and gets a result. A2A standardises discovery (Agent Card), task lifecycle, and wire format so agents from different vendors interoperate without shared code.

## Comparison table

| Dimension | MCP | A2A |
|---|---|---|
| **Purpose** | Agent ↔ tool / data / context | Agent ↔ agent task delegation |
| **Topology** | Client (host/agent) → server (tool) | Peer: client agent → server agent |
| **Transport** | stdio (local); Streamable HTTP (remote); HTTP+SSE (deprecated) | JSON-RPC, gRPC, or HTTP+JSON/REST — three functionally-equivalent bindings as of v1.0 (spec §§9-11) |
| **Message format** | JSON-RPC 2.0 | JSON-RPC 2.0 |
| **Discovery** | Registry at registry.modelcontextprotocol.io; client-vendor marketplaces | Agent Card at `/.well-known/agent-card.json` (self-hosted) |
| **Auth** | OAuth 2.1 + PKCE (mandatory for HTTP); stdio uses env credentials | OpenAPI 3.x Security Schemes declared in Agent Card |
| **Governance** | AAIF (Linux Foundation directed fund) — donated Dec 2025; co-founded by Anthropic, Block, OpenAI | Linux Foundation — donated Jun 2025; originated by Google |
| **Stable version / date** | 2025-11-25 (RC: 2026-07-28, stateless architecture) | v1.0 — released March 2026 (current v1.0.x; prior: v0.3) |
| **License** | MIT (spec + SDK) | Apache 2.0 |
| **Adoption** | Thousands of servers in the official registry; backed by AAIF members | 150+ organizations; adopters include AWS, Azure, Salesforce, SAP, ServiceNow |

## Capabilities inside MCP

- **Tools** — functions the model invokes (read DB, call API, run code).
- **Resources** — read-only data the model can subscribe to (files, rows, live feeds).
- **Prompts** — named, parameterised prompt templates served by the server.
- **Sampling** — server requests the client to run an LLM inference on its behalf.

## A2A core objects

- **Agent Card** (`/.well-known/agent-card.json`) — JSON document describing the agent's name, endpoint, skills, auth requirements, and SLAs. v1.0 adds a cryptographic signature so callers can verify the card was issued by the domain owner. (older spec versions used agent.json)
- **Task** — the unit of work; has a lifecycle (submitted → working → completed/failed).
- **Message** — the wire envelope; sent via `message/send`; streaming via `message/stream` (Server-Sent Events).

## How they compose in one stack

The standard pattern: agents talk to each other via A2A; each agent reaches its tools via MCP. This is not a convention — Microsoft Azure AI Foundry and Copilot Studio explicitly support both simultaneously (confirmed at Microsoft Build 2025).

Example flow:

1. Orchestrator agent receives a task from a user.
2. Orchestrator delegates a sub-task to a specialist agent via A2A (`message/send`).
3. Specialist agent fetches context (CRM records, docs) via MCP tool calls.
4. Specialist returns result to orchestrator via A2A streaming.
5. Orchestrator synthesises and responds.

Each layer stays within its protocol: A2A for the inter-agent envelope, MCP for the tool/data layer inside each agent.

## Common confusions

**"MCP already does multi-agent — why A2A?"** MCP's sampling capability lets a server request an LLM inference, but it does not define task lifecycle, agent discovery, or cross-organisational delegation. A2A fills that gap.

**"A2A replaces MCP."** No. They operate at different layers. A2A does not define how an agent accesses a database or calls a REST API; MCP does.

**"They are competing standards."** Neither spec mandates exclusivity. The reference implementations for Google ADK, AWS Strands, and Microsoft Agent Framework all use both.

**"MCP is still just Anthropic's."** No. MCP governance moved to the Agentic AI Foundation (AAIF) under the Linux Foundation on 2025-12-09. Anthropic remains a co-founder and active contributor but no longer controls the spec unilaterally.

## What is emerging vs stable

- **Stable**: MCP 2025-11-25 spec; A2A v1.0, including all three of its protocol bindings — JSON-RPC, gRPC, and HTTP+JSON/REST — which the v1.0 spec (§§5.1, 9-11) requires to stay functionally equivalent (same operations/capabilities, semantically equivalent results, consistent protocol-specific error mapping) whenever an agent supports more than one; the composition pattern.
- **Emerging**: MCP RC 2026-07-28 (stateless architecture, MCP Apps, Tasks extension — final spec targeted late July 2026); A2A global agent registry (proposal only as of Jun 2026 — no canonical registry exists yet, unlike MCP's registry.modelcontextprotocol.io). Real-world usage share across A2A's three bindings (what fraction of deployed agents actually use gRPC vs. JSON-RPC vs. REST in production) could not be confirmed from any source found — the spec mandates behavioral equivalence, not adoption reporting; treat any claim about which binding dominates in practice as unverified.

## Bottom line

Most production multi-agent systems need both protocols, not one instead of the other, because they govern different layers of the stack: A2A governs the agent-to-agent envelope (discovery via Agent Card, task lifecycle, delegation), while MCP governs the agent-to-tool/data layer inside each agent (tools, resources, prompts). The standard pattern above — orchestrator delegates via A2A, each agent then reaches its own tools via MCP — is already how Google ADK, AWS Strands, and Microsoft Agent Framework ship by default. Asking "MCP or A2A?" is the confusion this resource opened by naming: they solve different problems, so the real design question is which agent in your architecture needs which layer, not which protocol wins.

## Getting started — verified free resources

- MCP spec (stable 2025-11-25): https://modelcontextprotocol.io/specification/2025-11-25
- MCP registry: https://registry.modelcontextprotocol.io/
- MCP reference servers: https://github.com/modelcontextprotocol/servers
- A2A spec (v1.0): https://a2a-protocol.org/latest/specification/
- A2A GitHub (spec + SDKs + samples): https://github.com/a2aproject/A2A
- MCP course (hands-on, free): https://huggingface.co/learn/mcp-course/


AI Crawler Policy: robots.txt and User-Agents

Canonical reference table of major AI crawler user-agent tokens, their purpose, robots.txt semantics, and the WAF/edge layer that sits above robots.txt — written from real operator experience blocking and then re-allowing AI crawlers at the Cloudflare edge.

robots.txt is advisory. A compliant crawler reads it before fetching and honours Disallow rules — but WAF and firewall rules are enforced earlier, at the network edge, before a crawler can even retrieve robots.txt. If your WAF blocks a UA, robots.txt Allow rules have no effect. This page covers both layers.

## Canonical user-agent token table

| Token | Vendor | Purpose | robots.txt honoured? |
|---|---|---|---|
| `GPTBot` | OpenAI | Training data collection for GPT models | Yes |
| `OAI-SearchBot` | OpenAI | Indexing for ChatGPT Search (not training) | Yes |
| `ChatGPT-User` | OpenAI | Live user-triggered page fetch, incl. Custom GPT / GPT Actions requests | No — a Dec 2025 OpenAI doc update lists only `GPTBot`/`OAI-SearchBot` as robots.txt-compliant |
| `ClaudeBot` | Anthropic | Training data collection for Claude models | Yes |
| `Claude-SearchBot` | Anthropic | Indexing for Claude search results | Yes |
| `Claude-User` | Anthropic | Live user-triggered page fetch | Yes (Anthropic states all three honour it) |
| `Google-Extended` | Google | Training opt-out token for Gemini/Vertex AI — NOT a separate crawler; Googlebot fetches, this token controls downstream use | Yes (training opt-out only) |
| `Googlebot` | Google | Google Search indexing; also executes Google-Extended policy | Yes |
| `Google-CloudVertexBot` | Google | Crawls at site-owner request during Vertex AI Agent development | Yes |
| `PerplexityBot` | Perplexity | Indexing for Perplexity search answers | Yes |
| `Perplexity-User` | Perplexity | Live user-triggered page fetch | No — ignores robots.txt by design |
| `DuckAssistBot` | DuckDuckGo | Live user-triggered fetch for DuckAssist AI answers (RAG); not used for training | Yes — Disallow opt-out takes effect ~72h later |
| `Amazonbot` | Amazon | Crawling for Amazon product/AI improvement | Yes |
| `Applebot` | Apple | Apple Search (Spotlight, Siri) indexing | Yes |
| `Applebot-Extended` | Apple | Training opt-out token for Apple Intelligence / foundation models — NOT a separate crawler; Applebot fetches, this token controls training use | Yes (training opt-out only) |
| `Bytespider` | ByteDance | AI training data collection (Doubao LLM) | Disputed — documented violations |
| `CCBot` | Common Crawl | Open web archive used to train most major LLMs | Yes |
| `Meta-ExternalAgent` | Meta | Training data for Llama models and Meta AI products (launched July 2024) | Stated yes; compliance disputed |
| `Meta-ExternalFetcher` | Meta | Live user-triggered fetch for Meta AI assistant answers (parallel to ChatGPT-User/Claude-User); not used for training | Unclear — no independent robots.txt-compliance confirmation found |
| `MistralAI-User` | Mistral | User-triggered fetch in Le Chat; not used for training | Yes |

## robots.txt syntax — per-UA examples

```
# Allow ChatGPT Search indexing; block training
User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

# Block Anthropic training; allow user fetches and search
User-agent: ClaudeBot
Disallow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Claude-User
Allow: /

# Keep Google Search; block AI training use
User-agent: Google-Extended
Disallow: /

# Block Apple Intelligence training; keep Apple Search
User-agent: Applebot-Extended
Disallow: /

# Block Common Crawl (source data for most LLMs)
User-agent: CCBot
Disallow: /
```

## The advisory-only limit

robots.txt binds only crawlers that voluntarily read and respect it. Practical gaps:

- **User-triggered fetchers** (`ChatGPT-User`, `Perplexity-User`, `Meta-ExternalFetcher`) are sent by live users who requested a specific URL. Perplexity explicitly states `Perplexity-User` ignores robots.txt. As of a Dec 2025 documentation update, OpenAI no longer lists `ChatGPT-User` among its robots.txt-compliant agents (only `GPTBot` and `OAI-SearchBot` are) — it is now treated as a proxy for human browsing. Meta does not clearly state whether `Meta-ExternalFetcher` honours Disallow.
- **Non-compliant crawlers** (`Bytespider`, `Meta-ExternalAgent`) have documented or disputed histories of ignoring Disallow. IP-range blocking and WAF rules provide a harder layer.
- **Spoofed UAs** — any actor can send a fake UA. Vendor IP-range verification is the only way to confirm a crawler is authentic. All major vendors publish IP ranges (see verified sources below).

## Training opt-out tokens vs real crawlers

Two tokens are semantic policy signals, not user agents of separate crawlers:

- **`Google-Extended`** — The physical crawler is still `Googlebot`. Disallowing `Google-Extended` tells Google not to use already-crawled content to train Gemini and Vertex AI. It does not affect Google Search inclusion or ranking.
- **`Applebot-Extended`** — The physical crawler is `Applebot`. Disallowing `Applebot-Extended` tells Apple not to use already-crawled content to train Apple Intelligence and foundation models. Apple Search / Spotlight inclusion is unaffected.

## The WAF/edge layer: sits above robots.txt

ChangeGamer's own experience (BACKLOG item 0, June 2026): Cloudflare's managed rule "Manage AI bots" (`firewallManaged`) was silently 403ing `GPTBot`, `ChatGPT-User`, `OAI-SearchBot`, `PerplexityBot`, `CCBot`, and `Google-CloudVertexBot` — including on `/` and `/sitemap.xml` — even though robots.txt explicitly allowed them. Cloudflare Browser Integrity Check (BIC, enabled by default) additionally 403'd any client without standard browser headers, breaking the Google Search Console sitemap fetch.

Fixes: BIC off; AI Crawl Control set to Allow for all crawlers; WAF custom rule "Allow AI crawlers" (Skip all managed rules, UA-match, logging on) to ensure managed rules cannot re-block them.

**Key lesson:** after any WAF or security-rule change, verify actual crawler access with a spoofed-UA curl against your live domain — do not assume robots.txt Allow is sufficient:

```bash
curl -A "Mozilla/5.0 (compatible; GPTBot/1.1; +https://openai.com/gptbot)" \
  -I https://yourdomain.com/

curl -A "Mozilla/5.0 (compatible; ClaudeBot/1.0; +https://anthropic.com/aup)" \
  -I https://yourdomain.com/
```

Expect HTTP 200. A 403 means the WAF or BIC is blocking at the edge, not robots.txt.

## Emerging access-control and monetization signals

robots.txt is the established baseline, but newer mechanisms layer on top:

- **RSL (Really Simple Licensing)** — an XML-based machine-readable license document (a standalone `.xml` file, e.g. `/license.xml`) that declares licensing terms, usage boundaries, and compensation requirements. It is discovered via a `License:` directive in robots.txt (and HTTP headers, RSS, or HTML `<link>`). Spec at `rslstandard.org`. Announced 2025; early adoption stage as of June 2026. ChangeGamer publishes its own at /license.xml.
- **HTTP 402 / pay-per-crawl** — direct programmatic payment gate on individual resource requests. See /resources/paying-for-access-402 and /resources/access-and-pricing.
- **Cloudflare Pay Per Crawl** — Cloudflare's 402-based per-crawl pricing at the CDN layer (private beta as of June 2026). See /resources/access-and-pricing for current status.

For how agents should respond to a 402 gate, see /resources/paying-for-access-402.
For how ChangeGamer publishes its own machine-readable content index, see /resources/llms-txt-explained.

## Verified sources

- OpenAI crawler overview: https://developers.openai.com/api/docs/bots
- OpenAI publishers FAQ: https://help.openai.com/en/articles/12627856-publishers-and-developers-faq
- Anthropic crawler support page: https://support.anthropic.com/en/articles/8896518
- Google common crawlers: https://developers.google.com/crawling/docs/crawlers-fetchers/google-common-crawlers
- Applebot support page: https://support.apple.com/en-us/119829
- Perplexity bots guide: https://docs.perplexity.ai/guides/bots
- Amazon Amazonbot: https://developer.amazon.com/amazonbot
- Common Crawl CCBot: https://commoncrawl.org/ccbot
- Mistral AI robots doc: https://docs.mistral.ai/robots
- Cloudflare AI Crawl Control bot reference: https://developers.cloudflare.com/ai-crawl-control/reference/bots/
- Cloudflare Browser Integrity Check: https://developers.cloudflare.com/waf/tools/browser-integrity-check/
- RSL (Really Simple Licensing): https://rslstandard.org/
- Search Engine Roundtable, OpenAI ChatGPT-User/OAI-SearchBot doc update (Dec 2025): https://www.seroundtable.com/openai-chatgpt-crawler-oai-searchbot-update-40558.html
- DuckDuckGo DuckAssistBot help page: https://duckduckgo.com/duckduckgo-help-pages/results/duckassistbot


Open-Weight Models for Agents

Cross-vendor comparison table of major open-weight LLM families — license, tool-calling support, context window, and agent-builder notes — as of July 2026.

Open-weight models let agent builders control inference, eliminate per-call vendor fees, and avoid rate-limit ceilings. The tradeoff is hosting cost and model-update lag. This page compares the major families through the lens of what agent builders actually need. All claims are dated July 2026; this space moves fast — verify before pinning a model version.

## Comparison table

| Family | Latest open-weight release | License | Native tool/function-calling | Notable for agents |
|---|---|---|---|---|
| **Meta Llama 4** | Llama 4 Maverick (17B active / 400B total MoE, Apr 2025) | Llama 4 Community License (not OSI open; MAU cap >700M requires Meta approval; commercial use otherwise permitted) | Yes — natively optimized for tool-calling and agentic use | Scout (10M-token context) and Maverick (1M) both remain available on Hugging Face under the Llama 4 Community License; Maverick is the stronger general/agentic pick. Multimodal. Behemoth was previewed but never open-released. |
| **Mistral** | Mistral Small 4 (119B total / 6.5B active MoE, Mar 2026); Mistral Medium 3.5 (128B dense, Apr 2026); Mistral Large 3 (675B total / 41B active MoE, Dec 2025) | Apache 2.0 (Small 4, Large 3); Modified MIT with revenue cap (Medium 3.5) | Yes — function calling and structured output supported across all three; Small 4 also unifies reasoning and vision | Small 4 (256K ctx) unifies Magistral reasoning + Pixtral vision + Devstral coding in one model. Medium 3.5 (256K ctx) is a frontier-class open coding/agentic model. Large 3 (256K ctx) is the largest open-weight Mistral. Mistral Small 3.2 deprecated April 30, 2026. |
| **Alibaba Qwen** | Qwen 3.6-27B / 3.6-35B-A3B (Apr 2026); Qwen3 base series (Apr 2025) | Apache 2.0 | Yes — native tool-calling and MCP support via Qwen-Agent; all sizes | Dense and MoE variants from 0.6B to 235B. Up to 262K context (extensible to 1M via YaRN). Hybrid thinking/non-thinking mode. Qwen 3.7 is closed-weight API-only as of Jun 2026. |
| **DeepSeek** | DeepSeek V4-Pro (1.6T total / 49B active MoE) and V4-Flash (284B total / 13B active), both Apr 2026 preview | MIT | Yes — V4 natively supports function calling, JSON output, tool calls, and thinking / non-thinking modes | 1M context window (default across both V4 variants). V4-Pro: frontier-class agentic coding. V4-Flash: fast/cheap inference. Weights on Hugging Face (deepseek-ai). V4 labeled preview; stable release expected later 2026. |
| **Google Gemma 4** | Gemma 4: E2B, E4B, 26B-A4B, 31B (Mar–Apr 2026); Gemma 4 12B Unified (Jun 2026, encoder-free, native audio) | Apache 2.0 (first Gemma release under true Apache 2.0) | Yes — native function-calling built into Gemma 4; FunctionGemma 270M for edge/on-device | 128K context (E2B/E4B); 256K context (12B+, 26B, 31B). Gemma 4 12B Unified (Jun 3 2026) adds native audio + video via encoder-free architecture; runs on 16 GB RAM. Multimodal across the family. |
| **Microsoft Phi-4** | Phi-4-reasoning-vision-15B (15B, Mar 2026); Phi-4-reasoning (14B, May 2025); Phi-4-mini (3.8B) | MIT | Yes — Phi-4-mini has built-in function calling; the Phi-4 line supports tool use; Phi-4-reasoning for chain-of-thought agentic tasks | Efficiency-first: strong reasoning per parameter. MIT license. Phi-4-reasoning-vision-15B adds selective thinking mode + high-res vision. Phi-4-multimodal adds audio+vision. |
| **IBM Granite 4.1** | Granite 4.1 (3B, 8B, 30B, Apr 2026) | Apache 2.0 | Yes — tool calling follows OpenAI function definition schema; benchmarked on Berkeley BFCL | 512K context window. Enterprise-focused; ISO 42001 certified (Granite 4.0 line). 30B uses hybrid Mamba-Transformer architecture for long-context efficiency; 3B/8B are dense. Sizes 3B–30B. |
| **OpenAI gpt-oss** | gpt-oss-20b (21B total / 3.6B active, MoE); gpt-oss-120b (117B total / 5.1B active, MoE); released Aug 2025 | Apache 2.0 | Yes — native function calling, structured outputs, web browsing, code execution | Reasoning models (comparable to o3-mini / o4-mini). 128K context. MXFP4 quantized weights; 120B fits on a single 80GB GPU. Weights on Hugging Face: huggingface.co/openai. |
| **Z.ai GLM-5.2** | GLM-5.2 (744B total / ~40B active MoE, Jun 2026) | MIT | Yes — native tool-calling, function calling, structured output, and MCP support | 1M context (128K max output). Frontier-class long-horizon coding/agentic model (SWE-bench Pro 62.1); the highest-ranked open-weight model across several long-horizon coding benchmarks. Self-hosting needs a multi-GPU node (≈8×H100/H200-class at FP8); official FP8 weights at huggingface.co/zai-org/GLM-5.2-FP8. |
| **Moonshot AI Kimi K2.7 Code** | Kimi K2.7 Code (~1T total / ~32B active MoE, Jun 12 2026) | Modified MIT (commercial use and internal deployment permitted; attribution required above a revenue/MAU threshold, consistent with the established Kimi K2 license family) | Yes — native agentic tool-calling; purpose-built for long-horizon software-engineering workflows | 256K context. The coding/agentic-specialized variant of the Kimi K2 line; Moonshot reports ~30% fewer reasoning tokens than K2.6 at higher coding-benchmark scores. Weights on Hugging Face (moonshotai/Kimi-K2.7-Code). |
| **NVIDIA Nemotron 3 Ultra** | Nemotron 3 Ultra (550B total / 55B active MoE, Jun 4 2026) | OpenMDW-1.1 (the Linux Foundation's open AI-model license; NVIDIA adopted it across the Cosmos/Isaac GR00T/Nemotron families; permissive — commercial and non-commercial use, modification, and redistribution allowed, patent-termination clause, no revenue/MAU cap) | Yes — tuned for long-running agent orchestration across hundreds of sequential tool calls | 1M context. Hybrid Mamba-Transformer MoE architecture with an NVFP4 pretraining/quantization recipe for compute-efficient long-horizon inference. Weights on Hugging Face (nvidia/NVIDIA-Nemotron-3-Ultra-550B-A55B). |

## What to look for when picking an open-weight model for agents

### Tool-calling and JSON-mode reliability

Reliable structured output is the single most important property for agents. A model that hallucinates tool names, omits required arguments, or produces malformed JSON turns every downstream step into an error-handling problem. Check: (a) whether the model was instruction-tuned with a tool-use dataset, not just base-pretrained; (b) benchmark scores on Berkeley Function Calling Leaderboard (BFCL) for your target task category; (c) whether the inference framework you use supports the model's chat template exactly (template mismatches silently degrade tool-call reliability).

### License terms: true-open vs source-available

Not all "open-weight" licenses are equal. For commercial agent deployments, the key questions are: (1) Is the license OSI-approved (Apache 2.0, MIT)? If yes, no usage caps or approval gatekeepers exist. (2) Is there a monthly active user (MAU) cap requiring vendor approval? Llama 4 Community License restricts deployments serving >700M MAU to Meta's discretion — irrelevant for most builders, but material at scale. (3) Does the license permit sublicensing or redistribution of fine-tunes? Apache 2.0 and MIT do; Llama Community License restricts this. As of July 2026: Qwen 3.6, Gemma 4, Phi-4, Granite 4.1, Mistral Small 4 / Large 3, DeepSeek V4, gpt-oss, and Z.ai GLM-5.2 are all Apache 2.0 or MIT — no MAU caps. Mistral Medium 3.5 uses a Modified MIT license with a revenue-threshold clause for large enterprises (not Apache/OSI-approved, but commercial-use-permissive for most builders). Kimi K2.7 Code similarly uses a Modified MIT license (commercial-use-permissive, attribution required only above a revenue/MAU threshold). NVIDIA Nemotron 3 Ultra ships under OpenMDW-1.1, the Linux Foundation's open AI-model license that NVIDIA adopted for its Cosmos, Isaac GR00T, and Nemotron families — permissive on commercial use and redistribution, with no revenue/MAU cap, but not itself an OSI-approved software license (it's an AI-artifact-specific framework).

A growing class of capable models ship as **open-weight but commercially restricted**. MiniMax M3 (released June 2026; ~428B total / ~23B active MoE, 1M context, native multimodal, MiniMax Sparse Attention) has downloadable weights on Hugging Face (`MiniMaxAI/MiniMax-M3`) but a restrictive community license that gates commercial self-hosting behind MiniMax authorization (consistent with the M2.x line) — verify the current license before commercial use. By contrast, Qwen 3.7 remains closed-weight, API-only as of June 2026. "Downloadable" is not the same as "OSI-approved": check the license, not just the availability.

### Context length

Long context matters for agents that hold large tool outputs, long conversation histories, or multi-document retrieval results in the context window. Current verified windows: Qwen 3.6 up to 262K (extendable to 1M via YaRN); Llama 4 Maverick 1M / Scout 10M; Gemma 4 12B+ 256K; DeepSeek V4-Pro and V4-Flash 1M; gpt-oss 128K; Mistral Small 4 and Medium 3.5 256K; Granite 4.1 512K; Z.ai GLM-5.2 1M; Kimi K2.7 Code 256K; NVIDIA Nemotron 3 Ultra 1M. Long-context performance degrades before the nominal limit — test your actual retrieval patterns, not just the window size.

### Inference cost and the self-hosting tradeoff

Self-hosting eliminates per-token vendor fees but introduces GPU cost, model-update ops, and batching complexity. MoE architectures (Llama 4, Qwen 3.6 MoE, gpt-oss, DeepSeek) run fewer parameters per token at inference — lower latency and VRAM per request than dense models of comparable quality. Dense models (Phi-4 14B, Granite 4.1 3B/8B) are simpler to serve. For burst or experimental workloads, use an inference provider (Together AI, Fireworks, DeepInfra, Replicate) that hosts the weights — the Apache 2.0 / MIT license means no additional fee to the model vendor.

## Verified sources

- Meta Llama 4 blog: https://ai.meta.com/blog/llama-4-multimodal-intelligence/
- Llama 4 model cards and prompt formats: https://www.llama.com/docs/model-cards-and-prompt-formats/llama4/
- Mistral Small 4 announcement: https://mistral.ai/news/mistral-small-4/
- Mistral Small 4 model card: https://docs.mistral.ai/models/model-cards/mistral-small-4-0-26-03
- Mistral Medium 3.5 model card: https://docs.mistral.ai/models/model-cards/mistral-medium-3-5-26-04
- Mistral Medium 3.5 on Hugging Face: https://huggingface.co/mistralai/Mistral-Medium-3.5-128B
- Mistral Large 3 announcement: https://mistral.ai/news/mistral-3/
- Qwen3 blog: https://qwenlm.github.io/blog/qwen3/
- Qwen3.6 GitHub: https://github.com/QwenLM/Qwen3.6
- Qwen-Agent (tool-calling + MCP): https://github.com/QwenLM/Qwen-Agent
- DeepSeek V4 preview release notes: https://api-docs.deepseek.com/news/news260424
- DeepSeek V4-Pro on Hugging Face: https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro
- DeepSeek V4-Flash on Hugging Face: https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash
- Gemma 4 releases page: https://ai.google.dev/gemma/docs/releases
- Gemma 4 12B Unified announcement: https://blog.google/innovation-and-ai/technology/developers-tools/introducing-gemma-4-12b/
- Function calling with Gemma 4: https://ai.google.dev/gemma/docs/capabilities/text/function-calling-gemma4
- Gemma 4 Apache 2.0 announcement: https://opensource.googleblog.com/2026/03/gemma-4-expanding-the-gemmaverse-with-apache-20.html
- Microsoft Phi-4 on Azure: https://azure.microsoft.com/en-us/products/phi/
- Phi-4-reasoning-vision-15B (Microsoft Research): https://www.microsoft.com/en-us/research/blog/phi-4-reasoning-vision-and-the-lessons-of-training-a-multimodal-reasoning-model/
- Phi-4-reasoning-vision-15B on Hugging Face: https://huggingface.co/microsoft/Phi-4-reasoning-vision-15B
- IBM Granite 4.1 IBM Research blog: https://research.ibm.com/blog/granite-4-1-ai-foundation-models
- OpenAI gpt-oss introduction: https://openai.com/index/introducing-gpt-oss/
- gpt-oss GitHub (weights + model card): https://github.com/openai/gpt-oss
- MiniMax M3 model card (Hugging Face): https://huggingface.co/MiniMaxAI/MiniMax-M3
- MiniMax M3 open-weight coverage (The Decoder, Jun 2026): https://the-decoder.com/minimax-m3-open-weight-model-with-a-million-token-context-challenges-proprietary-leaders/
- Z.ai GLM-5.2 model card (Hugging Face): https://huggingface.co/zai-org/GLM-5.2
- Z.ai GLM-5.2 launch blog (Hugging Face): https://huggingface.co/blog/zai-org/glm-52-blog
- Kimi K2.7 Code model card (Hugging Face): https://huggingface.co/moonshotai/Kimi-K2.7-Code
- Kimi K2.7 Code coverage — specs/architecture/license (CometAPI): https://www.cometapi.com/what-is-kimi-k2-7-code/
- NVIDIA Nemotron 3 Ultra model card (Hugging Face): https://huggingface.co/nvidia/NVIDIA-Nemotron-3-Ultra-550B-A55B-BF16
- Linux Foundation: NVIDIA adopts OpenMDW-1.1 for the Nemotron family: https://www.linuxfoundation.org/press/linux-foundation-releases-openmdw-1.1-nvidia-adopts-openmdw-for-cosmos-isaac-gr00t-ising-and-nemotron-ai-model-families
- NVIDIA Nemotron 3 Ultra release coverage — architecture/specs (MarkTechPost): https://www.marktechpost.com/2026/06/04/nvidia-ai-releases-nemotron-3-ultra-an-open-550b-mixture-of-experts-hybrid-mamba-transformer-for-long-running-agents/


Agentic Payment Protocols: 402, Pay Per Crawl, and x402

Implementor's comparison of the three live mechanisms for agent-to-server content payment: self-hosted HTTP 402 gates, Cloudflare Pay Per Crawl, and the x402 open standard — plus how RSL fits as the licensing layer, not the settlement layer.

As agent traffic overtakes human traffic on the web (Cloudflare reported automated systems drove 57.5% of HTTP requests vs 42.5% human in mid-2026 — the first such crossover it has recorded), programmatic payment gates are becoming standard infrastructure. Three distinct mechanisms have emerged for gating content/resource access. ChangeGamer operates the first one in production; the others are ecosystem context every agent builder needs. A separate class of agent-purchase-authorization standards (ACP, AP2) that covers conventional fiat purchasing on a user's behalf is addressed later in this page.

## Key facts

- Automated traffic reportedly now exceeds human traffic on the web, per Cloudflare's mid-2026 figure — a crossover that is pushing programmatic payment gates toward standard infrastructure.
- Three payment mechanisms are live today: a self-hosted HTTP 402 gate (the pattern ChangeGamer itself runs), Cloudflare Pay Per Crawl, and the open x402 protocol.
- Cloudflare Pay Per Crawl remained in closed/private beta as of July 2026, with Cloudflare acting as Merchant of Record over fiat settlement; on July 1, 2026 Cloudflare announced a broader **Monetization Gateway** (waitlist stage) that generalizes the same x402-based 402 pattern from crawler-only content to any Cloudflare-protected resource (APIs, datasets, MCP tools).
- x402 settles on-chain in stablecoins (mainly USDC) across eight CAIP-2 network families, and is now governed by the Linux Foundation's x402 Foundation, which grew from 22 founding members (April 2026) to 40 members — including new premier members Visa, Mastercard, and Ripple — at its operational launch on July 14, 2026.
- x402 adoption jumped roughly 10x once Apify put 20,000+ Actors on the protocol, and Coinbase has put cumulative on-chain settlement volume in the tens of millions of dollars across a triple-digit-million transaction count — though such published numbers move fast and should be independently re-verified.
- RSL is a licensing-declaration layer, not a settlement mechanism: it states permitted uses and compensation terms in a machine-readable document, while actual payment runs through a separate mechanism.
- ACP (Stripe/OpenAI) and AP2 (Google, governed by the FIDO Alliance) solve a different problem than the three content-payment mechanisms above — letting an agent check out with the account owner's money and consent, rather than gating content or resource access.

## The three payment mechanisms

### 1. Self-hosted HTTP 402 gate (the ChangeGamer pattern)

The origin server returns `402 Payment Required` with a JSON body that a machine can parse and act on. No CDN middleman. No crypto wallet required.

**Flow:**

1. Agent `GET /resources/some-premium-slug`
2. Server → `402 Payment Required` + `Content-Type: application/json`
   ```json
   {
     "error": "payment_required",
     "resource": "some-premium-slug",
     "price_usd": "0.05",
     "payment_url": "https://buy.stripe.com/...",
     "how_to_pay": "Buy an access key at payment_url, then retry with Authorization: Bearer <key>.",
     "terms": "https://changegamer.ai/resources/access-and-pricing.md",
     "license": "https://changegamer.ai/license.xml"
   }
   ```
3. Agent follows `payment_url` to purchase a key (Stripe checkout, EUR fiat).
4. Agent retries: `GET /resources/some-premium-slug` + `Authorization: Bearer cg_<key>`
5. Server validates key, returns `200 OK` with resource body.

The 402 body also carries a partial preview of the gated resource in some implementations, so agents can decide whether the content is worth purchasing before committing.

Full contract documented at /resources/paying-for-access-402 and /resources/access-and-pricing.

### 2. Cloudflare Pay Per Crawl

A CDN-layer 402 marketplace: Cloudflare intercepts crawler requests on behalf of the origin and handles the pricing negotiation. Site owners set a per-crawl price in their Cloudflare dashboard (connected to Stripe); Cloudflare acts as Merchant of Record and remits monthly payouts.

**Flow (reactive path):**

1. Crawler `GET /some-page` (no payment intent header)
2. Cloudflare → `402 Payment Required` with price information
3. Crawler retries with `crawler-max-price` header indicating budget
4. If price <= budget, Cloudflare passes through to origin, returns `200 OK` + `crawler-charged` confirmation header

Crawlers can also use a proactive path: include `crawler-max-price` on the first request and receive a `200` immediately if the price is within budget.

A Discovery API (added December 2025) lets crawler operators programmatically list participating domains rather than discovering them via trial requests.

Settlement is fiat (Stripe). Cloudflare, not the site owner, handles the crawler billing relationship.

Status as of July 2026: **closed/private beta**. Invite-only. Request access via https://cloudflare.com/paypercrawl-signup or contact your Cloudflare account executive.

**Monetization Gateway (announced July 1, 2026, waitlist stage):** Cloudflare's next step beyond Pay Per Crawl — instead of billing only crawler content-fetches, site owners can write an edge rule charging any caller for any Cloudflare-protected resource (a web page, a dataset, an API, or an MCP tool call), enforced at the edge before the request reaches origin infrastructure. It settles over x402 (stablecoins, sub-second settlement) rather than Pay Per Crawl's Stripe-fiat rail — a sign Cloudflare is converging its own payment infrastructure on the same open protocol covered in §3 below, not building a parallel one. Currently early-access/waitlist, not GA.

### 3. x402 — open protocol for on-chain payment

x402 is an open standard that uses HTTP 402 to trigger on-chain stablecoin payment. Originated by Coinbase (open-sourced May 2025); governance moved to the x402 Foundation, co-founded by Coinbase and Cloudflare (announced September 2025) and formalized under the Linux Foundation in April 2026. The Linux Foundation x402 Foundation launched April 2, 2026 with 22 founding members including Google, Stripe, Visa, Mastercard, AWS, Circle, Shopify, and Solana Foundation, then held its **operational launch on July 14, 2026 with 40 member companies** — premier members now include Adyen, AWS, American Express, Circle, Cloudflare, Coinbase, Fiserv, Google, Mastercard, Monad Foundation, MoonPay, Ripple, Shopify, Solana Foundation, Stellar Development Foundation, Stripe, and Visa (WebSearch-corroborated across 4+ independent outlets — the Linux Foundation and PR Newswire primary press releases both 403'd to direct WebFetch this session) — making it a broad cross-industry body, no longer just Coinbase and Cloudflare. Canonical repository: github.com/x402-foundation/x402 (the original coinbase/x402 is now a downstream fork).

**Flow:**

1. Client `GET /resource`
2. Server → `402 Payment Required` + `PAYMENT-REQUIRED` header (base64-encoded JSON: scheme, network, token, amount, recipient address)
3. Client signs a transfer authorization (e.g. EIP-3009 for USDC on EVM chains; Permit2 is supported as a fallback for arbitrary ERC-20 tokens) locally — no gas spent yet
4. Client retries with `PAYMENT-SIGNATURE` header (signed `PaymentPayload`)
5. Server (or a facilitator) broadcasts the transaction on-chain; facilitator does not hold funds
6. Server → `200 OK` + `PAYMENT-RESPONSE` header (settlement confirmation)

Supported networks: the spec now formally supports eight network families via CAIP-2 identifiers — any EVM chain (eip155, e.g. Base, Ethereum, Arbitrum, Polygon, Optimism), Solana, TON, Algorand, Stellar, Aptos, Hedera, and Keeta. Primary stablecoin: USDC. The spec is network- and token-agnostic by design and may extend to fiat facilitators.

The public facilitator at x402.org is operated by Coinbase. Third-party facilitators can be used; the protocol does not mandate Coinbase infrastructure. Coinbase's hosted CDP facilitator settles USDC on Base with no facilitator fee (note: it authenticates with per-request signed JWTs from a CDP API key, not a static token).

**Marketplace-scale adoption (June 2026):** Apify, in partnership with Coinbase, put **20,000+ Apify Actors on x402** — roughly a 10x jump over the ~2,000 payable endpoints the ecosystem offered before. An agent calls an Actor, receives HTTP 402, settles in USDC on Base, and the Actor runs — no Apify account and no API key required. The integration uses both the `exact` scheme (fixed upfront price) and the newer `upto` scheme (authorize a maximum spend, get charged actual usage — Apify backs variable-cost runs with a deposit-and-refund mechanism). This made x402 the largest agent-payable tool marketplace to date and is the clearest signal yet that agent-held wallets are becoming standard operating equipment.

**Discovery — the x402 Bazaar:** Coinbase's developer platform (CDP) exposes a discovery layer that indexes x402-payable endpoints with semantic descriptions, payment metadata, and trust signals: `GET …/v2/x402/discovery/resources` (paginated catalog) plus a hybrid full-text + semantic `…/discovery/search`. Sellers do not register anywhere — **the CDP facilitator auto-catalogs an endpoint the first time it settles a payment for it**. For anyone selling to agents, the first real settlement doubles as the listing event.

Adoption has scaled into the hundreds of millions of transactions across Base and Solana, settled in USDC with zero protocol fees. Coinbase reported on the order of 165 million x402 transactions and approximately $50 million in cumulative settled volume by April 2026 (Coinbase's published figure, alongside ~69,000 active agents). Published figures change rapidly — treat any single snapshot as dated and check the x402 Foundation for current numbers.

## RSL: the licensing layer (not the payment layer)

RSL (Really Simple Licensing) is an XML-based licensing standard that declares *terms*, not *settlement*. Published as an official industry standard (RSL 1.0) on December 10, 2025 by the RSL Collective (co-founded by RSS co-creator Eckart Walther and former Ask.com CEO Doug Leeds).

How it works:

- Publisher hosts a machine-readable license document (e.g. `/license.xml`).
- A `License:` directive in `robots.txt` points to that document.
- The license declares: permitted uses, attribution requirements, compensation model (free / subscription / pay-per-crawl / pay-per-inference / opt-out).
- RSL does not execute payment itself — it declares *that* payment is required and under what terms. Actual settlement is handled by whichever mechanism the publisher uses (Stripe, x402 on-chain, Cloudflare Pay Per Crawl, etc.).

ChangeGamer publishes its own RSL document at /license.xml, discoverable via the `License:` directive in robots.txt.

As of mid-2026, 1,500+ publishers have adopted RSL 1.0 — including the Associated Press, The Guardian, and Vox Media — and Cloudflare and Akamai provide infrastructure support.

## Agent-authorized commerce: ACP and AP2 (a different layer)

The 402 / Pay Per Crawl / x402 mechanisms above gate *content and resource access* — they decide whether an agent can read a page or API response. ACP and AP2 solve a distinct but adjacent problem: how an agent is *authorized to make a purchase on a user's behalf* over conventional fiat rails. These are not content-payment protocols; they are agent-purchase- authorization protocols.

### Stripe Agentic Commerce Protocol (ACP)

Open-source (Apache 2.0), co-developed by Stripe and OpenAI (announced September 2025). ACP standardizes agentic checkout using Shared Payment Tokens that are scoped to a specific seller and bounded by amount and time — preventing an agent from charging more than the user authorized. ACP powers OpenAI Instant Checkout inside ChatGPT and is designed to be adopted by any payment processor or merchant. Spec and reference implementation: https://docs.stripe.com/agentic-commerce/acp.

### Google Agent Payments Protocol (AP2)

Announced by Google in September 2025 and donated to the FIDO Alliance for community governance. AP2 uses W3C Verifiable Credentials carrying three signed "Mandates" (Intent, Cart, Payment) that encode what the agent is authorized to buy, from whom, and with what payment method. It is payment-method agnostic — cards, bank transfers, and stablecoins are all in scope. The ecosystem includes 60+ partners including Mastercard, Visa, PayPal, and Coinbase. Note: a specific stable version number was not independently confirmable from primary FIDO Alliance sources at time of writing; consult https://agentpaymentsprotocol.eu/ for current status.

## Comparison table

| Mechanism | Layer | Who pays whom | Settlement | Standardization | When to use |
|---|---|---|---|---|---|
| Self-hosted HTTP 402 | Origin server | Agent → publisher (direct) | Fiat card (Stripe or equivalent) | No formal spec; well-understood pattern | Full control, any stack, no CDN dependency |
| Cloudflare Pay Per Crawl | CDN (Cloudflare edge) | Crawler operator → Cloudflare → publisher | Fiat (Stripe; Cloudflare as Merchant of Record) | Cloudflare-proprietary; private beta | Cloudflare-hosted sites; hands-off publisher billing |
| x402 | Protocol (HTTP headers) | Agent → resource server (via on-chain tx) | Stablecoin on-chain (USDC; EVM, Solana, + 6 more network families) | Open spec (x402 Foundation, github.com/x402-foundation/x402) | Crypto-native agents; zero-fee micropayments; cross-platform |
| RSL | Licensing declaration (robots.txt + XML) | N/A — terms only | N/A | Open spec (RSL 1.0, December 2025, rslstandard.org) | Declaring licensing terms machine-readably; complements any payment layer |
| ACP | Agent purchase authorization (fiat rails) | Agent → merchant (scoped token, user-authorized) | Fiat (card/bank; Stripe-initiated) | Open spec Apache 2.0 (Stripe + OpenAI, Sep 2025) | Authorizing an agent to check out on a user's behalf over existing rails |
| AP2 | Agent purchase authorization (fiat rails) | Agent → merchant (Verifiable Credential Mandates) | Payment-method agnostic (cards, bank, stablecoins) | FIDO Alliance community governance (Google donation, Sep 2025) | Cross-network agent purchasing with cryptographically signed spending limits |

## What agents must handle

- A `402` response with a JSON body (self-hosted gate or x402): parse `payment_url` or `PAYMENT-REQUIRED` header; follow the appropriate flow.
- A `402` response from Cloudflare Pay Per Crawl: read the price header; retry with `crawler-max-price` if within budget.
- An RSL `License:` directive: fetch `/license.xml`; parse permitted uses before deciding whether to fetch or cache content.
- `Cache-Control: no-store` on any 402 response — never cache it.

## Verified sources

- Cloudflare Pay Per Crawl (private beta, July 2025): https://developers.cloudflare.com/changelog/2025-07-01-pay-per-crawl/
- Cloudflare Pay Per Crawl enhancements (December 2025): https://developers.cloudflare.com/changelog/2025-12-10-pay-per-crawl-enhancements/
- Cloudflare Pay Per Crawl — what it is: https://developers.cloudflare.com/ai-crawl-control/features/pay-per-crawl/what-is-pay-per-crawl/
- Cloudflare Pay Per Crawl signup: https://cloudflare.com/paypercrawl-signup
- Cloudflare x402 integration docs: https://developers.cloudflare.com/agents/agentic-payments/x402/
- Cloudflare Monetization Gateway announcement (July 1, 2026, fetched directly): https://blog.cloudflare.com/monetization-gateway/
- x402 Foundation operational launch, 40 members (July 14, 2026; WebSearch-corroborated, primary press releases 403'd): https://www.coindesk.com/business/2026/07/16/ai-payments-have-a-new-open-standards-body-its-aim-is-to-reinvent-the-internet
- x402 Foundation GitHub (canonical spec): https://github.com/x402-foundation/x402
- x402 network and token support docs: https://docs.x402.org/core-concepts/network-and-token-support
- Coinbase x402 announcement (May 2025): https://www.coinbase.com/developer-platform/discover/launches/x402
- Coinbase + Cloudflare x402 Foundation announcement (September 2025): https://www.coinbase.com/blog/coinbase-and-cloudflare-will-launch-x402-foundation
- Linux Foundation x402 Foundation launch (April 2, 2026): https://www.linuxfoundation.org/press/linux-foundation-is-launching-the-x402-foundation-and-welcoming-the-contribution-of-the-x402-protocol
- Coinbase April 2026 x402 volume figures: https://cryptoadventure.com/coinbase-says-x402-has-processed-160m-agentic-payments/
- Apify x402 launch — 20,000+ Actors (June 2026): https://blog.apify.com/introducing-x402-agentic-payments/
- Apify x402 integration docs (exact/upto schemes): https://docs.apify.com/platform/integrations/x402
- x402 Bazaar discovery layer (CDP docs): https://docs.cdp.coinbase.com/x402/bazaar
- Coinbase x402 Bazaar launch post: https://www.coinbase.com/developer-platform/discover/launches/x402-bazaar
- RSL 1.0 official standard (December 2025): https://rslstandard.org/press/rsl-1-specification-2025
- RSL standard homepage: https://rslstandard.org/
- RSL 1,500-publisher milestone (mid-2026): https://mediacopilot.ai/rsl-licensing-standard-hits-1-0-gains-support-from-1500-publishers/
- Stripe ACP blog (September 2025): https://stripe.com/blog/developing-an-open-standard-for-agentic-commerce
- Stripe ACP specification docs: https://docs.stripe.com/agentic-commerce/acp
- Google AP2 homepage (FIDO Alliance): https://agentpaymentsprotocol.eu/
- AP2 landscape overview: https://www.openfort.io/blog/agentic-payments-landscape
- ChangeGamer 402 gate implementation detail: /resources/paying-for-access-402
- ChangeGamer access and pricing: /resources/access-and-pricing

## Content freshness

This page tracks a fast-moving standards space — Pay Per Crawl's beta status, x402 transaction and settlement figures, RSL publisher counts, and ACP/AP2's version and governance milestones can all shift within weeks. Treat the material here as most reliable as of this page's `updated` date (2026-07-22); mechanisms, adoption numbers, and standardization status are all liable to have moved on by the time you read this. If you're reading this after roughly Q4 2026 (around October 2026), independently re-verify the specifics above rather than relying on this snapshot.