Gam Seller MCP Node

Governed MCP seller control-plane prototype for future GAM integration.

A Model Context Protocol server that exposes sell-side ad inventory to buyer-side AI agents: discovery, firm pricing, and a buyer-scoped soft commitment primitive. No writes to an ad server exist. Forecasts can come live from Google Ad Manager (opt-in, read-only ForecastService snapshot); the catalog is operator config, and without a GAM connection forecast data is synthetic.

What problem does this solve?

Sell-side ad inventory (availability, pricing, product structure) lives inside ad servers that hold commercially sensitive and sometimes personal data. Giving an AI buyer agent direct API access to GAM or a similar system creates three risks:

How it works

A buyer agent connects via MCP and gets five tools — three read-only, plus a buyer-scoped commitment primitive (create/revoke) that is the sole write surface:

Buyer agent

│ ├── well_known_capabilities ← Signed trust anchor. Check this first. │ Returns: RS256-signed capability document, node identity, privacy posture. │ ├── discover_products ← What can I buy here, and at what firm price? │ Returns: product families the buyer is entitled to see (e.g. "Pre-Roll Video"), │ each with its formats, channel and sites, and its firm list price │ when the publisher has configured them. │ Never returns: deal IDs, internal IDs, raw inventory, exact per-impression pricing. │ ├── get_forecast ← How available is this family next quarter? │ Returns: Low / Mid / High availability bucket. │ Never returns: exact impression counts, CPM curves, floor prices. │ ├── check_availability ← Can you deliver 2.8M impressions of this family in October? │ Returns: available / partial (up to ~2.7M, ~1.3M viewable) / unavailable, as of the │ last forecast — and, when it does not fit, where it would ("November: 3.1M"). │ Volumes come from the forecast rounded down to 2 significant figures │ (configurable by the publisher). │ Never returns: other buyers' bookings, floor prices, audience data. │ ├── create_intent ← Commit to a product at its current firm price (with TTL). │ Records a firm, time-boxed buying intent — rejected if the price is stale or │ mismatched. NOT a GAM order and NOT an inventory hold; it is the handoff artifact │ the classic sales rails pick up. Buyer-scoped: you can only ever commit as yourself. │ └── revoke_intent ← Withdraw one of your own active intents by id.

Every call flows through the same pipeline before any domain logic runs:

  Buyer request

│ ▼ [SEC-GATE-3] Replay detection — deduplicate client_request_id │ ▼ [Auth] RS256 token validation → identity confirmed or AUTH_FAILED │ ▼ [Policy] Surface denylist → entitlement check → scope check (Default-Deny) │ ▼ [Rate limit] N=1 / T=30s per buyer_id │ ▼ [Domain] Catalog / ForecastEngine — synthetic, seeded or live GAM forecast snapshot │ ▼ [Disclosure] Response checked against the tool's strict schema — undeclared field → withheld │ ▼ [Audit] Append-only hash-chained ledger, buyer pseudonymized (HMAC) │ ▼ Response to buyer

Each request-path gate rejects on failure. One honest caveat to the diagram above:

• `client_request_id` (the replay-guard deduplication key) is required by default on every authenticated surface since v0.9.0 — a request without it is rejected, so SEC-GATE-3 cannot be bypassed by omission. An operator can explicitly opt out for legacy clients with MCP_REQUIRE_IDEMPOTENCY_KEY=0, which reopens that bypass.

The rate-limit stage covers every authenticated tool — the read surfaces, create_intent, and revoke_intent — so no authenticated surface bypasses it.

A corrupted or tampered on-disk ledger is detected on startup and the node refuses to serve (fail-closed on load, plus a chain-integrity verify before the first request) rather than resetting to an empty chain.

create_intent runs the same gates and adds one more before it records anything: the buyer's price_ref must match the family's current firm price, or the request is rejected.

Quick start

Run a full pilot in one command. scripts/pilot.sh brings the node up on your config with

production guards on, mints a buyer token per entitled buyer, and prints how to drive a buyer

agent through the whole loop (discover → forecast → commit → revoke) — see

docs/PILOT-QUICKSTART.md. The reference buyer agent lives at

examples/buyer-client-ts/agent.ts; hosting behind TLS is a

filled-in-the-blanks recipe in deploy/.

Install in an MCP client (via npx)

Add the server to your MCP client (Claude Desktop, Claude Code, Cursor, …):

{

"mcpServers": { "gam-seller": { "command": "npx", "args": ["-y", "gam-seller-mcp-node"] } } }

Or run it directly (stdio transport — the default for MCP clients):

npx -y gam-seller-mcp-node

Demo mode. With no config of your own, the node boots on a bundled

pilot-publisher example (illustrative catalog, prices and forecasts) and says so

on stderr — it starts instead of failing, so you can try the tools immediately.

Because buyer surfaces always require a token (there is no anonymous path, even in

demo), the node prints a ready-to-use demo buyer token on startup: copy it and pass

it as the token argument to discover_products / get_forecast to see the example

families, prices and forecasts.

For a real deployment, point MCP_CONFIG_DIR at a directory holding your own

deployment.json, catalog.json, entitlements.json and pricing.json:

`bash

MCP_CONFIG_DIR=/etc/gam-seller/config npx -y gam-seller-mcp-node

`

From source

git clone https://github.com/juan-sibbo/gam-seller-mcp-node.git

cd gam-seller-mcp-node npm install npm run build npm run start:http # HTTP transport on 127.0.0.1:3900

Run the full buyer-agent walkthrough (scripted demo) — the five native tools driven over a real in-process MCP transport, ending in the governed refusals (fail-closed auth, Default-Deny, fail-closed pricing) and a verified audit chain:

npm run demo          # or: npx tsx demo/run-demo.ts

With Docker

docker compose up

The node starts on 127.0.0.1:3900. The well-known document is at /.well-known/seller-mcp-capabilities. Persistent volumes for keys and audit data are pre-configured in docker-compose.yml.

Configure for your publisher

Four JSON files drive all publisher-specific behaviour — no code changes needed. Place them in config/ (from-source) or in the directory named by MCP_CONFIG_DIR (npx/containerised):

deployment.json     # DSR contact, controller model, data retention window

catalog.json # product families + per-buyer access grants entitlements.json # which buyers are entitled to which MCP surfaces pricing.json # firm list prices per family (fail-closed on expiry) forecast.json # OPTIONAL — seed availability buckets from real numbers (still synthetic-labeled) gam.json # OPTIONAL — live GAM forecast (network, service-account key path, family → targeting)

Invalid config always fails closed: a malformed file stops the node rather than running with a silently different access policy. Absent config (no config/ and no MCP_CONFIG_DIR) drops to the bundled config/examples/pilot-publisher/ example — demo mode, announced on stderr — so the node is never a broken install, only ever a real deployment or a clearly-labelled demo.

Taking a pilot onto real inventory (short of a live GAM connection) is all configuration — see docs/PUBLISHER-DEPLOYMENT.md:

• Seed the forecast with the publisher's own availability, exported once from a GAM report, via an optional forecast.json (template: config/examples/pilot-publisher/forecast.sample.json). Buckets become realistic while every result stays synthetic: true — pre-loaded is not a live read, so no live-GAM claim is made.
• Connect GAM live with an optional gam.json (template: config/examples/pilot-publisher/gam.sample.json) and a service account added to the GAM network with a read role that can run forecasts. The node asks ForecastService.getAvailabilityForecast for every configured family × period at boot and every 30 minutes, using prospective line items that are never saved — nothing in GAM is created, modified or reserved. Buyers are answered from that snapshot as Low/Mid/High buckets with synthetic: false; raw availability never leaves the node. Precedence: gam.json > forecast.json > synthetic.
• Close the handoff loop so a committed intent reaches the publisher's sales rails, via MCP_INTENT_HANDOFF=file (a local JSONL drop an operator forwarder tails). The handoff makes no outbound call — forwarding is the operator's process, and a URL value is refused. A handoff record is a notification, never a GAM order or inventory hold.
• Harden for the road: MCP_REQUIRE_OPERATOR_CONFIG=1 (refuse to boot on demo config), MCP_ANCHOR_SINK=tsa (anchor the audit trail to a third party).

Network egress — declared and bounded, not deny-all. Buyer request handling makes no outbound network calls. The live GAM forecast (gam.json) calls Google's OAuth token endpoint and the Ad Manager SOAP API for the configured network, at boot and on the 30-minute refresh cycle — never inside a buyer request, so buyers cannot generate load on the publisher's GAM. Optional audit anchoring can generate operator-configured egress outside the buyer request path (at boot and on the periodic anchor cycle): the TSA backend (MCP_ANCHOR_SINK=tsa) submits the ledger head hash to the configured RFC 3161 authority; the S3 backend (MCP_ANCHOR_SINK=s3) writes the anchor record to the configured Object Lock bucket; a custom sink module (MCP_ANCHOR_SINK= ) runs operator-supplied code. The default local anchor backend performs no external network call. Destinations come only from opera