- AdCP discovery - Does this agent support AdCP? Which versions?
- Protocol support - Which domain protocols (media_buy, signals, governance, sponsored_intelligence, creative)?
- Auth model - Does this seller trust the agent directly, or must each operator authenticate independently?
- Detailed capabilities - Features, execution integrations, geo targeting, portfolio
/schemas/v3/protocol/get-adcp-capabilities-request.json
Response Schema: /schemas/v3/protocol/get-adcp-capabilities-response.json
Tool-Based Discovery
AdCP uses native MCP/A2A tool discovery. The presence ofget_adcp_capabilities in an agent’s tool list indicates AdCP support.
- Uses standard MCP/A2A mechanisms (no custom extensions)
- Always returns current capabilities (not stale metadata)
- Single source of truth for all capability information
adcp-extension.json) has been removed in v3. Use tool-based discovery instead.
:::
Request Parameters
| Field | Type | Description |
|---|---|---|
protocols | string[] | Optional. Filter to specific protocols (media_buy, signals, governance, sponsored_intelligence, creative). If omitted, returns all supported protocols. |
Response Structure
adcp
Core AdCP protocol information:| Field | Type | Description |
|---|---|---|
major_versions | integer[] | Required. AdCP major versions supported (e.g., [1]) |
supported_protocols
Array of domain protocols this seller supports:account
Account and authentication capabilities. All sellers should declare this section — buyers read it before callingsync_accounts, list_accounts, or any authenticated task. Even simple publishers need account management to handle billing relationships and sandbox testing.
| Field | Type | Description |
|---|---|---|
supported_billing | string[] | Required. Billing models this seller supports: operator, agent. The buyer must pass one of these values as billing in every sync_accounts entry. |
require_operator_auth | boolean | Default: false. Determines the account model. When true (explicit accounts): each operator authenticates independently, buyer discovers accounts via list_accounts, passes account_id. When false (implicit accounts): agent is trusted, buyer declares accounts via sync_accounts, passes natural key (brand + operator). For sandbox, the path follows the account model: explicit accounts discover pre-existing test accounts via list_accounts; implicit accounts declare sandbox via sync_accounts with sandbox: true. |
authorization_endpoint | string | OAuth URL for operator authentication. Present when the seller supports OAuth for operator authentication. Relevant when require_operator_auth: true; if absent, operators obtain credentials out-of-band (seller portal, API key). |
required_for_products | boolean | Default: false. When true, the buyer must establish an account before calling get_products. When false, the buyer can browse products without an account — useful for price comparison and discovery before committing to a seller. |
account_financials | boolean | Default: false. When true, the seller supports get_account_financials for querying spend, credit, and invoice status. Only applicable to operator-billed accounts. |
sandbox | boolean | Default: false. Strongly recommended for production sales agents. When true, the seller supports sandbox accounts for testing. For sandbox, the path follows the account model: explicit accounts discover pre-existing test accounts via list_accounts; implicit accounts declare sandbox via sync_accounts with sandbox: true — no real platform calls or spend. See Sandbox mode. |
Auth models
Implicit accounts (require_operator_auth: false) — The seller trusts the agent’s identity claims. The agent authenticates once with its own bearer token, then calls sync_accounts to declare which brands and operators it represents. The seller provisions accounts based on the agent’s claims, optionally verifying operators against brand.json. All subsequent calls use the agent’s single credential and pass natural keys (brand + operator).
Explicit accounts (require_operator_auth: true) — Each operator must authenticate with the seller directly. The agent obtains a credential per operator — via OAuth using authorization_endpoint, or out-of-band — opens a per-operator session, and discovers accounts via list_accounts. The buyer passes seller-assigned account_id values on all subsequent requests.
For sandbox, the path follows the account model: explicit accounts (require_operator_auth: true) discover pre-existing test accounts via list_accounts; implicit accounts declare sandbox via sync_accounts with sandbox: true.
See Accounts and Agents for full workflows and seller patterns for common combinations of auth model and billing support.
media_buy
Media-buy protocol capabilities. Only present ifmedia_buy is in supported_protocols.
features
Optional media-buy features. If declared true, seller MUST honor requests using that feature.| Feature | Description |
|---|---|
inline_creative_management | Accepts creatives inline in create_media_buy requests |
property_list_filtering | Honors property_list parameter in get_products |
content_standards | Full support for content standards configuration (see content_standards_detail for specifics) |
audience_targeting | Support for audience targeting and ingestion, including sync_audiences |
content_standards_detail
Whenfeatures.content_standards is true, sellers can provide additional detail about their content standards implementation. This gives buyers pre-buy visibility into local evaluation and artifact delivery capabilities.
| Field | Type | Description |
|---|---|---|
supports_local_evaluation | boolean | Whether the seller runs a local evaluation model. When false, local_verdict will always be unevaluated and the failures_only filter on get_media_buy_artifacts is not useful. |
supported_channels | string[] | Channels for which the seller can provide content artifacts. Helps buyers understand which parts of a mixed-channel buy will have content standards coverage. |
supports_webhook_delivery | boolean | Whether the seller supports push-based artifact delivery via artifact_webhook configured at buy creation time. |
supports_local_evaluation is false, the failures_only filter on get_media_buy_artifacts will return an empty result set — all verdicts will be unevaluated.
execution
Technical execution capabilities:| Field | Type | Description |
|---|---|---|
trusted_match | object | TMP support. When present, this seller supports real-time contextual and/or identity matching. Check individual products for per-product TMP capabilities. |
axe_integrations | string[] | Deprecated. Legacy AXE URLs this seller can execute through. Use trusted_match for new integrations. |
creative_specs | object | Creative specification support (VAST versions, MRAID, etc.) |
targeting | object | Targeting capabilities (geo granularity) |
axe_integrations
axe_integrations is an array of Agentic Ad Exchange (AXE) endpoint URLs that this seller can execute through. AXE is the real-time execution layer for AdCP campaigns — it connects buyer agents to programmatic inventory via standardized exchanges.
When a seller declares AXE URLs in their capabilities, buyers can:
- Route impression-level execution through the declared exchange
- Use the exchange’s targeting, optimization, and measurement capabilities
- Execute alongside the seller’s direct-sold inventory
get_adcp_capabilities and filter products to AXE-enabled sellers using required_axe_integrations on get_products.
creative_specs
| Field | Type | Description |
|---|---|---|
vast_versions | string[] | VAST versions supported (e.g., ["4.0", "4.1", "4.2"]) |
mraid_versions | string[] | MRAID versions supported |
vpaid | boolean | VPAID support |
simid | boolean | SIMID support |
targeting
| Field | Type | Description |
|---|---|---|
geo_countries | boolean | Country-level targeting using ISO 3166-1 alpha-2 codes |
geo_regions | boolean | Region/state-level targeting using ISO 3166-2 codes (e.g., US-NY, GB-SCT) |
geo_metros | object | Metro area targeting with system-specific support |
geo_postal_areas | object | Postal area targeting with country and precision support |
age_restriction | object | Age restriction capabilities with supported flag and verification_methods |
device_platform | boolean | Device platform targeting (Sec-CH-UA-Platform values) |
device_type | boolean | Device form factor targeting (desktop, mobile, tablet, ctv, dooh) |
language | boolean | Language targeting (ISO 639-1 codes) |
audience_include | boolean | Audience inclusion targeting (requires features.audience_targeting) |
audience_exclude | boolean | Audience exclusion targeting (requires features.audience_targeting) |
keyword_targets | object | Keyword targeting with supported_match_types array (broad, phrase, exact). Presence indicates support. |
negative_keywords | object | Negative keyword targeting with supported_match_types array. Presence indicates support. |
geo_proximity | object | Proximity targeting from arbitrary coordinates (see below) |
geo_metros.nielsen_dma: true SHOULD mean the seller supports both geo_metros and geo_metros_exclude with Nielsen DMA codes. If a seller only supports one direction (e.g., inclusion but not exclusion), it MUST return a validation error for unsupported fields rather than silently ignoring them. See Targeting Overlays for exclusion semantics.
geo_proximity specifies which proximity targeting methods are supported:
| Field | Type | Description |
|---|---|---|
radius | boolean | Simple radius targeting (distance circle from a point) |
travel_time | boolean | Travel time isochrone targeting (requires a routing engine) |
geometry | boolean | Pre-computed GeoJSON geometry (buyer provides the polygon) |
transport_modes | string[] | Transport modes supported for isochrones: driving, walking, cycling, public_transport |
| System | Description |
|---|---|
nielsen_dma | Nielsen DMA codes (US market, e.g., 501 for NYC) |
uk_itl1 | UK ITL Level 1 regions |
uk_itl2 | UK ITL Level 2 regions |
eurostat_nuts2 | Eurostat NUTS Level 2 regions (EU) |
| System | Description |
|---|---|
us_zip | US 5-digit ZIP codes (e.g., 10001) |
us_zip_plus_four | US 9-digit ZIP+4 codes (e.g., 10001-1234) |
gb_outward | UK postcode district (e.g., SW1, EC1) |
gb_full | UK full postcode (e.g., SW1A 1AA) |
ca_fsa | Canadian Forward Sortation Area (e.g., K1A) |
ca_full | Canadian full postal code (e.g., K1A 0B1) |
de_plz | German Postleitzahl (e.g., 10115) |
fr_code_postal | French code postal (e.g., 75001) |
au_postcode | Australian postcode (e.g., 2000) |
ch_plz | Swiss Postleitzahl (e.g., 8000) |
at_plz | Austrian Postleitzahl (e.g., 1010) |
audience_targeting
Audience targeting capabilities. Only present whenfeatures.audience_targeting is true. Describes what identifier types the seller accepts for audience matching, size constraints, and expected matching latency.
| Field | Type | Required | Description |
|---|---|---|---|
supported_identifier_types | string[] | Required | PII-derived identifier types accepted for audience matching. Buyers should only send identifiers the seller supports. Values: hashed_email, hashed_phone. |
minimum_audience_size | integer | Required | Minimum matched audience size required for targeting. Audiences below this threshold will have status: too_small. Varies by platform (100–1000 is typical). |
supports_platform_customer_id | boolean | When true, the seller accepts the buyer’s CRM/loyalty ID as a matchable identifier. Only applicable when the seller operates a closed ecosystem with a shared ID namespace (e.g., a retailer matching against their loyalty program). Buyers can include platform_customer_id values in AudienceMember.identifiers. Reporting on matched IDs typically requires a clean room or the seller’s own reporting surface. | |
supported_uid_types | string[] | Universal ID types accepted for audience matching (MAIDs, RampID, UID2, etc.). MAID support varies significantly by platform — check this field before sending uids with type: maid. | |
matching_latency_hours | object | Expected matching latency range in hours after upload. Use to calibrate polling cadence and set appropriate expectations before configuring push_notification_config. Shape: { min: integer, max: integer }. |
conversion_tracking
Seller-level conversion tracking capabilities. Declares what the seller supports forkind: "event" optimization goals.
| Field | Type | Description |
|---|---|---|
multi_source_event_dedup | boolean | Whether the seller can deduplicate events across multiple event sources within a single goal. When true, the same event_id from multiple sources counts once. When false or absent, buyers should use a single event source per goal. |
supported_event_types | string[] | Event types this seller can track. If omitted, all standard event types are supported. |
supported_uid_types | string[] | Universal ID types accepted for user matching. |
supported_hashed_identifiers | string[] | Hashed PII types accepted (hashed_email, hashed_phone). Buyers must hash before sending (SHA-256, normalized). |
supported_action_sources | string[] | Action sources this seller accepts events from. |
attribution_windows | object[] | Available attribution windows. Single-element arrays indicate fixed windows; multi-element arrays indicate configurable options the buyer can choose from via attribution_window on optimization goals. |
portfolio
Inventory portfolio information:| Field | Type | Description |
|---|---|---|
publisher_domains | string[] | Required. Publisher domains this seller represents |
primary_channels | string[] | Main advertising channels |
primary_countries | string[] | Main countries (ISO codes) |
description | string | Markdown portfolio description |
advertising_policies | string | Content policies and restrictions |
signals
Signals protocol capabilities. Only present ifsignals is in supported_protocols. Reserved for future use.
creative
Creative protocol capabilities. Only present ifcreative is in supported_protocols.
| Field | Type | Description |
|---|---|---|
supports_compliance | boolean | When true, this creative agent can process briefs with compliance requirements (required_disclosures, prohibited_claims) and will validate that disclosures can be satisfied by the target format. Use the disclosure_positions filter on list_creative_formats to find compatible formats. |
governance
Governance protocol capabilities. Only present ifgovernance is in supported_protocols. Governance agents declare capabilities across four domains: property evaluation, creative evaluation, content standards verification, and policy registry integration.
property_features
Array of property features this governance agent can evaluate. See Property Governance.| Field | Type | Description |
|---|---|---|
feature_id | string | Required. Unique identifier (e.g., mfa_score, coppa_certified). Use registry:{policy_id} prefix for features mapped to Policy Registry entries. |
type | string | Required. Data type: binary, quantitative, or categorical |
range | object | For quantitative: { min, max } |
categories | string[] | For categorical: valid values |
description | string | Human-readable description |
methodology_url | string | URL to methodology documentation |
creative_features
Array of creative features this governance agent can evaluate. Same field schema asproperty_features. See Creative Governance.
Creative governance agents evaluate creatives for security, content categorization, and regulatory compliance. Buyers filter creatives by feature requirements — for example, blocking creatives flagged for auto_redirect or requiring registry:eu_ai_act_article_50 compliance.
content_standards
Content standards verification capabilities. See Content Standards.| Field | Type | Description |
|---|---|---|
supported | boolean | Whether this agent can serve as a content standards verification agent |
calibration_formats | string[] | Artifact asset types this agent can evaluate (e.g., text, image, video, audio) |
policy_registry
Policy registry integration capabilities. See Policy Registry.| Field | Type | Description |
|---|---|---|
supported | boolean | Whether this agent consumes policies from the AdCP Policy Registry |
domains | string[] | Governance domains this agent covers (e.g., campaign, property, creative, content_standards) |
extensions_supported
Array of extension namespaces this agent supports. Buyers can expect meaningful data inext.{namespace} fields on responses from this agent.
| Field | Type | Description |
|---|---|---|
extensions_supported | string[] | Extension namespaces (e.g., ["scope3", "garm"]) |
ext.{namespace} data in responses.
Example:
- Product responses may include
ext.scope3with Scope3 sustainability data - Creative policies may include
ext.garmwith GARM brand suitability categorizations - Responses may include
ext.iab_tcfwith IAB TCF consent data
The Capability Contract
If a capability is declared, the seller MUST honor it.media_buy.execution.targeting.geo_postal_areas.us_zip: true→ Buyer can send US ZIP codes, seller MUST honor themmedia_buy.execution.targeting.geo_metros.nielsen_dma: true→ Buyer can send DMA codes, seller MUST honor themmedia_buy.features.content_standards: true→ Seller MUST apply content standards when provided- AXE URL in
media_buy.execution.axe_integrations→ Seller can execute through that exchange (legacy — new integrations use TMP)
false or omit it.
Common Scenarios
Basic Capability Discovery
Check multi-protocol support
Filter sellers by capability
Use Capabilities to Build Targeting
Capabilities tell you what you CAN specify in create_media_buy targeting. Userequired_geo_targeting to filter products to sellers that support specific geo targeting levels and systems:
| Inventory Type | Filter By | Example |
|---|---|---|
| Digital (display, OLV, CTV) | Capability: required_geo_targeting | Products have broad coverage, target at buy time |
| Local (radio, DOOH, local TV) | Coverage: metros, regions | Products ARE geographically bound |
- Digital inventory: Use
countries+required_geo_targeting(capability), apply fine-grained targeting increate_media_buy - Local inventory: Use
metros/regions(coverage) to find products with coverage in your target markets
Local Inventory Example (Radio, DOOH)
For locally-bound inventory, products ARE geographically specific. A radio station in NYC DMA only covers NYC.Response Example
- AdCP versions: Version 1
- Protocols: Media buy only
- Auth model: Agent-trusted (
require_operator_auth: false) — authenticate once, declare brands viasync_accounts - Billing: Operator or agent billing; default is operator
- Country targeting: Available (ISO 3166-1 alpha-2:
US,GB, etc.) - Region targeting: Available (ISO 3166-2:
US-NY,GB-SCT, etc.) - Metro targeting: Nielsen DMA only (US market)
- Postal targeting: US ZIP, UK outward codes, Canadian FSA
- Audience targeting: Accepts hashed email, hashed phone, UID2, and RampID; minimum matched audience size of 500; matching latency 1–24 hours
- Conversion tracking: Accepts purchase, lead, add_to_cart, view_content events from website/app; no multi-source dedup
- Extensions: Scope3 sustainability data in
ext.scope3
Multi-protocol agent
An agent can implement multiple protocols from a single endpoint. This is common for sellers that manage both media buying and creative generation — the buyer calls all tasks on the same URL.- Media Buy Protocol: Product discovery, media buying, delivery reporting
- Creative Protocol: Creative library management, AI-powered creative generation, variant-level delivery analytics via
get_creative_delivery - Shared account: A single account established via
sync_accountsapplies to both protocols
supported_protocols includes "creative", the buyer can call Creative Protocol tasks (list_creative_formats, sync_creatives, get_creative_delivery, etc.) on this agent. See Creative capabilities on sales agents.
Geo Standards Reference
| Level | System | Examples |
|---|---|---|
| Country | ISO 3166-1 alpha-2 | US, GB, DE, CA |
| Region | ISO 3166-2 | US-NY, GB-SCT, DE-BY, CA-ON |
| Metro (US) | nielsen_dma | 501 (NYC), 803 (LA), 602 (Chicago) |
| Metro (UK) | uk_itl2 | UKI (London), UKD (North West) |
| Metro (EU) | eurostat_nuts2 | DE30 (Berlin), FR10 (Île-de-France) |
| Postal (US) | us_zip | 10001, 90210 |
| Postal (US) | us_zip_plus_four | 10001-1234 |
| Postal (UK) | gb_outward | SW1, EC1, M1 |
| Postal (UK) | gb_full | SW1A 1AA |
| Postal (CA) | ca_fsa | K1A, M5V |
Migration from list_authorized_properties (v2)
Thelist_authorized_properties task was removed in v3. If migrating from v2:
| Old Field | New Location |
|---|---|
publisher_domains | media_buy.portfolio.publisher_domains |
primary_channels | media_buy.portfolio.primary_channels |
primary_countries | media_buy.portfolio.primary_countries |
portfolio_description | media_buy.portfolio.description |
advertising_policies | media_buy.portfolio.advertising_policies |
last_updated | last_updated (top level) |
adcp.major_versions- Version compatibilitysupported_protocols- Which domain protocols are supportedmedia_buy.features- Optional feature supportmedia_buy.execution.axe_integrations- Ad exchange supportmedia_buy.execution.creative_specs- VAST/MRAID versionsmedia_buy.execution.targeting- Geo targeting granularity
Error Handling
| Error Code | Description | Resolution |
|---|---|---|
AUTH_REQUIRED | Authentication needed | Provide credentials |
INTERNAL_ERROR | Server error | Retry with backoff |
Best Practices
1. Cache Capabilities Capabilities rarely change. Cache results and uselast_updated for staleness detection.
2. Check Protocol Support First
Before accessing protocol-specific fields, verify the protocol is in supported_protocols.
3. Check Before Requesting
Don’t send postal areas for a system the seller doesn’t support. Don’t request features the seller doesn’t support.
4. Fail Fast on Incompatibility
If a seller doesn’t support required capabilities, skip them early rather than discovering failures later.
5. Read the Auth Model Before Proceeding
Check account.require_operator_auth immediately after discovery. Agent-trusted and operator-scoped flows diverge significantly: the former uses a single credential for all brands and operators, the latter requires per-operator credentials and sessions.
6. Use Protocol Version for Routing
Route requests to appropriate API versions based on adcp.major_versions.
Next Steps
After discovering capabilities:- Set up accounts: Follow the auth model from
account.require_operator_auth— see Accounts and Agents - Filter products: Use
get_productswith capability-aware filters - Validate properties: Fetch publisher
adagents.jsonfiles for property definitions - Create buys: Use
create_media_buywith supported features
Learn More
- Accounts and Agents - Auth models, account setup, billing
- adagents.json Specification - Publisher authorization files
- Product Filters - Capability-aware filtering
- Content Standards - Brand safety configuration