AdCP — AdCP 3.0

AdCP 3.0 expands the protocol beyond media buying into brand identity, governance, media planning, and conversational brand experiences.

At a glance

Area	v2.x	v3.x
Protocol scope	Media Buy, Signals, Creative	Adds Brand Protocol, Governance, Sponsored Intelligence
Brand identity	No standard mechanism	`brand.json` + community brand registry
Governance	No brand suitability protocol	Property lists, content standards, and brand calibration
Sponsored Intelligence	No conversational brand protocol	Consent-first brand sessions in AI assistants
Accounts Protocol	No formal account model	Named protocol layer: `sync_accounts`, `list_accounts`, `report_usage`, brand registry-grounded identity
Catalogs	`promoted_offerings` creative asset	First-class `sync_catalogs` task with 13 catalog types
Media planning	Products only	Proposals with budget allocations + delivery forecasts
Brand rights	No licensing protocol	`get_rights`, `acquire_rights`, `update_rights` with HMAC-authenticated webhooks
Visual guidelines	No structured brand visuals	`visual_guidelines` on `brand.json` for generative creative systems
Creative governance	No creative evaluation protocol	`get_creative_features` for security scanning, quality, content categorization
Shows and episodes	No content programming model	`shows` on products with distribution IDs, episode lifecycle, break-based inventory
Channel model	9 channels	20 planning-oriented channels (including `sponsored_intelligence`)
Capability discovery	Agent card extensions	Runtime `get_adcp_capabilities` task
Creative assignment	Simple ID arrays	Weighted assignments with placement targeting
Geo targeting	Implicit US-centric	Explicit named systems (global)
Keyword targeting	No keyword support	`keyword_targets` with match types and bid prices
Optimization	Single optimization goal	Multi-goal `optimization_goals` array with metric and event types
Delivery reporting	Aggregate delivery only	Opt-in dimension breakdowns (geo, device, audience, placement, keyword)
Signal pricing	Simple CPM	Structured pricing models (CPM, percent of media, flat fee)
Device targeting	No form-factor targeting	`device_type` (desktop, mobile, tablet, ctv, dooh, unknown) distinct from `device_platform` (OS)
Proximity targeting	No point-based geo targeting	`geo_proximity` with travel time, radius, and GeoJSON methods
Refinement	Free-text with `proposal_id`	Typed change-request array with seller acknowledgment
Error handling	Unstructured errors	`recovery` field (transient, correctable, terminal) + 18 standard error codes
AI provenance	No provenance model	`provenance` object with IPTC source types, C2PA references, regulatory disclosures
Creative compliance	No compliance on briefs	`required_disclosures`, `prohibited_claims`, disclosure positions
Agent ergonomics	Full payloads on every call	`fields` projection, opt-in breakdowns, pre-flight capability filtering
Signal lifecycle	Activate only	`activate` / `deactivate` action on `activate_signal`

New capabilities

Brand Protocol

Buy-side identity through /.well-known/brand.json. Just as publishers use adagents.json to declare properties and authorized agents, brands use brand.json to declare their identity, brand hierarchy, and authorized operators.

Sell side	Buy side
Publisher	House (corporate entity)
Property	Brand (advertising identity)
`adagents.json`	`brand.json`

Four variants: House Portfolio (full brand hierarchy inline), Brand Agent (dynamic via MCP), House Redirect (sub-brand to house domain), and Authoritative Location (hosted URL). Given any domain, the protocol resolves to a canonical brand:

shoes.novabrands.example.com
  -> fetch /.well-known/brand.json
  -> { "house": "novabrands.example.com" }
  -> fetch novabrands.example.com/.well-known/brand.json
  -> search brands[] for property matching "shoes.novabrands.example.com"
  -> Result: { house: "novabrands.example.com", brand_id: "nova_athletics" }

Use cases: creative generation (resolve domain to brand identity), brand verification (check authorized_operators), reporting roll-up (group campaigns by house).

Brand Protocol

Full specification including brand.json variants, resolution flow, and brand identity.

Brand rights lifecycle

Three tasks for licensing and usage rights between brands and content owners:

Task	Purpose
`get_rights`	Discover available rights for a brand’s content
`acquire_rights`	Request and negotiate rights acquisition
`update_rights`	Modify active rights (extend, restrict, revoke)

Rights include generation credentials (API keys or tokens for accessing licensed content), creative approval webhooks (HMAC-SHA256 authenticated callbacks when creatives are submitted for review), and revocation notifications. The protocol distinguishes actionable rejections (fix and resubmit) from final rejections (do not retry). Structured visual_guidelines on brand.json complement rights by giving generative creative systems structured rules for on-brand asset production: photography style, graphic elements, composition, motion, logo placement, colorways, type scale, and restrictions.

Brand rights

Task reference for rights discovery, acquisition, and management.

Shows and episodes

Products can now reference persistent content programs — podcasts, TV series, YouTube channels — via show_ids. get_products responses include a top-level shows array with distribution identifiers for cross-seller matching, episode lifecycle states (scheduled, tentative, live, postponed, cancelled, aired, published), break-based ad inventory configuration, talent linking to brand.json, and international content rating systems. Shows support relationships (spinoff, companion, sequel, prequel, crossover) and derivative content (clips, highlights, recaps) for comprehensive content modeling.

Shows and episodes

Full specification including show schemas, episode lifecycle, and break-based inventory.

Registry API

The AgenticAdvertising.org registry provides a public REST API for resolving brands and properties, discovering agents, and validating authorization. Most endpoints require no authentication.

Capability	Endpoint	Description
Brand resolution	`/api/brands/resolve`	Resolve domain to canonical brand
Property resolution	`/api/properties/resolve`	Resolve publisher domain to property info
Agent discovery	`/api/registry/agents`	List registered agents with capabilities
Authorization check	`/api/registry/validate/property-authorization`	Real-time authorization validation
Search	`/api/search`	Search across brands, publishers, and properties
Community brands	`/api/brands/save`	Contribute brand data (auth required)

The registry complements the protocol: resolve entities via the REST API, then transact via MCP/A2A tasks.

Registry API

Complete endpoint reference with authentication and rate limits.

Proposals and delivery forecasts

Publishers can return proposals alongside products — structured media plans with percentage-based budget allocations that buyers can execute directly via create_media_buy. Proposals encode publisher expertise, replacing ad-hoc product lists with actionable buying strategies. They can be refined through session continuity — subsequent get_products calls within the same session carry conversation history. Delivery forecasts attach to proposals and allocations. Each forecast contains budget points with metric ranges (low/mid/high), showing how delivery scales with spend. Three forecast methods: estimate (rough approximation), modeled (predictive models), guaranteed (contractually committed). Forecasts can predict delivery metrics (impressions, reach, GRPs) and outcomes (purchases, leads, app installs). TV and radio forecasts use demographic_system and demographic for GRP-based planning.

Proposals and forecasting

Complete documentation including budget curves, CTV, retail media, and broadcast audio examples.

Accounts

Migrating from v2? Accounts are entirely new in v3 — there is no v2 equivalent to migrate from. Start with Accounts and Agents for the setup guide.

Formal billing relationships between buyers and sellers via sync_accounts. Four entities:

Entity	Question	How identified
Brand	Whose products are advertised?	House domain + brand_id via `brand.json`
Account	Who gets billed?	Account reference — `account_id` from `list_accounts` or natural key
Operator	Who operates on the brand’s behalf?	Domain (e.g., `acmeagency.example.com`)
Agent	What software places buys?	Authenticated session

Two billing models: operator (operator or brand buying direct is invoiced) and agent (agent consolidates billing). Two trust models: agent-trusted (default, agent declares brands/operators) and operator-scoped (seller requires operator-level credentials). Workflow: get_adcp_capabilities -> sync_accounts -> get_products with account -> create_media_buy with account.

Accounts Protocol

Accounts Protocol overview: identity verification, billing models, and settlement.

Catalogs

First-class catalog lifecycle with sync_catalogs. Thirteen catalog types: structural (offering, product, inventory, store, promotion) and industry-vertical (hotel, flight, job, vehicle, real_estate, education, destination, app). Vertical types have canonical item schemas drawn from Google Ads, Meta, LinkedIn, and Microsoft feed specs. Formats declare what catalogs they need via catalog_requirements. Creatives reference synced catalogs by catalog_id instead of embedding items in assets. Catalogs declare conversion_events and content_id_type for attribution alignment.

Catalogs

Complete documentation including catalog types, sync workflow, format requirements, and conversion events.

Capability discovery

get_adcp_capabilities replaces both adcp-extension.json and the MCP agent card with runtime capability discovery. It returns supported protocols, account billing models, portfolio information, targeting systems, and governance features — all schema-validated.

Agent cards and adcp-extension.json are no longer needed. Buyers discover sellers through adagents.json and call get_adcp_capabilities at runtime. If your v2 integration reads capability data from agent card extensions, switch to get_adcp_capabilities.

get_adcp_capabilities

Full task reference with request/response schemas.

Governance Protocol

Brand suitability and inventory curation. Governance agents manage property lists (curated sets of properties for targeting or exclusion) and content standards (brand suitability policies with per-category block/allow rules). Buyers pass property lists to get_products for filtered inventory discovery, and use calibrate_content for collaborative alignment between brand and governance agent. Governance agents can enforce provenance_required on creative policy and support third-party AI content verification via the verification array on provenance claims.

Governance Protocol

Full specification including property lists, content standards, and calibration.

Publishers	Data providers
Declare properties	Declare signals
Use `property_ids` / `property_tags`	Use `signal_ids` / `signal_tags`
Buyers verify via `publisher_domain`	Buyers verify via `data_provider_domain`

Data provider guide

Complete implementation guide for publishing signal catalogs.

Breaking changes

Media channel taxonomy

v2’s 9 channels are replaced by 20 planning-oriented channels. Five channels carried over unchanged (display, social, ctv, podcast, dooh). The remaining four are split, removed, or renamed.

All code that reads or writes channel values must be updated.

v2 channel	v3 channel(s)	Notes
`display`	`display`	Unchanged
`video`	`olv`, `linear_tv`, `cinema`	Split by distribution context (`ctv` was already separate in v2)
`audio`	`radio`, `streaming_audio`	Split by distribution (`podcast` was already separate in v2)
`native`	Removed	Use format-level properties instead
`social`	`social`	Unchanged
`ctv`	`ctv`	Unchanged
`podcast`	`podcast`	Unchanged
`dooh`	`dooh`	Unchanged
`retail`	`retail_media`	Renamed for clarity

New channels in v3 (no v2 equivalent): search, linear_tv, radio, streaming_audio, ooh, print, cinema, email, gaming, retail_media, influencer, affiliate, product_placement, sponsored_intelligence.

The gaming channel covers intrinsic in-game ads, rewarded video, and playable ads. Rewarded video in gaming apps could also be classified as olv — use gaming when the inventory comes from a gaming budget.

Channels deep dive

Complete mapping guide with examples for each v2 channel, multi-channel products, and capability discovery.

Pricing option field renames

v3 separates hard constraints (publisher-enforced prices) from soft hints (historical percentiles). fixed_rate becomes fixed_price, and price_guidance.floor moves to top-level floor_price.

v2 field	v3 field	Notes
`fixed_rate`	`fixed_price`	Renamed for clarity (it’s a price, not a rate)
`price_guidance.floor`	`floor_price`	Moved to top level as hard constraint

These fields map to standard deal types: fixed_price corresponds to Programmatic Guaranteed (PG) and Preferred Deals, while floor_price corresponds to Private Marketplace (PMP) auctions. Open auction inventory omits both fields.

Pricing deep dive

Fixed-price vs auction examples, price guidance schema, flat-rate pricing, minimum spend, and transition period handling.

Creative assignments with weighting

creative_ids string arrays are replaced by creative_assignments objects that support delivery weighting and placement targeting.

v2 field	v3 field
`creative_ids` (string array)	`creative_assignments` (object array with `creative_id`, `weight`, `placement_ids`)

Creatives deep dive

Weighted assignments, placement targeting, asset discovery with the unified assets array, repeatable groups, and format cards.

Geo targeting with named systems

Metro and postal targeting now require explicit system specification, supporting global markets. Values are grouped by system using { "system": "...", "values": [...] } objects.

v2 field	v3 field
`geo_metros` (string array)	`geo_metros` (system/values objects)
`geo_postal_codes` (string array)	`geo_postal_areas` (system/values objects)

v3 also adds geo_metros_exclude and geo_postal_areas_exclude for negative targeting (e.g., target the US except the New York DMA).

Geo targeting deep dive

Metro and postal system reference tables, exclusion targeting, capability discovery, and a full targeting example.

Other targeting changes

v3 adds several targeting fields beyond geo:

Field	Description
`daypart_targets`	Time-of-day and day-of-week targeting windows
`age_restriction`	Age-gating for restricted content
`device_platform`	Operating system targeting (iOS, Android, Windows, tvOS, etc.)
`device_type`	Device form factor targeting (desktop, mobile, tablet, ctv, dooh, unknown)
`language`	Content language targeting
`keyword_targets` / `negative_keywords`	Keyword targeting for search and retail media with match types (broad, phrase, exact) and per-keyword bid prices
`device_type_exclude`	Negative device form factor targeting
`geo_proximity`	Point-based proximity targeting via travel time isochrones, radius, or GeoJSON geometry

These fields are optional additions — they don’t replace any v2 fields.

Unified asset discovery

Formats now use an assets array with required boolean instead of assets_required. See the creatives deep dive.

Catalogs replace promoted_offerings

The promoted_offerings creative asset type and promoted_offering string field are removed. Catalogs are now first-class protocol objects with their own sync lifecycle (sync_catalogs), format-level requirements (catalog_requirements), and conversion event alignment.

v2 field	v3 replacement
`promoted_offerings` (creative asset)	`catalogs` field on creative manifest
`promoted_offering` (string on media-buy)	Removed — use `brand` + `brief`
`promoted_offering` (string on creative-manifest)	Removed — use `catalogs` field

Catalogs deep dive

Before/after examples, sync_catalogs workflow, catalog_requirements discovery, and migration checklist.

Brand identity unification

Inline brand_manifest objects are replaced by brand references (BrandRef). Task schemas reference brands by { domain, brand_id } instead of passing manifests inline. Brand data is resolved from brand.json or the registry at execution time.

v2/beta field	v3 rc.1 field
`brand_manifest` (inline object)	`brand` (`{ domain, brand_id }`)

Affects: get_products, create_media_buy, build_creative, and property list schemas.

Brand identity deep dive

BrandRef schema, resolution flow, before/after examples, and migration steps.

Product delivery forecasts

estimated_exposures is replaced by a structured forecast field using the DeliveryForecast type.

v2/beta field	v3 rc.1 field
`estimated_exposures` (integer)	`forecast` (DeliveryForecast with time periods, metric ranges, methodology)

proposal_id is removed from the get_products request. Refinement now uses buying_mode: "refine" with a typed refine array of change-requests (see typed refinement). Session continuity (context_id in MCP, contextId in A2A) carries conversation history across calls. Proposal execution via create_media_buy with proposal_id is unchanged.

v2/beta field	v3 rc.1 field
`proposal_id` on `get_products` request	Removed — use `buying_mode: "refine"`

Optimization goals redesign

optimization_goal (singular object) is replaced by optimization_goals (array). Each goal is a discriminated union on kind:

v2/beta field	v3 rc.1 field
`optimization_goal` (single object)	`optimization_goals` (array)
Implicit single goal	`priority` field for multi-goal ordering

Two goal kinds:

metric — Seller-native delivery metrics (clicks, views, reach, engagements, etc.) with cost_per or threshold_rate targets
event — Conversion tracking with event_sources array and optional value_field/value_factor

Optimization goals deep dive

Goal kinds, reach optimization, multi-goal priority, product capabilities, and migration steps.

Signals pricing restructure

The legacy pricing: { cpm } object on signals is replaced by a structured pricing_options array with three pricing models.

v2/beta field	v3 rc.1 field
`pricing.cpm` (number)	`pricing_options[]` (array of pricing model objects)

Three models: cpm, percent_of_media (with optional max_cpm), flat_fee.

Signals deep dive

Pricing models, deliver_to flattening, usage reporting, and migration steps.

Signals deliver_to flattening

The nested deliver_to object in get_signals request is replaced with two top-level fields.

v2/beta field	v3 rc.1 field
`deliver_to.destinations`	`destinations` (top-level)
`deliver_to.countries`	`countries` (top-level)

AudienceMember external_id required

external_id is promoted from a uid-type enum value to a required top-level field on AudienceMember. Every member must have a buyer-assigned stable identifier plus at least one matchable identifier.

Audiences deep dive

Before/after examples, uid-type changes, sync_audiences usage, and migration steps.

refine is redesigned from a nested object with overall/products/proposals to a flat typed array. Each entry is discriminated by scope:

v2/beta field	v3 rc.1 field
`refine.overall` (string)	`{ "scope": "request", "ask": "..." }` array entry
`refine.products[].product_id`	`{ "scope": "product", "id": "..." }`
`refine.products[].notes`	`ask` field

Sellers respond with refinement_applied — a positionally-matched array where each entry reports status (applied, partial, unable) and optional notes.

Refinement deep dive

Change-request types, seller acknowledgment, and before/after examples.

Creative assignments restructured

SyncCreativesRequest.assignments changed from a { creative_id: package_id[] } map to a typed array with explicit fields.

v2/beta field	v3 rc.1 field
`assignments` (object map)	`assignments` (array of `{ creative_id, package_id, weight, placement_ids }`)

Signals account and field consistency

Two consistency changes to signals schemas:

v2/beta field	v3 rc.1 field
`account_id` (string) on `get_signals` and `activate_signal`	`account` (AccountReference object)
`deployments` on `activate_signal`	`destinations` (renamed for consistency with `get_signals`)

Package catalogs as array

v2/beta field	v3 rc.1 field
`catalog` (single Catalog object) on Package	`catalogs` (array of Catalog refs)

Brand tone structured format

Brand tone is now an object type only — string format is removed. Structured tone includes voice, attributes, dos, and donts fields. Existing string values should migrate to { "voice": "<previous-string>" }.

v2/beta field	v3 rc.2 field
`tone` (string or object)	`tone` (object: `{ voice, attributes, dos, donts }`)

Account resolution removed

account_resolution capability field is removed. require_operator_auth now determines both the auth model and account reference style: true means explicit accounts (discover via list_accounts, pass account_id), false means implicit accounts (declare via sync_accounts, pass natural key).

v2/beta/rc.1 field	v3 rc.2 field
`account_resolution` capability	Removed — use `require_operator_auth`

AdCP does not define its own consent framework. Privacy signals (TCF 2.0, GPP, US Privacy String) should be passed via the brief’s ext field or through transport-level headers. Sellers that require consent signals should declare this in get_adcp_capabilities using the extension mechanism.

Removed in v3

Removed	Replacement
`adcp-extension.json` agent card	`get_adcp_capabilities` task
`list_authorized_properties` task	`get_adcp_capabilities` portfolio section
`assets_required` in formats	`assets` array with `required` boolean
`preview_image` in formats	`format_card` object
`creative_ids` in packages	`creative_assignments` array
`geo_postal_codes`	`geo_postal_areas`
`fixed_rate` in pricing	`fixed_price`
`price_guidance.floor`	`floor_price` (top-level)
`promoted_offerings` asset type	`catalogs` field on creative manifest
`promoted_offering` on media-buy	Removed — use `brand` + `brief`
`promoted_offering` on creative-manifest	`catalogs` field
`brand_manifest` (inline object)	`brand` ref (`{ domain, brand_id }`)
`estimated_exposures` on Product	`forecast` (DeliveryForecast)
`proposal_id` on `get_products` request	Session continuity (`context_id` / `contextId`)
`refine` object with `overall`/`products`/`proposals`	`refine` array of typed change-requests
`creative_brief` on `build_creative` request	`brief` asset type in manifest `assets` map
`supports_brief` capability	`supports_compliance`
`creative-brief-ref.json` schema	Deleted — briefs are now asset types
`deployments` on `activate_signal`	`destinations`
`account_id` (string) on signals tasks	`account` (AccountReference)
`report_usage.kind` and `report_usage.operator_id`	Removed
`catalog` (singular) on Package	`catalogs` (array)
`account_resolution` capability	`require_operator_auth` determines account model
`delete_content_standards` task	Archive via `update_content_standards` instead
`get_property_features` task	Property list filters + `get_adcp_capabilities` for feature discovery
`tone` as string on brand.json	Object only: `{ voice, attributes, dos, donts }`

Migration checklists

All implementations

These breaking changes affect anyone reading or writing AdCP data:

Seller agents (publishers, SSPs, networks)

Update all data structures to v3 format (channels, pricing, geo targeting), then implement new capabilities:

Buyer agents and orchestrators (DSPs, agencies, brands)

Update all requests and response handling to v3 format, then integrate new capabilities:

Signals agents (data providers, measurement vendors)

Update schema references from v2 to v3. Signals Protocol doesn’t use media channels in its core model.

Data providers (new in v3)

Publish signal catalogs via adagents.json. See Data Provider Guide.

Create signal catalog in /.well-known/adagents.json
Define signals with id, name, value_type, and optional metadata
Add signal_tags for grouping and efficient authorization
Authorize signals agents using signal_ids or signal_tags authorization types
Validate catalog using AdAgents.json Builder

Creative agents (creative management, DCO providers)

Support new asset discovery and integrate brand identity. Format type field (video, display, audio) is IAB creative classification, not media channels.

Brands (new in v3)

Establish buy-side identity. See brand.json specification.

Host /.well-known/brand.json on your domain
Declare brand portfolio, properties, and authorized operators
Optionally provide brand data (logos, colors, fonts, tone) inline in brand.json or via brand agent
Add visual_guidelines to brand.json for generative creative systems
Implement get_rights / acquire_rights / update_rights if licensing content
Register in the community brand registry if not hosting brand.json

Governance agents (new in v3)

Implement brand suitability capabilities. See Governance Protocol.

Implement property list tasks (create_property_list, get_property_list, etc.)
Implement content standards tasks (create_content_standards, calibrate_content, etc.)
Implement get_adcp_capabilities with governance in supported_protocols
Implement provenance_required enforcement on creative policy
Support verification results from AI detection services
Implement get_creative_features for creative evaluation
Declare creative_features in get_adcp_capabilities

Sponsored Intelligence agents (new in v3)

Implement conversational brand experiences. See Sponsored Intelligence.

Implement SI session tasks (si_initiate_session, si_send_message, si_terminate_session)
Implement get_adcp_capabilities with sponsored_intelligence in supported_protocols

Getting help

Community: Slack
Issues: GitHub Issues
Support: support@adcontextprotocol.org

​At a glance

​New capabilities

​Brand Protocol

Brand Protocol

​Brand rights lifecycle

Brand rights

​Shows and episodes

Shows and episodes

​Registry API

Registry API

​Proposals and delivery forecasts

Proposals and forecasting

​Accounts

Accounts Protocol

​Catalogs

Catalogs

​Capability discovery

get_adcp_capabilities

​Governance Protocol

Governance Protocol

​Sponsored Intelligence Protocol

Sponsored Intelligence

​Signal catalogs for data providers

Data provider guide

​Breaking changes

​Media channel taxonomy

Channels deep dive

​Pricing option field renames

Pricing deep dive

​Creative assignments with weighting

Creatives deep dive

​Geo targeting with named systems

Geo targeting deep dive

​Other targeting changes

​Unified asset discovery

​Catalogs replace promoted_offerings

Catalogs deep dive

​Brand identity unification

Brand identity deep dive

​Product delivery forecasts

​Proposal refinement via buying mode

​Optimization goals redesign

Optimization goals deep dive

​Signals pricing restructure

Signals deep dive

​Signals deliver_to flattening

​AudienceMember external_id required

Audiences deep dive

​Typed refinement with seller acknowledgment

Refinement deep dive

​Creative assignments restructured

​Signals account and field consistency

​Package catalogs as array

​Brand tone structured format

​Account resolution removed

​Privacy and consent

​Removed in v3

​Migration checklists

​Getting help

At a glance

New capabilities

Brand Protocol

Brand rights lifecycle

Shows and episodes

Registry API

Proposals and delivery forecasts

Accounts

Catalogs

Capability discovery

Governance Protocol

Sponsored Intelligence Protocol

Signal catalogs for data providers

Breaking changes

Media channel taxonomy

Pricing option field renames

Creative assignments with weighting

Geo targeting with named systems

Other targeting changes

Unified asset discovery

Catalogs replace promoted_offerings

Brand identity unification

Product delivery forecasts

Proposal refinement via buying mode

Optimization goals redesign

Signals pricing restructure

Signals deliver_to flattening

AudienceMember external_id required

Typed refinement with seller acknowledgment

Creative assignments restructured

Signals account and field consistency

Package catalogs as array

Brand tone structured format

Account resolution removed

Privacy and consent

Removed in v3

Migration checklists

Getting help