​

AdCP 3.3 beta program

​

Know which version string to use

​

Test beta.0 without an SDK

curl -fLO https://adcontextprotocol.org/protocol/3.3.0-beta.0.tgz
curl -fLO https://adcontextprotocol.org/protocol/3.3.0-beta.0.tgz.sha256
shasum -a 256 -c 3.3.0-beta.0.tgz.sha256
tar -xzf 3.3.0-beta.0.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: expected_confirmation_at, commercial_terms.definition_pins[], 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, 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.0" 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.

​

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.

​

beta.1 convergence

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

​

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

​

Ratified 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 beta.1 interoperability.

​

Related

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