Documentation Index
Fetch the complete documentation index at: https://docs.adcontextprotocol.org/llms.txt
Use this file to discover all available pages before exploring further.
A2B: Testing your first agent call
Free module — No account required. ~20 minutes with Addie. Prerequisite: A2.
Learning objectives
- Initialize a stateful MCP session against the AdCP test agent
- Call
get_productswith a natural-language brief and read the product response - Place a media buy with
create_media_buyand handle all three response shapes - Attach creatives with
sync_creativesand check buy status viaget_media_buys - Diagnose and resolve auth failures, schema mismatches, and async polling delays
Reading list
AdCP quickstart
End-to-end buyer workflow from setup to delivery.
Media buy lifecycle
Media buy status states — pending_creatives, pending_start, active, paused, completed — and what each means for the buyer.
Create media buy task
Full field reference, required fields, and all three response shapes.
Sync creatives task
How to attach assets to a buy, dry-run validation, and assignment patterns.
Error handling
Error codes, retry behavior, and how to read the
errors[] array.MCP integration guide
Session initialization, the
mcp-session-id header, and tool call format.Test agent
All curl examples below target the AdCP training agent:<your-api-key> in every example.
What you’ll do with Addie
Walk through five calls in sequence. Addie demonstrates each call, shows the raw response, then guides you through reproducing it yourself.- Initialize — open a stateful MCP session; save the
mcp-session-idheader - Discover —
get_productswith a brief; read proposals - Buy —
create_media_buy; handle all three response shapes - Attach creatives —
sync_creatives; validate with dry-run first - Poll status —
get_media_buysuntilvalid_actionsshows the buy is serving
Step-by-step curl reference
Use these as a quick reference while working through the module with Addie, or to reproduce any step independently.Step 1 — Initialize a session
Every sequence starts with aninitialize call. The response sets the protocol version and returns an mcp-session-id header — save it.
mcp-session-id in the response headers. Every subsequent call must include it:
Step 2 — Discover products
Callget_products with buying_mode: "brief" and a plain-English description of your campaign goals. The agent returns curated products[] and ready-to-execute proposals[].
content[0].text as JSON. Look for proposals[0].proposal_id — you’ll pass it to create_media_buy.
Step 3 — Place a media buy
Pass theproposal_id from Step 2 and a total_budget. The idempotency_key lets you safely retry if the network drops — use a fresh UUID v4 per request.
| Shape | What it means | Next step |
|---|---|---|
media_buy_id + status: "pending_creatives" | Buy confirmed; attach creatives | Go to Step 4 |
media_buy_id + status: "pending_start" or "active" | Buy confirmed and ready | Creatives already attached or not required |
status: "submitted" + task_id | Buy queued for async processing | Poll tasks/get with task_id (see Async polling below) |
errors[] present, no media_buy_id | Rejected — read errors[0].code | Fix the request and retry with a new idempotency_key |
Step 4 — Attach creatives
A buy inpending_creatives state can’t serve until you call sync_creatives. Use dry_run: true first to validate your creative shapes without writing anything.
"dry_run": true to apply. The response includes creatives[].status — approved, pending_review, or rejected.
Step 5 — Check status
Pollget_media_buys with the media_buy_id from Step 3 to see lifecycle state and valid_actions.
media_buys[0].status field is one of pending_creatives, pending_start, active, paused, completed, rejected, or canceled. The valid_actions array tells you what the buyer can do next.
Async polling
Whencreate_media_buy returns status: "submitted" and a task_id, the buy is queued. Poll until the task completes:
tasks/get is an MCP protocol-level method, not an AdCP tool — it uses "method": "tasks/get" directly rather than the "method": "tools/call" + "name": "..." pattern used for AdCP tasks. It is auto-registered by the MCP SDK alongside tasks/result, tasks/list, and tasks/cancel.task.status is completed, the result field contains the full create_media_buy response with media_buy_id. See the Task lifecycle doc for all MCP task status values.
Common errors
| Symptom | Likely cause | Fix |
|---|---|---|
HTTP 401 / error: "invalid_token" | Expired or wrong API key | Reissue the token from your dashboard; confirm the Bearer prefix |
HTTP 401 / error: "invalid_request" | Authorization header missing | Add -H "Authorization: Bearer <token>" to every call |
errors[] in body, no media_buy_id | Schema validation failure | Read errors[0].field and errors[0].code; fix the field and retry with a new idempotency_key |
status: "submitted" stays indefinitely | Async task stalled | Check task.status via tasks/get; if failed, read task.error.message for the rejection reason |
mcp-session-id: invalid error | Session expired or header missing | Re-run Step 1 to get a fresh session ID |
Assessment
| Dimension | Weight | What Addie looks for |
|---|---|---|
| Conceptual understanding | 10% | Can you describe the MCP session lifecycle and why mcp-session-id is required? |
| Practical knowledge | 40% | Can you trace through all five calls in order with correct task names and request shapes? |
| Problem solving | 30% | Can you reason through what happens when each step fails or returns an unexpected response? |
| Error recovery | 20% | Can you identify the correct fix for auth failures, schema errors, and async polling delays? |
Start this module
Start A2B with Addie
Open Addie and say “I’d like to start certification module A2B.”