​

AdCP 3.3 beta program

​

Beta status

​

Know which version string to use

​

Test a beta without an SDK

curl -fLO https://adcontextprotocol.org/protocol/3.3.0-beta.3.tgz
curl -fLO https://adcontextprotocol.org/protocol/3.3.0-beta.3.tgz.sha256
shasum -a 256 -c 3.3.0-beta.3.tgz.sha256
tar -xzf 3.3.0-beta.3.tgz

• manifest.json: release version, bundle contents, skills, and file count;
• schemas/: source-shaped and bundled request/response schemas, including schemas/manifest.json for the task and capability inventory;
• compliance/: storyboards, test kits, vectors, and runner contracts;
• skills/: role guidance for coding agents;
• openapi/: published OpenAPI artifacts.

1. Generate or refresh types from the pinned bundled schemas.
2. Validate representative requests and responses for the roles you implement, including the new 3.3 surfaces you plan to adopt: the account_id identity model and, if you support it, request_account; status on every response through the protocol envelope; expected_confirmation_at, vendor-metric outcome_target goals, reporting_webhook.operation_id, media_buy.features.catalog_ingestion, the DOOH location and dooh_inventory_summary fields, sync_audiences audience sizes, and the experimental spot, print, daypart, loudness, reporting-subscription, live-creative-update, and governance budget.periods[] fields.
3. Compare your advertised tools with schemas/manifest.json.
4. Exercise raw MCP or A2A calls with adcp_version: "3.3-beta.3" against a staging peer that advertises the same pin.
5. Run the compliance assets with a source-compatible runner if you maintain one. Do not weaken production authentication to accommodate a beta runner.

​

Try the preview on the public test agent

curl -s https://test-agent.adcontextprotocol.org/sales/mcp \
  -H "Authorization: Bearer $ADCP_AUTH_TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_adcp_capabilities","arguments":{"adcp_version":"3.3-beta.3"}}}'

• account requests (account.requests): request_account, and account_requests on list_accounts;
• the caller’s authorization, with authorized_at and regranted_at, and revision on each list_accounts account;
• principal-level reporting subscriptions (media_buy.reporting_subscriptions): the reporting_subscriptions section of sync_principal and get_principal, and subscription_coverage on get_reporting_status;
• the reporting_subscription_probe controller scenario, which revokes, reduces, and restores grants and advances a per-caller sandbox clock;
• collection cards (media_buy.collection_cards): include_collections on get_products, list_products, request_proposals and refine_proposals, with images, samples, links, talent brand_ref and follower counts on the CreatorLoop creator channels;
• the collection catalog (media_buy.collection_catalog): list_collections, and the collection_card.* and collection_catalog.bulk_change webhooks registered through sync_accounts;
• the seed_collection controller scenario, which changes the caller’s cards (a sample, a removal, a follower sweep) so the card webhooks fire;
• inventory holds (Hold policy): hold_policy on products and drafts (media_buy.hold_policy), committed proposals with hold_placed_at, ranked holds with hold_rank (media_buy.hold_ranking), per-installment holds (media_buy.installment_holds), extend_hold (media_buy.hold_extension), and the force_hold_unavailable controller scenario.

​

SDK support contract

• exact SDK package version;
• exact AdCP prerelease bundle used to generate or load schemas;
• supported roles and transports;
• known unsupported or raw-only surfaces;
• install command and one tested validation command.

​

SDK guidance

​

SDK convergence

• every first-party SDK’s support for it is marked supported, partial, or unavailable with an exact package version;
• accepted protocol feedback from the previous beta is merged;
• the integration scenarios below have run against the previous beta and identify any correction in the candidate;
• copy/paste installation and validation commands have been executed as published;
• the cumulative migration guide and release notes describe any correction that requires adopter action.

​

Withdrawn after beta.1

​

Required integration evidence

1. Account lifecycle. Call a discovery task (get_products or list_products) with a buyer-declared natural key that was never provisioned. The seller returns ACCOUNT_NOT_FOUND (a seller that provisions lazily instead of exposing sync_accounts may answer without creating the account), and list_accounts shows no new account. Then provision, with sync_accounts or the seller’s lazy path on a provisioning task, and repeat the read.
2. Signed traffic. Send a signed request and receive a signed webhook between two agents that publish identity.brand_json_url. Confirm agent resolution by canonical URL, and that a pinned key missing from the agent’s JWKS is rejected. Against a seller that lists an operation in required_for and a2a_invocation_skill in request_signing.operation_sources, confirm an unsigned A2A call to that operation is rejected. A 3.3 seller that lists the operation in required_for without the marker must reject it too; the marker advertises enforcement, it does not enable it.
3. Catalog intake. For a seller that declares media_buy.features.catalog_ingestion, confirm sync_catalogs rejects an unlisted catalog type, mode, or feed format, and an explicit content_id_type outside a declared supported_content_id_types, with UNSUPPORTED_FEATURE before mutation, including on a dry run, and reports one item_issues entry per item on terminal results and discovery reads under per_item reporting.
4. Delivery webhooks. Register a reporting_webhook with an operation_id and confirm every media_buy_delivery webhook echoes it verbatim. Register one without it and confirm the seller sends no delivery webhooks to it.
5. End to end. Run one buyer and seller lifecycle through purchase, creative assignment, and a delivery readback.

​

What may still change

• Open 3.3 issues
• Open 3.3 pull requests
• Closed 3.3 milestone work

​

In review for 3.3

​

Decisions

​

Open 3.3.0 milestone issues

​

Known beta boundaries

• Experimental surfaces retain their experimental-status contract. A 3.3 beta does not graduate them to stable. The surfaces new in 3.3 are listed in the release notes.
• The 3.3-beta documentation selector moves forward; pinned semver artifacts and documentation snapshots remain immutable.
• Stable schema aliases continue to resolve to stable releases during beta. Use pinned prerelease URLs when validating beta behavior.
• The media_buy_seller/unprovisioned_account_reference storyboard is advisory until runner capability 14.1.0.

​

Report useful feedback

• protocol artifact version and wire pin;
• SDK name and version, or raw wire;
• buyer, seller, creative, signals, brand, measurement, or governance role;
• transport and task name;
• schema path or JSON Pointer involved;
• expected and actual behavior;
• minimal redacted payload and validation error;
• whether the problem blocks interoperability on the beta you tested.

​

Related

• What’s new in AdCP 3.3
• Migrating from 3.2 to 3.3
• Release Notes
• Versions & Compatibility
• Choose your SDK