AdCP Explorer

Ad Context Protocol (AdCP)

The Ad Context Protocol (AdCP) is an open standard for buying and selling advertising between software agents. Release 3.1.13 defines 64 operations: 62 called over MCP or A2A, 2 over a serve-time HTTP profile.

Release 3.1.13 registers 64 operations across 10 area groups, under 63 distinct names. One of them is required of every conforming agent: get_adcp_capabilities. Every other operation is conditional on the role an agent claims, so no agent implements all 64.

The 64 operations by area

AdCP 3.1.13 — operations per area
Area Operations What it covers
Media Buy 11 Media buy task request/response schemas
Creative 8 Creative protocol task request/response schemas and asset type definitions
Signals 2 Signals protocol task request/response schemas
Protocol 3 Protocol-level tasks that work across all AdCP domain protocols
Accounts 5 Account management task request/response schemas
Brand Protocol 6 Brand protocol for identity retrieval, rights discovery, acquisition, and lifecycle management
Governance 22 Governance protocol for property governance, brand standards, content standards, and compliance
Sponsored Intelligence 4 Sponsored Intelligence Protocol for conversational brand experiences in AI assistants
Trusted Match 2 Trusted Match Protocol (TMP) — real-time execution layer for activating pre-negotiated packages across any surface.
Compliance 1 Compliance testing tool schemas.

list_creative_formats is registered twice, once under media buy and once under creative, with a different request schema each time. Both variants are set out on the schema registry page.

Governance is the largest area at 22 operations, most of it create, read, update and delete over property lists, collections and the content standards those properties are judged against. 30 of the 64 write state; the rest are reads. 13 are marked experimental, including both serve-time operations. An experimental operation may change surface between 3.x releases on at least six weeks' notice, and a seller that implements one declares its feature id in experimental_features on get_adcp_capabilities.

What a buyer implements and what a seller implements

Conformance is scoped by role, not by the 64-operation total. Every conforming agent implements get_adcp_capabilities. The Required rows on the specification's requirements page add the following on top of it.

AdCP 3.1.13 — Required operations per role
Role Required operations Notes
Every conforming agent 1 get_adcp_capabilities, whatever role is claimed
Sales agent7
Governance agent 14 campaign, property and collection lists
Content standards agent4
Signal agent2
Brand agent 1 3 more for a brand agent that also runs Sponsored Intelligence
Creative agent 1 list_creative_formats; every other row in the creative table is Conditional or Optional
Buy-side orchestrator 0 not an MCP or A2A server; it calls a sales agent's operations

Orchestrator conformance is five numbered rules on the same page:

  1. Authenticate.
  2. Send the fields the request schemas require.
  3. Handle asynchronous replies and webhook delivery.
  4. Use media_buy_id on every later call.
  5. Respect creative_deadline.

Every operation by name

Media Buy

Creative

Signals

Protocol

Accounts

Brand Protocol

Governance

Sponsored Intelligence

Trusted Match

Compliance

enums/task-type.json lists two names, search_brands and media_buy_delivery, that are not registered as operations in 3.1.13. In the other direction, property/validate-property-delivery-request.json ships inside 3.1.13 with no group claiming it. The enum file is documentation, maintained alongside the schemas rather than derived from them; the authoritative operation list is the set of task maps in the release's index.json and the request and response schemas they name.

Release 3.1.13

3.1.13 (published stable), last updated 2026-08-11. Releases ship as complete schema trees under dist/schemas/<version>/.

1 operation is registered ahead of release, with request and response schemas in no published release: sync_agent_notification_configs . It is not in the 3.1.13 counts. The 3.1.13 documentation bundle ships a task page for it under dist/docs/3.1.13/protocol/, linking request and response schemas at /schemas/3.1.13/protocol/ that the 3.1.13 schema tree does not contain, so those links resolve to nothing.

Protocol layers

A layer is a grouping of schema groups declared in protocol_layers in the release's index.json. Layer membership is not an input to conformance: Required and Conditional rows are keyed by role.

Negotiation layer
Planning-time protocols for discovery, buying, creative, signals, accounts, governance, brand identity, and sponsored intelligence. Areas: media-buy , creative , signals , account , governance , sponsored-intelligence
Decisioning and serving layer
Trusted Match Protocol schemas for serve-time Context Match and Identity Match decisions. Areas: trusted-match

The layer list does not cover the registry. It names brand, a schema group that holds no operations, and omits protocol, brand-protocol and compliance, which hold 10 operations between them. get_adcp_capabilities is registered under protocol, which the layer list does not name.

The serve-time layer is 2 operations, context_match and identity_match. Their request schemas are the most tightly constrained in the registry; the MUST NOT rules and the correlation gap between them are set out on the trusted match area page.

The shared response envelope

Response schemas compose core/protocol-envelope.json, so 13 of the rows in an operation's response table are shared with every other operation: status, task_id, context, push_notification_config and the rest. The envelope also carries asynchrony: status can come back submitted, working or input-required on any call, and seven operations ship a dedicated async-arm schema for that case — get_products, create_media_buy, update_media_buy, build_creative, get_signals, sync_creatives and sync_catalogs. Everywhere else the unfinished case is handled against the generic envelope. The schema registry page covers the envelope files themselves.

Frequently asked

What version of AdCP is current?
3.1.13, last updated 2026-08-11.
How many operations does AdCP define?
64 in release 3.1.13, spread over 10 areas and 63 distinct names, because one name is registered twice. 30 write state and 13 are marked experimental.
Is AdCP the same as MCP?
No. MCP is a transport, a way for a client to call tools on a server. AdCP is a domain vocabulary that says which advertising operations exist and what their payloads contain: 62 of its 64 operations run over MCP or A2A, and the 2 serve-time operations use a direct HTTP profile instead. An agent declares its transport in get_adcp_capabilities and the declaration applies to every operation it serves. A sales agent MUST support at least one of MCP or A2A, and a call that works over one works the same over the other.
Who governs AdCP?
AgenticAdvertising.org, a pending 501(c)(6) trade association incorporated in Delaware, with four equally weighted voting classes: brands, agencies, publishers and technology providers. The specification is Apache 2.0 and developed in public on GitHub. The reference sell-side implementation is maintained by Prebid.

Related