{ "$schema": "http://json-schema.org/draft-07/schema#", "$id": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/protocol/get-adcp-capabilities-response.json", "title": "Get AdCP Capabilities Response", "description": "Response payload for get_adcp_capabilities task. Protocol-level capability discovery across all AdCP protocols. Each protocol has its own capability section.", "type": "object", "allOf": [ { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/version-envelope.json" }, { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/protocol-envelope.json" }, { "if": { "required": [ "measurement_gateway" ] }, "then": { "properties": { "supported_protocols": { "contains": { "const": "measurement" } }, "experimental_features": { "contains": { "const": "measurement.gateway" } } }, "required": [ "experimental_features" ] } }, { "if": { "required": [ "measurement" ] }, "then": { "properties": { "supported_protocols": { "contains": { "const": "measurement" } }, "experimental_features": { "contains": { "const": "measurement.core" } } }, "required": [ "experimental_features" ] } }, { "if": { "properties": { "media_buy": { "required": [ "performance_feedback" ] } }, "required": [ "media_buy" ] }, "then": { "properties": { "experimental_features": { "contains": { "const": "measurement.core" } } }, "required": [ "experimental_features" ] } }, { "if": { "allOf": [ { "properties": { "request_signing": { "properties": { "supported": { "const": true } }, "required": [ "supported" ] } }, "required": [ "request_signing" ] }, { "anyOf": [ { "properties": { "adcp_version": { "type": "string", "pattern": "^(?:3\\.(?:[2-9]|[1-9][0-9]+)|(?:[4-9]|[1-9][0-9]+)\\.\\d+)(?:-[a-zA-Z0-9.-]+)?$" } }, "required": [ "adcp_version" ] }, { "properties": { "adcp": { "properties": { "supported_versions": { "contains": { "type": "string", "pattern": "^(?:3\\.(?:[2-9]|[1-9][0-9]+)|(?:[4-9]|[1-9][0-9]+)\\.\\d+)(?:-[a-zA-Z0-9.-]+)?$" } } }, "required": [ "supported_versions" ] } }, "required": [ "adcp" ] } ] } ] }, "then": { "properties": { "request_signing": { "properties": { "covers_content_digest": { "const": "required" } }, "required": [ "covers_content_digest" ] } } } }, { "if": { "properties": { "governance": { "required": [ "runtime_attestations" ] } }, "required": [ "governance" ] }, "then": { "properties": { "adcp": { "required": [ "attestations" ] } } } }, { "if": { "properties": { "media_buy": { "properties": { "audience_evidence": { "properties": { "supports_attestation_evaluation": { "const": true } }, "required": [ "supports_attestation_evaluation" ] } }, "required": [ "audience_evidence" ] } }, "required": [ "media_buy" ] }, "then": { "properties": { "adcp": { "required": [ "attestations" ] } } } }, { "if": { "properties": { "media_buy": { "required": [ "rights_attestations" ] } }, "required": [ "media_buy" ] }, "then": { "properties": { "adcp": { "properties": { "attestations": { "properties": { "accepted_claim_types": { "contains": { "const": "https://adcontextprotocol.org/claims/rights/grant" } } } } }, "required": [ "attestations" ] } } } }, { "if": { "properties": { "media_buy": { "required": [ "relationship_notifications" ] } }, "required": [ "media_buy" ] }, "then": { "required": [ "webhook_signing" ], "properties": { "webhook_signing": { "properties": { "supported": { "const": true } }, "required": [ "supported", "profile", "algorithms", "legacy_hmac_fallback" ] } } } }, { "if": { "properties": { "media_buy": { "properties": { "relationship_notifications": { "properties": { "projection_tasks": { "contains": { "const": "list_creatives" } } }, "required": [ "projection_tasks" ] } }, "required": [ "relationship_notifications" ] } }, "required": [ "media_buy" ] }, "then": { "properties": { "supported_protocols": { "contains": { "const": "creative" } } }, "required": [ "supported_protocols" ] } } ], "properties": { "adcp": { "type": "object", "description": "Core AdCP protocol information", "properties": { "major_versions": { "type": "array", "deprecated": true, "description": "DEPRECATED in favor of `supported_versions` (release-precision strings). Servers MUST continue to emit this field through 3.x for backwards compatibility. Removed in 4.0. Original semantics: AdCP major versions supported by this seller. Major versions indicate breaking changes.", "items": { "type": "integer", "minimum": 1 }, "minItems": 1 }, "supported_versions": { "type": "array", "description": "Release-precision (VERSION.RELEASE) AdCP versions this seller speaks. Authoritative for buyer-side release pinning — buyers SHOULD declare `adcp_version` (release-precision string) on each request. Sellers downshift to the highest supported release ≤ the buyer's pin within the same major; cross-major mismatch returns VERSION_UNSUPPORTED. Pre-release tags (e.g. `\"3.1-beta\"`) hang off release.", "items": { "type": "string", "pattern": "^(?:0|[1-9]\\d*)\\.(?:0|[1-9]\\d*)(?:-[a-zA-Z0-9](?:[a-zA-Z0-9.-]*[a-zA-Z0-9])?)?$" }, "minItems": 1, "examples": [ [ "3.0" ], [ "3.0", "3.1" ], [ "3.0", "3.1-beta" ] ] }, "build_version": { "type": "string", "description": "Optional advisory metadata: full semver build identifier of the seller's deployment — MAJOR.MINOR.PATCH plus optional pre-release and build-metadata segments per semver §9–§10. Patches are not part of the wire contract — semver patch by definition introduces no contract change — but surfacing the build helps buyers triage incidents and bug reports against a specific seller deployment lineage. Buyers MUST NOT use this field for negotiation; use `supported_versions` (release-precision) instead.", "pattern": "^\\d+\\.\\d+\\.\\d+(-[a-zA-Z0-9.-]+)?(\\+[a-zA-Z0-9.-]+)?$", "examples": [ "3.0.1", "3.1.2", "3.1.0-beta.3", "3.1.2+scope3.deploy.4821", "3.1.0-beta.3+sha.a1b2c3d" ] }, "idempotency": { "type": "object", "description": "Idempotency semantics for mutating requests. Sellers MUST declare whether they honor idempotency_key replay protection so buyers can reason about safe retry behavior. Modeled as a discriminated union on the supported boolean so that code generators produce two named types (IdempotencySupported, IdempotencyUnsupported) with the replay_ttl_seconds invariant enforced at the type level — draft-07 if/then would be dropped by most generators (openapi-typescript, zod-to-json-schema, datamodel-code-generator pre-0.25, quicktype). Clients MUST NOT assume a default — a seller without this declaration is non-compliant and should be treated as unsafe for retry-sensitive operations.", "oneOf": [ { "title": "IdempotencySupported", "description": "Seller honors idempotency_key replay protection on mutating requests. Replays within replay_ttl_seconds return the cached response (or IDEMPOTENCY_CONFLICT on payload divergence); replays past the window return IDEMPOTENCY_EXPIRED when the seller can still distinguish 'seen and evicted' from 'never seen'.", "properties": { "supported": { "const": true, "description": "Discriminator. True means the seller deduplicates replays — a repeat of the same idempotency_key within replay_ttl_seconds returns the cached response without re-executing side effects." }, "replay_ttl_seconds": { "type": "integer", "description": "How long the seller retains a canonical response for an idempotency_key. Within this window, a replay with the same key + equivalent canonical payload returns the cached response; a replay with a different canonical payload returns IDEMPOTENCY_CONFLICT; a replay past the window returns IDEMPOTENCY_EXPIRED when the seller can still distinguish 'seen and evicted' from 'never seen'. Minimum 3600 (1h); recommended 86400 (24h). Maximum 604800 (7 days) — longer windows force buyers to retain secret keys at rest for extended periods and grow the seller's cache table without bounded benefit.", "minimum": 3600, "maximum": 604800 }, "in_flight_max_seconds": { "type": "integer", "description": "Maximum lifetime in seconds of an in-flight idempotency row before the seller releases it per L1/security.mdx rule 9 (treat the in-flight attempt as failed if the handler does not complete within this bound). Buyer SDKs use this value to compute a retry budget when they see `IDEMPOTENCY_IN_FLIGHT` — cap individual retry waits at this value rather than the much-wider `replay_ttl_seconds` ceiling. Optional in 3.1 (additive declaration); SDKs that don't see the field fall back to rule 9's order-of-magnitude SHOULD heuristic. Required when `supported: true` in 4.0. MUST be no greater than `replay_ttl_seconds` (a bound larger than the replay window is vacuous — any retry past the TTL hits IDEMPOTENCY_EXPIRED regardless of in-flight state); validators MUST enforce this cross-field constraint at the test layer since JSON Schema cannot express field-relative bounds. A buyer that observes top-level `error.retry_after` exceeding this value MAY treat that as a seller bug — the in-flight row cannot legitimately outlive the bound the seller declared.", "minimum": 1, "maximum": 604800 }, "account_id_is_opaque": { "type": "boolean", "description": "When true, the seller derives `account_id` via an HKDF-based one-way transform of the buyer's natural account key rather than echoing the natural key on the wire. Buyers MUST NOT attempt to invert the opaque id and MUST treat it as a blind handle scoped to this seller. Absent or false, callers should assume `account_id` is the natural key (or a server-assigned but non-opaque id). This flag does not change the wire shape, but it DOES change buyer behavior — buyers MUST NOT cache, log, or treat `account_id` as a natural-key analog when this flag is true. Migration note for sellers already returning an opaque id without this flag: set it to true at the next capabilities refresh so buyers stop inferring natural-key semantics; until set, new-buyer replay/retry logic will misclassify these ids as natural keys.", "default": false } }, "required": [ "supported", "replay_ttl_seconds" ] }, { "title": "IdempotencyUnsupported", "description": "Seller does NOT honor idempotency_key replay protection — sending a key is a no-op, the seller will NOT return IDEMPOTENCY_CONFLICT or IDEMPOTENCY_EXPIRED, and a naive retry WILL double-process. Buyers MUST use natural-key checks (e.g., get_media_buys plus request context such as context.internal_campaign_id or package context such as context.buyer_ref) before retrying spend-committing operations against this seller. replay_ttl_seconds and in_flight_max_seconds MUST be absent — they have no meaning without replay support.", "properties": { "supported": { "const": false, "description": "Discriminator. False means the seller does not deduplicate retries." } }, "required": [ "supported" ], "not": { "anyOf": [ { "required": [ "replay_ttl_seconds" ] }, { "required": [ "in_flight_max_seconds" ] } ] } } ] }, "capability_changes": { "type": "object", "description": "Freshness metadata and optional invalidation webhooks for this `get_adcp_capabilities` document. Buyers and registries MAY cache capabilities for up to `cache_ttl_seconds` when present, SHOULD compare `capabilities_version` across refreshes when present, and SHOULD re-run `get_adcp_capabilities` after receiving a `capabilities.changed` webhook. This block describes the agent-wide capability document, not per-caller authorization or account-scoped settings. A material capability change is any externally advertised contract change that can affect routing, validation, conformance coverage, task availability, auth/account handling, sandbox support, billing support, reporting delivery methods, creative-library support, targeting support, protocol versions, or other buyer-visible feature gates. Non-contract operational changes that do not alter the response body do not require a revision or webhook fire.", "properties": { "capabilities_version": { "type": "string", "description": "Opaque revision token for the full capability document. Required when `notifications.supported: true` because `capabilities.changed` webhooks use this as the read-after-notify fence. Sellers SHOULD change this value whenever any material field in `get_adcp_capabilities` changes. Buyers MUST treat it as opaque and compare it only for equality.", "minLength": 1, "maxLength": 255 }, "last_modified": { "type": "string", "format": "date-time", "description": "ISO 8601 timestamp when the seller last changed the advertised capability document. This is the scoped replacement for legacy top-level `last_updated` when buyers need cache validation semantics." }, "cache_ttl_seconds": { "type": "integer", "description": "Maximum time a buyer or registry SHOULD reuse this capability response before refreshing when it has no fresher invalidation signal. Sellers that emit `capabilities.changed` webhooks SHOULD still set a bounded TTL so consumers can recover from missed notifications. This is a cache hint, not an authorization lifetime.", "minimum": 60, "maximum": 604800 }, "notifications": { "type": "object", "description": "Whether the seller supports agent-level capability-change webhooks. When supported, interested consumers register endpoint subscribers with `sync_agent_notification_configs`; each `capabilities.changed` fire is a small invalidation payload, and consumers repair by re-reading `get_adcp_capabilities`.", "oneOf": [ { "title": "CapabilityChangeNotificationsSupported", "properties": { "supported": { "type": "boolean", "const": true, "description": "Discriminator. True means the seller accepts `sync_agent_notification_configs` for `capabilities.changed` subscriptions." }, "registration_task": { "type": "string", "const": "sync_agent_notification_configs", "description": "Task consumers call to manage their caller-scoped agent-level subscriber set." }, "event_types": { "type": "array", "description": "Agent-level notification types this seller can emit for capability changes. Currently only `capabilities.changed` is defined.", "items": { "type": "string", "enum": [ "capabilities.changed" ] }, "minItems": 1, "uniqueItems": true }, "coalescence_window_seconds": { "type": "integer", "description": "Maximum coalescence window the seller applies before firing a `capabilities.changed` webhook after a burst of related capability edits. The default recommendation is at most 300 seconds; latency-sensitive deactivations SHOULD fire sooner.", "minimum": 0, "maximum": 86400 } }, "required": [ "supported", "registration_task", "event_types" ], "additionalProperties": true }, { "title": "CapabilityChangeNotificationsUnsupported", "properties": { "supported": { "type": "boolean", "const": false, "description": "Discriminator. False means consumers must rely on TTL refresh, manual refresh, or registry polling for capability changes." } }, "required": [ "supported" ], "not": { "anyOf": [ { "required": [ "registration_task" ] }, { "required": [ "event_types" ] } ] }, "additionalProperties": true } ] } }, "allOf": [ { "if": { "properties": { "notifications": { "properties": { "supported": { "const": true } }, "required": [ "supported" ] } }, "required": [ "notifications" ] }, "then": { "required": [ "cache_ttl_seconds", "capabilities_version" ] } } ], "additionalProperties": true }, "governance_enforcement": { "type": "object", "description": "Cross-role declaration that this agent enforces buyer-provided governance authorization when performing consequential tasks. This is distinct from the top-level `governance` capability block, which describes an agent that provides governance services. An agent can enforce governance without implementing the governance protocol itself. Absence means the agent makes no governance-enforcement conformance claim.", "properties": { "tasks": { "type": "array", "description": "Task-scoped enforcement claims. The task field is a semantic uniqueness key: an agent MUST emit at most one entry per task and combine all supported modes in that entry. JSON Schema uniqueItems only rejects structurally identical objects, so producers and capability validators MUST enforce task-key uniqueness separately. Values correspond to request schemas annotated with x-governed-commitment. Online execution checks are currently defined only for media-buy tasks, whose prepared result has the PlannedDelivery contract; other roles can enforce signed intent authorization without inventing media-buy fields.", "items": { "discriminator": { "propertyName": "task" }, "oneOf": [ { "properties": { "task": { "type": "string", "const": "create_media_buy" }, "modes": { "type": "array", "items": { "type": "string", "enum": [ "signed_context", "online_execution_check" ] }, "contains": { "const": "signed_context" }, "minItems": 1, "uniqueItems": true } }, "required": [ "task", "modes" ], "additionalProperties": false }, { "properties": { "task": { "type": "string", "const": "update_media_buy" }, "modes": { "type": "array", "items": { "type": "string", "enum": [ "signed_context", "online_execution_check" ] }, "contains": { "const": "signed_context" }, "minItems": 1, "uniqueItems": true } }, "required": [ "task", "modes" ], "additionalProperties": false }, { "properties": { "task": { "type": "string", "const": "buy_products" }, "modes": { "type": "array", "items": { "type": "string", "enum": [ "signed_context", "online_execution_check" ] }, "contains": { "const": "signed_context" }, "minItems": 1, "uniqueItems": true } }, "required": [ "task", "modes" ], "additionalProperties": false }, { "properties": { "task": { "type": "string", "const": "accept_proposal" }, "modes": { "type": "array", "items": { "type": "string", "enum": [ "signed_context", "online_execution_check" ] }, "contains": { "const": "signed_context" }, "minItems": 1, "uniqueItems": true } }, "required": [ "task", "modes" ], "additionalProperties": false }, { "properties": { "task": { "type": "string", "const": "control_media_buy" }, "modes": { "type": "array", "items": { "type": "string", "enum": [ "signed_context", "online_execution_check" ] }, "contains": { "const": "signed_context" }, "minItems": 1, "uniqueItems": true } }, "required": [ "task", "modes" ], "additionalProperties": false }, { "properties": { "task": { "type": "string", "const": "build_creative" }, "modes": { "type": "array", "items": { "type": "string", "const": "signed_context" }, "minItems": 1, "maxItems": 1, "uniqueItems": true } }, "required": [ "task", "modes" ], "additionalProperties": false }, { "properties": { "task": { "type": "string", "const": "activate_signal" }, "modes": { "type": "array", "items": { "type": "string", "const": "signed_context" }, "minItems": 1, "maxItems": 1, "uniqueItems": true } }, "required": [ "task", "modes" ], "additionalProperties": false }, { "properties": { "task": { "type": "string", "const": "acquire_rights" }, "modes": { "type": "array", "items": { "type": "string", "const": "signed_context" }, "minItems": 1, "maxItems": 1, "uniqueItems": true } }, "required": [ "task", "modes" ], "additionalProperties": false }, { "properties": { "task": { "type": "string", "const": "update_rights" }, "modes": { "type": "array", "items": { "type": "string", "const": "signed_context" }, "minItems": 1, "maxItems": 1, "uniqueItems": true } }, "required": [ "task", "modes" ], "additionalProperties": false } ] }, "minItems": 1, "uniqueItems": true } }, "required": [ "tasks" ], "x-status": "experimental", "additionalProperties": false }, "attestations": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/attestation-capabilities.json", "description": "Portable-attestation trust and delivery capabilities for this evaluator. Present only when the agent accepts AttestationReference inputs on one or more domain task surfaces. This block is an allowlist: presenters cannot expand accepted issuers, resolver endpoints, verifier agents, claim types, or proof formats by supplying values in a request." } }, "required": [ "major_versions", "idempotency" ] }, "supported_protocols": { "type": "array", "description": "AdCP protocols this agent supports. Stable values both (a) declare which tools the agent implements and (b) commit the agent to pass the baseline compliance storyboard at /compliance/{version}/protocols/{protocol}/ (with snake_case → kebab-case path mapping, e.g. media_buy → /compliance/.../protocols/media-buy/). The `measurement` protocol is experimental and currently covers provider catalog/output declaration (`measurement.core`) and buyer-orchestrator interchange gateways (`measurement.gateway`). Measurement agents exchange delivery and feedback with the gateway rather than receiving direct seller access. Additional provider tasks and a baseline storyboard land only when concrete workflows require them. Compliance testing support is declared separately via the `compliance_testing` capability block (below), not as a protocol claim.", "items": { "type": "string", "enum": [ "media_buy", "signals", "governance", "sponsored_intelligence", "creative", "brand", "measurement" ] }, "minItems": 1 }, "account": { "type": "object", "description": "Account management capabilities. Describes how accounts are established, what billing models are supported, and whether an account is required before browsing products.", "properties": { "require_operator_auth": { "type": "boolean", "description": "Whether the seller requires operator-level credentials. This declares who must authenticate; it does not by itself declare whether OAuth is used, whether list_accounts is exposed, or which sync_accounts modes are supported. When true, operators authenticate independently with the seller and account-scoped calls use seller/storefront-assigned account_id values because the seller or upstream platform owns the canonical account namespace. If a credential may access more than one account, the seller MUST expose list_accounts and buyers MUST resolve an explicit account_id before the first account-scoped request. If a credential is bound to exactly one account, the seller SHOULD expose list_accounts returning that singleton; a seller MAY omit list_accounts only when it provides the same explicit account_id through another declared path or out-of-band onboarding. When false (default, buyer-declared accounts), the seller trusts the agent's identity claims and account-scoped calls use the advertiser natural key: brand + operator + optional operator_unit, fixed currency, optional buyer-selected account timezone, and sandbox. operator_unit.id is owned by the operator and is distinct from the seller's account_id. The seller normally provisions through sync_accounts, but MAY lazily provision on the first account-scoped request when billing and other required settings are unambiguous from capabilities or onboarding defaults. A lazy-provisioning seller MUST keep accepting the natural key and MUST expose list_accounts for recovery; if buyer input is needed before use, the seller MUST expose sync_accounts.", "default": false }, "authorization_endpoint": { "type": "string", "format": "uri", "description": "OAuth authorization endpoint for obtaining operator-level credentials. Present when the seller supports OAuth for operator authentication. The agent directs the operator to this URL to authenticate and obtain a bearer token. If absent and require_operator_auth is true, operators obtain credentials out-of-band (e.g., seller portal, API key)." }, "supported_billing": { "type": "array", "description": "Billing models this seller supports. operator: seller invoices the operator (agency or brand buying direct). agent: agent consolidates billing. advertiser: seller invoices the advertiser directly, even when a different operator places orders on their behalf. When the buyer calls sync_accounts, it must pass one of these values. A lazy-provisioning seller may omit sync_accounts only when billing can be resolved unambiguously from this capability or the authenticated agent's onboarding defaults.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/billing-party.json" }, "minItems": 1 }, "supported_account_currency_modes": { "type": "array", "description": "Required for sellers implementing AdCP 3.2 advertiser-account provisioning, but optional in this shared 3.x response schema so existing 3.0 and 3.1 capability responses remain valid. Declares whether advertiser accounts are bound to one immutable currency (`fixed`), select currency independently per proposal or media buy (`per_media_buy`), or support both models. When only `fixed` is advertised, buyer-declared provisioning entries MUST include `currency`. When only `per_media_buy` is advertised, they MUST omit it. When both are advertised, presence of `currency` selects a fixed-currency account and omission selects per-media-buy currency. Buyers MUST treat absence as an older seller whose currency mode is not discoverable, not as support for either mode.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/account-currency-mode.json" }, "minItems": 1, "uniqueItems": true }, "timezone": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/account-timezone-capability.json", "description": "Required for sellers implementing AdCP 3.2 advertiser-account provisioning, but optional in the shared 3.x response schema for compatibility. Declares whether the account timezone is seller-wide or fixed per account and whether a buyer must select it during sync_accounts provisioning. Account timezone is the default for account-scoped calendar semantics; feature-specific capability fields explicitly declare exceptions." }, "required_for_products": { "type": "boolean", "description": "Whether an account reference is required for get_products. When true, the buyer must establish an account before browsing products. When false (default), the buyer can browse products without an account — useful for price comparison and discovery before committing to a seller.", "default": false }, "account_financials": { "type": "boolean", "description": "Whether this seller exposes the `get_account_financials` task for querying account-level financial status (spend, credit, invoices). Acts as a **pre-call discriminator** — buyers MUST consult this field before issuing `get_account_financials`; when `false` (or absent), sellers MAY reject the call with an `UNSUPPORTED_FEATURE` / `OPERATION_NOT_SUPPORTED` error. Companion pattern to `creative.bills_through_adcp` (issue #2881) — both fields let buyers gate optional capability calls on a single declared boolean rather than probing for support. Only applicable to operator-billed accounts; sellers using buyer-billed flows omit or set to `false`.", "default": false }, "notifications": { "type": "object", "description": "Whether the seller supports durable account-lifecycle webhooks through account-level `notification_configs[]`. This capability is specifically for account status changes such as approval, rejection, payment-required, suspension, recovery, and closure. When supported, buyers register subscribers with `sync_accounts.accounts[].notification_configs[]`; each `account.status_changed` fire is an invalidation payload, and buyers repair by re-reading `list_accounts` for the account_id.", "oneOf": [ { "title": "AccountNotificationsSupported", "properties": { "supported": { "type": "boolean", "const": true, "description": "Discriminator. True means the seller accepts account-level `notification_configs[]` registrations for account lifecycle events." }, "registration_task": { "type": "string", "const": "sync_accounts", "description": "Task buyers call to manage account-level subscriber sets." }, "read_task": { "type": "string", "const": "list_accounts", "description": "Authoritative repair read after receiving an account lifecycle invalidation." }, "event_types": { "type": "array", "description": "Account lifecycle notification types this seller can emit. Currently only `account.status_changed` is defined.", "items": { "type": "string", "enum": [ "account.status_changed" ] }, "minItems": 1, "uniqueItems": true }, "supports_webhook_activity": { "type": "boolean", "description": "Whether `list_accounts` can return recent delivery attempts in `accounts[].webhook_activity[]` when the buyer requests `include_webhook_activity: true`.", "default": false } }, "required": [ "supported", "registration_task", "read_task", "event_types" ], "additionalProperties": true }, { "title": "AccountNotificationsUnsupported", "properties": { "supported": { "type": "boolean", "const": false, "description": "Discriminator. False means buyers must rely on `sync_accounts` results, `push_notification_config` for one-shot provisioning callbacks, and polling `list_accounts` for later status changes." } }, "required": [ "supported" ], "not": { "anyOf": [ { "required": [ "registration_task" ] }, { "required": [ "read_task" ] }, { "required": [ "event_types" ] } ] }, "additionalProperties": true } ] }, "identity_updates": { "type": "object", "description": "Whether the seller accepts buyer-desired operator identity reconciliation through sync_accounts settings-update entries. Sellers declaring support expose the exact identity transitions they implement, MUST return account revisions from sync_accounts and list_accounts, and MUST return identity_change_preview for dry-run identity updates.", "oneOf": [ { "title": "AccountIdentityUpdatesSupported", "properties": { "supported": { "type": "boolean", "const": true, "description": "Discriminator. True means the seller accepts operator_identity in sync_accounts settings-update mode." }, "supported_changes": { "type": "array", "description": "Identity changes the seller accepts. operator_unit_name covers display-name-only reconciliation within the current operator. operator_unit covers adding, removing, or changing the stable unit id within the current operator and also implies name updates. operator covers an inter-entity operator-domain handoff and encompasses the entire replacement operator identity, including any simultaneous unit addition, removal, or change; a seller need not also advertise operator_unit for that cross-operator replacement.", "items": { "type": "string", "enum": [ "operator_unit_name", "operator_unit", "operator" ] }, "minItems": 1, "uniqueItems": true } }, "required": [ "supported", "supported_changes" ], "additionalProperties": false }, { "title": "AccountIdentityUpdatesUnsupported", "properties": { "supported": { "type": "boolean", "const": false, "description": "Discriminator. False means buyers must not submit operator_identity settings updates." } }, "required": [ "supported" ], "not": { "required": [ "supported_changes" ] }, "additionalProperties": false } ] }, "sandbox": { "type": "boolean", "description": "Whether this seller supports sandbox accounts for testing. Buyer-declared accounts use sandbox: true in sync_accounts or, for an unambiguous lazy-provisioning seller, in the natural-key account reference. Sellers with account_id namespaces expose sandbox accounts as pre-existing test accounts through list_accounts or supply them out-of-band. Requests using a sandbox account perform no real platform calls or spend.", "default": false } }, "required": [ "supported_billing" ] }, "media_buy": { "type": "object", "description": "Media-buy protocol capabilities. Expected when media_buy is in supported_protocols. Sellers declaring media_buy should also include account with supported_billing.", "properties": { "supported_pricing_models": { "type": "array", "description": "Pricing models this seller supports across its product portfolio. Buyers can use this for pre-flight filtering before querying individual products. Individual products may support a subset of these models.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/pricing-model.json" }, "minItems": 1, "uniqueItems": true }, "buying_modes": { "type": "array", "description": "Buying modes this seller supports on get_products. 'brief' (semantic discovery driven by the brief) is universally supported and implicit. 'wholesale' (raw wholesale product feed enumeration — caller omits brief and the seller returns the full priced product feed, paginated) is opt-in and SHOULD be declared explicitly so buyers can probe before issuing wholesale calls. 'refine' lets buyers iterate on prior products/proposals and is also the vehicle for finalizing draft proposals when the seller returns them. Sellers MAY declare ['brief', 'wholesale'] to signal wholesale support; absent declaration is treated as ['brief'] for wholesale-feed probing purposes and sellers MAY return INVALID_REQUEST for wholesale calls they do not support. Symmetric with signals.discovery_modes.", "items": { "type": "string", "enum": [ "brief", "wholesale", "refine" ] }, "minItems": 1, "uniqueItems": true, "default": [ "brief" ] }, "lifecycle_tools": { "type": "array", "description": "Compact product and MediaBuy lifecycle operation names this seller supports. Added in AdCP 3.2 as task-specific contracts that form the 4.0 lifecycle foundation. Sellers may advertise any supported subset while retaining the deprecated get_products/create_media_buy/update_media_buy facades throughout 3.x. Each stateful split task has its own idempotency identity; callers MUST retry with the same tool name.", "items": { "type": "string", "enum": [ "list_products", "request_proposals", "refine_proposals", "decline_proposals", "buy_products", "accept_proposal", "control_media_buy" ] }, "minItems": 1, "uniqueItems": true }, "proposal_refinement": { "type": "object", "description": "Pre-flight support for typed refine_proposals revision dimensions. These declarations mean the seller can parse and mechanically validate a dimension; they never promise that the seller will commercially concede it. Absence means typed-dimension support is unknown and buyers must handle per-result partial or unable outcomes. A dimension omitted from an explicit supported_dimensions list MUST be rejected at task level with UNSUPPORTED_FEATURE before any proposal is created.", "properties": { "supported_dimensions": { "type": "array", "description": "Typed revision dimensions the seller can parse and validate. An empty list authoritatively means ask-only refinement with no typed dimensions. total_budget, cpm, impressions, and flight cover the same-named constraints keys; product_changes covers product_changes; alternatives covers alternatives.count; criteria covers structured discovery criteria. Free-text ask interpretation is competence, not a capability declared here.", "items": { "type": "string", "enum": [ "total_budget", "cpm", "impressions", "flight", "product_changes", "alternatives", "criteria" ] }, "uniqueItems": true }, "max_alternatives": { "type": "integer", "minimum": 2, "maximum": 10, "description": "Optional maximum alternatives.count the seller accepts, up to the protocol maximum of 10. Valid only when supported_dimensions includes alternatives. Requests above this ceiling fail at task level with VALIDATION_ERROR identifying refinements[i].alternatives.count; sellers MUST NOT silently clamp the request or return alternatives_unavailable for the declared ceiling violation." } }, "required": [ "supported_dimensions" ], "allOf": [ { "if": { "required": [ "max_alternatives" ] }, "then": { "properties": { "supported_dimensions": { "contains": { "const": "alternatives" } } } } } ], "additionalProperties": true }, "reporting_delivery_methods": { "type": "array", "description": "How this seller delivers reporting data to buyers. Polling via get_media_buy_delivery is always available as a baseline regardless of this field. This array declares additional push-based delivery methods the seller supports. 'webhook': seller pushes to buyer-provided URL (configured per buy via reporting_webhook). 'offline': seller pushes batch files to a cloud storage bucket (seller-provisioned per account via reporting_bucket on the account object). When absent, only polling is available.", "items": { "type": "string", "enum": [ "webhook", "offline" ] }, "minItems": 1, "uniqueItems": true }, "performance_feedback": { "type": "object", "x-status": "experimental", "description": "Structured seller performance-feedback support beyond the legacy scalar contract. Presence means the seller accepts compact baseline/metric/provenance fields from a buyer orchestrator and returns a feedback_id.", "properties": { "reports_application_status": { "type": "boolean", "x-status": "experimental", "description": "Whether provide_performance_feedback responses include an honest application_status of accepted, applied, or not_applied. accepted is explicitly not an application claim. Sellers that cannot determine optimizer disposition omit this claim or set it false.", "default": false } }, "additionalProperties": true }, "offline_delivery_protocols": { "type": "array", "description": "Cloud storage protocols this seller supports for offline file delivery. Only meaningful when reporting_delivery_methods includes 'offline'. Buyers express a protocol preference in sync_accounts; the seller provisions the account's reporting_bucket using a supported protocol.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/cloud-storage-protocol.json" }, "minItems": 1, "uniqueItems": true }, "supports_proposals": { "type": "boolean", "description": "Conformance declaration that this seller supports proposals through either the compact request/refine/finalize lifecycle or the legacy get_products facade. accept_proposal, or the create_media_buy compatibility facade, consumes a finalized committed proposal_id before expires_at.", "default": false }, "governance_aware": { "type": "boolean", "description": "Compatibility claim used by existing media-buy conformance runners. A value of true corresponds only to online governance consultation for create_media_buy, the historically graded surface. Agents use adcp.governance_enforcement for explicit task-scoped claims, including update_media_buy and cross-role signed-context enforcement.", "default": false }, "propagation_surfaces": { "type": "array", "description": "Where this seller surfaces dependency-resource impairments (creative suspended/rejected post-approval, audience suspended, catalog item withdrawn, event source insufficient, property depublished) to buyers. Non-exclusive: a seller mirroring impairments on both the buy snapshot AND firing webhooks declares `[\"snapshot\", \"webhook\"]` (the common case for premium guaranteed sellers). Each value names one surface where buyers can observe an impairment:\n\n- **`snapshot`** — seller propagates resource transitions into `media_buy.health` and `media_buy.impairments[]` on the next `get_media_buys` read. The `impairment.coherence` compliance assertion grades this surface; storyboards that exercise it (`media_buy_seller/dependency_impairment`, `media_buy_seller/dependency_impairment_cardinality`) require `\"snapshot\"` to be declared, else they grade `not_applicable`.\n- **`webhook`** — seller fires `notification-type: impairment` webhooks (configured via `push_notification_config`). Sellers declaring `\"webhook\"` MUST satisfy the persistent-channel webhook contract for the impairment event type. A seller declaring `[\"webhook\"]` without `\"snapshot\"` is webhook-only — buyers reconcile state from the push channel alone, and snapshot-coherence storyboards grade `not_applicable`.\n- **`out_of_band`** — seller propagates via channels outside the AdCP protocol surface entirely (email to trafficker, separate dashboard, partner-specific notification feed). Long-tail and enterprise-bundled platforms commonly use this when impairment workflows are managed in human channels. Sellers declaring only `[\"out_of_band\"]` are not graded by snapshot or webhook compliance — their bar is the offline agreement, not a protocol assertion. If a seller has impairment data in their API under a non-AdCP field name (a mapping gap, not truly out-of-band), they SHOULD document the mapping rather than declare `out_of_band` — the spec's gap, not the seller's posture, is what `out_of_band` legitimately covers.\n\nDefault: `[\"snapshot\"]` when absent (preserves the existing snapshot-coherence contract for sellers that don't declare). Empty array `[]` is invalid (`minItems: 1`) — omit the field to inherit the default rather than declaring no surfaces. Pick the surfaces that honestly describe where buyers will see impairments on this agent. Mixing is normative — `[\"snapshot\", \"webhook\"]` is the documented common case; `[\"snapshot\", \"webhook\", \"out_of_band\"]` is valid for sellers that ship all three surfaces (rare but legal). See lifecycle.mdx § Compliance for the per-surface contract.", "items": { "type": "string", "enum": [ "snapshot", "webhook", "out_of_band" ] }, "uniqueItems": true, "minItems": 1, "default": [ "snapshot" ] }, "creative_approval_mode": { "type": "string", "description": "Tenant-wide applicability signal for media-buy creative approval behavior. This is not a notification or new approval workflow. `auto_approve` means human review does not block serving eligibility after creatives are assigned and automated validation passes. `require_human` means one or more products/accounts may require manual review before creatives become eligible to serve; buyers and compliance runners MUST treat this as a worst-case ceiling across this seller's portfolio unless a future product-level override says otherwise. Compliance runners use this mainly to decide whether auto-approval-dependent storyboards apply. When absent, approval behavior is legacy-unspecified; runners SHOULD NOT treat omission as an affirmative auto-approval claim. `ai_assisted` is intentionally not part of the enum until a behavioral contract is defined.", "enum": [ "auto_approve", "require_human" ] }, "supported_indicator_types": { "type": "array", "description": "Indicator types this seller can expose on get_media_buys media-buy/package/creative-assignment snapshots. Each type's meaning is defined by the negotiated AdCP release; indicator types do not carry independent sub-versions. This is availability, not complete upstream coverage. Poll-only sellers may declare this field without relationship_notifications. If relationship_notifications includes indicators.changed, this field is required so receivers know which durable indicator types can be repaired.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/indicator-type.json" }, "minItems": 1, "uniqueItems": true }, "relationship_notifications": { "type": "object", "description": "Optional durable account-level invalidations for indicator, creative-assignment, and assignment-approval changes. A seller may expose indicators only through polling and omit this block. A seller without an indicator catalog may declare creative.assignment_changed alone. get_media_buys is the complete authoritative repair read. creative.assignment_changed is independent of the optional bounded list_creatives reverse projection, so inline-only sellers can advertise approval and assignment invalidations. Presence means the seller accepts the declared subscriptions through sync_accounts notification_configs. Timestamp-only reevaluation does not fire. Poll-based upstream integrations fire when they detect a change; this declaration does not promise upstream detection latency.", "properties": { "supported": { "type": "boolean", "const": true, "description": "Discriminator. True means the declared invalidation event types are supported." }, "registration_task": { "type": "string", "const": "sync_accounts", "description": "Task buyers call to register account-level subscribers." }, "event_types": { "type": "array", "description": "Relationship invalidation events supported by this seller. indicators.changed requires supported_indicator_types but is not required merely because polling readback is available. creative.assignment_changed is independently available when the seller can detect assignment or assignment-approval changes; it does not require indicator support or list_creatives.", "items": { "type": "string", "enum": [ "indicators.changed", "creative.assignment_changed" ] }, "minItems": 1, "maxItems": 2, "uniqueItems": true }, "repair_tasks": { "type": "array", "description": "Complete authoritative snapshot reads used after an invalidation. get_media_buys is mandatory and is the only 3.2 repair task for this contract.", "items": { "type": "string", "const": "get_media_buys" }, "minItems": 1, "maxItems": 1, "uniqueItems": true }, "projection_tasks": { "type": "array", "description": "Optional bounded reverse projections of relationship-scoped indicator and approval state. list_creatives is a discovery/read convenience for creative-library sellers, not a complete repair path; declaring it also requires creative in supported_protocols. Buyers fall back to get_media_buys whenever nested assignments are truncated or a relationship must be proven absent.", "items": { "type": "string", "const": "list_creatives" }, "minItems": 1, "maxItems": 1, "uniqueItems": true }, "supports_webhook_activity": { "type": "boolean", "description": "Whether the declared repair tasks can return recent delivery attempts for these account-level invalidations when include_webhook_activity is true.", "default": false } }, "required": [ "supported", "registration_task", "event_types", "repair_tasks" ], "additionalProperties": false }, "features": { "allOf": [ { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/media-buy-features.json" }, { "if": { "required": [ "catalog_item_availability_updates" ], "properties": { "catalog_item_availability_updates": { "const": true } } }, "then": { "required": [ "catalog_management" ], "properties": { "catalog_management": { "const": true } } } } ] }, "execution": { "type": "object", "description": "Technical execution capabilities for media buying", "properties": { "trusted_match": { "type": "object", "description": "Trusted Match Protocol (TMP) support. Presence of this object indicates the seller has TMP infrastructure deployed. Check individual products via get_products for per-product TMP capabilities.", "x-status": "experimental", "properties": { "surfaces": { "type": "array", "description": "Surface types this seller supports via TMP.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/property-type.json" } } } }, "axe_integrations": { "type": "array", "deprecated": true, "description": "Deprecated. Legacy AXE integrations. Use trusted_match for new integrations.", "items": { "type": "string", "format": "uri" } }, "creative_specs": { "type": "object", "description": "Creative specification support", "properties": { "vast_versions": { "type": "array", "description": "VAST versions supported for video creatives", "items": { "type": "string", "pattern": "^[0-9]+\\.[0-9]+$" } }, "mraid_versions": { "type": "array", "description": "MRAID versions supported for rich media mobile creatives", "items": { "type": "string", "pattern": "^[0-9]+\\.[0-9]+$" } }, "vpaid": { "type": "boolean", "description": "VPAID support for interactive video ads" }, "simid": { "type": "boolean", "description": "SIMID support for interactive video ads" }, "vast_validation": { "type": "string", "enum": [ "structural", "document", "wrapper" ], "default": "structural", "description": "Level of VAST asset validation the seller performs at sync_creatives (including dry_run): 'structural' checks manifest shape and format requirements only and never inspects the VAST document; 'document' additionally parses the VAST document and can return VAST_PARSE_FAILED / VAST_VERSION_MISMATCH; 'wrapper' additionally resolves the wrapper chain and can return VAST_WRAPPER_DEPTH_EXCEEDED. Absent means 'structural'. See the VAST Validation section of the video channel documentation for the normative checks at each level." } } }, "targeting": { "type": "object", "description": "Targeting capabilities. If declared true/supported, buyer can use these targeting parameters and seller MUST honor them.", "properties": { "geo_countries": { "type": "boolean", "description": "Country-level targeting using ISO 3166-1 alpha-2 codes" }, "geo_regions": { "description": "ISO 3166-2 subdivision inclusion targeting. A legacy boolean is a coarse seller-wide declaration. Structured country/value entries are individually supported within the response scope, but do not promise joint composability or availability through the same execution route or account. Only Product.overlay_support supplies the binding set of executable targeting permissions for a configured Product.", "anyOf": [ { "type": "boolean" }, { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/geo-region-support.json" } ] }, "geo_regions_exclude": { "description": "ISO 3166-2 subdivision exclusion targeting, declared independently from inclusion. Structured country/value entries are individually supported within the response scope, but do not promise joint composability or availability through the same execution route or account. Only Product.overlay_support supplies the binding set of executable targeting permissions for a configured Product; absence means buyers cannot infer exclusion support from geo_regions alone.", "anyOf": [ { "type": "boolean" }, { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/geo-region-support.json" } ] }, "geo_metros": { "type": "object", "description": "Metro area targeting. Properties indicate which classification systems are supported.", "properties": { "nielsen_dma": { "type": "boolean" }, "uk_itl1": { "type": "boolean" }, "uk_itl2": { "type": "boolean" }, "eurostat_nuts2": { "type": "boolean" } }, "additionalProperties": false }, "geo_postal_areas": { "description": "Postal area targeting. Prefer the native country-keyed map where each ISO 3166-1 alpha-2 country lists supported country-local postal systems. Deprecated legacy country-fused postal-system boolean aliases may be emitted alongside native country keys during migration.", "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/postal-area-support.json" }, "geo_places": { "type": "object", "description": "Place targeting support keyed by collision-safe identifier system. Each system declares exact country-to-place-type combinations, accepted catalog versions, and a machine-readable resolver. Sellers MUST reject unsupported systems, country/type pairs, versions, and identifiers rather than silently dropping them.", "propertyNames": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/geo-place-system.json" }, "additionalProperties": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/geo-place-support.json" }, "minProperties": 1 }, "age_restriction": { "type": "object", "description": "Age restriction capabilities for compliance (alcohol, gambling)", "properties": { "supported": { "type": "boolean", "description": "Whether seller supports age restrictions" }, "verification_methods": { "type": "array", "description": "Age verification methods this seller supports", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/age-verification-method.json" } } } }, "demographics": { "type": "object", "description": "Seller-wide discovery rollup for canonical demographic targeting. supported=true means at least one product implements the demographic targeting contract; it does not authorize demographic targeting on every product. Buyers MUST inspect Product.demographic_targeting for exact execution modes, bounds, intervals, and unknown-age behavior.", "properties": { "supported": { "type": "boolean", "description": "Whether at least one seller product supports canonical demographic targeting." } }, "required": [ "supported" ], "additionalProperties": true }, "language": { "description": "Language-preference targeting support. A legacy boolean is a coarse declaration. The structured form can enumerate the exact canonical BCP 47 targeting ranges the seller accepts. Buyers MUST treat supported_languages as exact selectable values: a declared 'fr' does not by itself authorize a request for 'fr-CA'. Sellers MUST reject unsupported requested values rather than silently widening or dropping them.", "oneOf": [ { "type": "boolean" }, { "type": "object", "properties": { "supported": { "type": "boolean", "description": "Whether seller supports language-preference targeting" }, "supported_languages": { "type": "array", "description": "Exact canonical BCP 47 language ranges accepted in targeting.language. Omission means the seller makes no exhaustive language-list declaration.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/locale-tag.json" } } } } ] }, "keyword_targets": { "type": "object", "description": "Keyword targeting capabilities. Presence indicates support for targeting_overlay.keyword_targets and keyword_targets_add/remove in update_media_buy.", "properties": { "supported_match_types": { "type": "array", "description": "Match types this seller supports for keyword targets. Sellers must reject goals with unsupported match types.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/match-type.json" }, "minItems": 1 } }, "required": [ "supported_match_types" ] }, "negative_keywords": { "type": "object", "description": "Negative keyword capabilities. Presence indicates support for targeting_overlay.negative_keywords and negative_keywords_add/remove in update_media_buy.", "properties": { "supported_match_types": { "type": "array", "description": "Match types this seller supports for negative keywords. Sellers must reject goals with unsupported match types.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/match-type.json" }, "minItems": 1 } }, "required": [ "supported_match_types" ] }, "placement_selection": { "type": "boolean", "description": "When true, seller-wide rollup indicating at least one product supports targeting_overlay.placement_selection. False or absence makes no product-level promise. Product.overlay_support and Product.placements remain authoritative for a selected product." }, "property_list": { "type": "boolean", "description": "When true, seller-wide rollup indicating at least one product supports targeting_overlay.property_list inclusion targeting. False or absence makes no product-level promise. Product.overlay_support is authoritative." }, "property_list_exclude": { "type": "boolean", "description": "When true, seller-wide rollup indicating at least one product supports targeting_overlay.property_list_exclude targeting. False or absence makes no product-level promise. Product.overlay_support is authoritative." }, "collection_list": { "type": "boolean", "description": "When true, seller-wide rollup indicating at least one product supports targeting_overlay.collection_list inclusion targeting. False or absence makes no product-level promise. Product.overlay_support is authoritative." }, "collection_list_exclude": { "type": "boolean", "description": "When true, seller-wide rollup indicating at least one product supports targeting_overlay.collection_list_exclude targeting. False or absence makes no product-level promise. Product.overlay_support is authoritative." }, "geo_proximity": { "type": "object", "description": "Proximity targeting capabilities from arbitrary coordinates via targeting_overlay.geo_proximity.", "properties": { "radius": { "type": "boolean", "description": "Whether seller supports simple radius targeting (distance circle from a point)" }, "travel_time": { "type": "boolean", "description": "Whether seller supports travel time isochrone targeting (requires a routing engine)" }, "geometry": { "type": "boolean", "description": "Whether seller supports pre-computed GeoJSON geometry (buyer provides the polygon)" }, "transport_modes": { "type": "array", "description": "Transport modes supported for travel_time isochrones. Only relevant when travel_time is true.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/transport-mode.json" }, "minItems": 1 } } } } } } }, "audience_evidence": { "type": "object", "description": "Support for structured product audience evidence and buyer-authored evidence policy. Presence means the seller can publish Product.audience_evidence, preserve immutable snapshots through package readback, and evaluate the declared policy modes. It does not declare audience-targeting capability.", "properties": { "supported_requirement_modes": { "type": "array", "description": "Buyer policy modes the seller evaluates. A seller MUST NOT silently ignore a mode it does not list.", "items": { "type": "string", "enum": [ "required", "preferred" ] }, "minItems": 1, "uniqueItems": true }, "supported_presence_modes": { "type": "array", "description": "Evidence-presence semantics the seller supports.", "items": { "type": "string", "enum": [ "required", "when_available" ] }, "minItems": 1, "uniqueItems": true }, "supports_attestation_evaluation": { "type": "boolean", "description": "Whether the seller evaluates audience-evidence attestation_refs under its core adcp.attestations policy and returns the exact reference and AttestationEvaluation in package readback." } }, "required": [ "supported_requirement_modes", "supported_presence_modes", "supports_attestation_evaluation" ], "additionalProperties": true }, "rights_attestations": { "type": "object", "description": "Seller evaluation policy for portable rights-grant attestations carried on creative rights constraints. Presence requires adcp.attestations and the rights-grant claim URI in accepted_claim_types. The seller remains verifier-of-record and never treats verification_url or a buyer-authored evaluation as authorization.", "properties": { "requirement": { "type": "string", "enum": [ "optional", "required" ], "description": "required means every applicable rights constraint needs at least one current verified attestation evaluation before the creative is eligible to serve. optional permits independent legacy contractual policy, but unattested constraints remain machine-unverified and verification_url is never a downgrade path." } }, "required": [ "requirement" ], "additionalProperties": false }, "audience_targeting": { "type": "object", "description": "Audience targeting capabilities. Presence of this object indicates the seller supports audience targeting, including sync_audiences and audience_include/audience_exclude in targeting overlays.", "properties": { "supported_identifier_types": { "type": "array", "description": "PII-derived identifier types accepted for audience matching. Buyers should only send identifiers the seller supports.", "items": { "type": "string", "enum": [ "hashed_email", "hashed_phone" ] }, "minItems": 1 }, "supports_platform_customer_id": { "type": "boolean", "description": "Whether 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). When true, buyers can include platform_customer_id values in AudienceMember.identifiers for matching against the seller's identity graph. Reporting on matched platform_customer_ids typically requires a clean room or the seller's own reporting surface." }, "supported_uid_types": { "type": "array", "description": "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.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/uid-type.json" }, "minItems": 1 }, "minimum_audience_size": { "type": "integer", "description": "Minimum matched audience size required for targeting. Audiences below this threshold will have status: too_small. Varies by platform (100–1000 is typical).", "minimum": 1 }, "matching_latency_hours": { "type": "object", "description": "Expected matching latency range in hours after upload. Use to calibrate polling cadence and set appropriate expectations before configuring push_notification_config.", "properties": { "min": { "type": "integer", "minimum": 0 }, "max": { "type": "integer", "minimum": 0 } }, "additionalProperties": false } }, "required": [ "supported_identifier_types", "minimum_audience_size" ], "additionalProperties": true }, "supported_optimization_metrics": { "type": "array", "description": "Optimization metrics this seller can support on at least one of their products. Seller-level rollup of product-level metric_optimization.supported_metrics declarations (core/product.json). Buyers SHOULD filter their requested optimization goals against this list before submitting briefs. Sellers MUST keep this in sync with their product catalog — if no products support a metric, it must not appear here. Omitting this field means the seller declares no specific guarantees about which metrics they support; buyers should fall back to per-product inspection of metric_optimization.supported_metrics.", "items": { "type": "string", "enum": [ "clicks", "views", "completed_views", "viewed_seconds", "attention_seconds", "attention_score", "engagements", "follows", "saves", "profile_visits", "reach" ] }, "minItems": 1, "uniqueItems": true }, "vendor_metric_optimization": { "type": "object", "description": "Seller-level rollup of vendor-metric optimization capabilities supported by at least one product. Product-level vendor_metric_optimization.supported_metrics[] remains authoritative for the specific (vendor, metric_id) pairs and target kinds a buyer may bind on a package; this seller-level object exists so buyers and compliance runners can discover whether vendor_metric goals are in scope before walking the catalog. Sellers MUST keep this in sync with product-level vendor_metric_optimization declarations.", "properties": { "supported_targets": { "type": "array", "description": "Target kinds this seller can support for vendor_metric optimization goals on at least one product. Values match optimization_goals[].target.kind for kind: vendor_metric. A target-less vendor_metric goal maximizes the metric within budget and does not require a target-kind declaration.", "items": { "type": "string", "enum": [ "cost_per", "threshold_rate" ] }, "minItems": 1, "uniqueItems": true } }, "additionalProperties": true }, "conversion_tracking": { "type": "object", "description": "Seller-level conversion tracking capabilities. Presence of this object indicates the seller supports sync_event_sources and log_event for conversion event tracking.", "properties": { "multi_source_event_dedup": { "type": "boolean", "description": "Whether this seller can deduplicate conversion events across multiple event sources within a single goal. When true, the seller honors the deduplication semantics in optimization_goals event_sources arrays — the same event_id from multiple sources counts once. When false or absent, buyers should use a single event source per goal; multi-source arrays will be treated as first-source-wins. Most social platforms cannot deduplicate across independently-managed pixel and CAPI sources." }, "per_creative_attribution": { "type": "boolean", "description": "Whether the seller can attribute conversions to specific creatives within a package and surface that breakdown via media_buy_deliveries[].by_package[].by_creative[].conversions in get_media_buy_delivery. Defaults to false when omitted. Sellers that report conversions only at the line / package / placement / campaign granularity (retail-media, MMP-mediated mobile, CTV performance) declare false (or omit) and the per-creative scenario grades not_applicable for them. Sellers that surface ad-level conversion attribution (most social platforms) declare true and the scenario asserts the breakdown is populated end-to-end. Defaults to false to preserve backward compatibility." }, "supported_event_types": { "type": "array", "description": "Event types this seller can track and attribute. If omitted, all standard event types are supported.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/event-type.json" }, "minItems": 1 }, "supported_targets": { "type": "array", "description": "Event-goal target kinds this seller can compute against. Buyers should only submit event-kind optimization goals whose target.kind is listed here — sellers MUST reject goals with unlisted target kinds. When omitted, only target-less event goals (maximize conversion count within budget) are guaranteed; sellers MAY accept specific target kinds but buyers should not rely on it. Named to parallel `metric_optimization.supported_targets` at the product level — same concept (which target kinds are supported), one at seller-capability granularity and one at product granularity.", "items": { "type": "string", "enum": [ "cost_per", "per_ad_spend", "maximize_value" ] }, "minItems": 1, "uniqueItems": true }, "supported_uid_types": { "type": "array", "description": "Universal ID types accepted for user matching", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/uid-type.json" }, "minItems": 1 }, "supported_hashed_identifiers": { "type": "array", "description": "Hashed PII types accepted for user matching. Buyers must hash before sending (SHA-256, normalized).", "items": { "type": "string", "enum": [ "hashed_email", "hashed_phone" ] }, "minItems": 1 }, "supported_action_sources": { "type": "array", "description": "Action sources this seller accepts events from", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/action-source.json" }, "minItems": 1 }, "attribution_windows": { "type": "array", "description": "Attribution windows available from this seller. Single-element arrays indicate fixed windows; multi-element arrays indicate configurable options the buyer can choose from via attribution_window on optimization goals.", "items": { "type": "object", "properties": { "event_type": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/event-type.json", "description": "Event type this window applies to, or omit for default window" }, "post_click": { "type": "array", "description": "Available post-click attribution windows (e.g. [{\"interval\": 7, \"unit\": \"days\"}])", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/duration.json" }, "minItems": 1 }, "post_view": { "type": "array", "description": "Available post-view attribution windows (e.g. [{\"interval\": 1, \"unit\": \"days\"}])", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/duration.json" }, "minItems": 1 } }, "required": [ "post_click" ], "additionalProperties": true } } }, "additionalProperties": true }, "frequency_capping": { "type": "object", "description": "Frequency capping capabilities. Presence of this object indicates the seller honors targeting.frequency_cap on packages and MUST reject caps it cannot enforce rather than silently dropping them. Buyers SHOULD inspect supported_per_units and supported_window_units before submitting caps; sellers without these sub-fields populated MAY accept any reach-unit / duration-unit combination they can enforce. Per-product overrides (for sellers with mixed addressable/non-addressable inventory) are a likely follow-up — file a separate RFC if needed.", "properties": { "supported_per_units": { "type": "array", "description": "Entity granularities the seller can enforce caps against. Values from the reach-unit enum. Omit to indicate all reach-unit values are supported.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/reach-unit.json" }, "minItems": 1, "uniqueItems": true }, "supported_window_units": { "type": "array", "description": "Duration units the seller supports for frequency cap windows. Values must match the duration.json unit enum (e.g., 'hours', 'days', 'campaign'). Omit to indicate all duration units are supported.", "items": { "type": "string" }, "minItems": 1, "uniqueItems": true } }, "additionalProperties": true }, "budget_capping": { "type": "object", "description": "Hard daily budget-cap capabilities. Presence declares only the scopes listed in supported_scopes; sellers MUST reject a daily_budget_cap at an undeclared scope with UNSUPPORTED_FEATURE before mutation and MUST NOT silently drop or soften it. A cap is always a hard ceiling. Sellers that offer a best-effort pacing target must expose that under a separately named feature rather than interpreting daily_budget_cap as soft. Daily caps are orthogonal to pacing.", "properties": { "supported_scopes": { "type": "array", "description": "Scopes where the seller enforces hard daily caps. media_buy bounds aggregate spend across all packages without allocating it. package bounds one package and remains subordinate to any aggregate cap.", "items": { "type": "string", "enum": [ "media_buy", "package" ] }, "minItems": 1, "uniqueItems": true }, "supported_periods": { "type": "array", "description": "Cap reset periods the seller enforces. AdCP 3.2 defines day only; the array form reserves room for future periods as an additive change.", "items": { "type": "string", "enum": [ "day" ] }, "minItems": 1, "uniqueItems": true }, "timezone_basis": { "type": "string", "enum": [ "account", "fixed" ], "description": "Source of the default cap-day boundary. account uses the selected Account.timezone and therefore supports different boundaries for different accounts. fixed uses fixed_timezone for every media buy regardless of account timezone." }, "fixed_timezone": { "type": "string", "minLength": 1, "description": "Feature-specific default cap-day timezone used when timezone_basis is fixed. Use UTC or an IANA timezone identifier." }, "buyer_timezone_override": { "type": "boolean", "description": "When true, buyers MAY override the default cap-day boundary via media-buy-level budget_cap_timezone. The accepted timezone applies to aggregate and package caps alike. When false or absent, a submitted override is rejected with UNSUPPORTED_FEATURE." } }, "required": [ "supported_scopes", "supported_periods", "timezone_basis" ], "allOf": [ { "if": { "properties": { "timezone_basis": { "const": "fixed" } }, "required": [ "timezone_basis" ] }, "then": { "required": [ "fixed_timezone" ] } }, { "if": { "properties": { "timezone_basis": { "const": "account" } }, "required": [ "timezone_basis" ] }, "then": { "not": { "required": [ "fixed_timezone" ] } } } ], "additionalProperties": true }, "content_standards": { "type": "object", "description": "Content standards implementation details. Presence of this object indicates the seller supports content_standards configuration including sampling rates and category filtering. Gives buyers pre-buy visibility into local evaluation and artifact delivery capabilities. This is a seller-side media-buy capability; governance agents providing content standards services declare `specialisms: [\"content-standards\"]` instead.", "properties": { "supports_local_evaluation": { "type": "boolean", "description": "Whether the seller runs a local evaluation model. When false, all artifacts will have local_verdict: 'unevaluated' and the failures_only filter on get_media_buy_artifacts is not useful." }, "supported_channels": { "type": "array", "description": "Channels for which the seller can provide content artifacts. Helps buyers understand which parts of a mixed-channel buy will have content standards coverage.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/channels.json" }, "minItems": 1 }, "supports_webhook_delivery": { "type": "boolean", "description": "Whether the seller supports push-based artifact delivery via artifact_webhook configured at buy creation time." } } }, "portfolio": { "type": "object", "description": "Information about the seller's media inventory portfolio. Media-buy sellers SHOULD publish primary_channels and primary_countries as their complete brief-routing scope. Buyers use publisher_domains to verify authorization via adagents.json. Omitted routing arrays mean unknown scope and MUST NOT be interpreted as global coverage.", "properties": { "publisher_domains": { "type": "array", "description": "Publisher domains this seller is authorized to represent. Buyers should fetch each publisher's adagents.json for property definitions.", "items": { "type": "string", "pattern": "^[a-z0-9]([a-z0-9-]*[a-z0-9])?(\\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)*$" }, "minItems": 1 }, "primary_channels": { "type": "array", "description": "Complete list of AdCP media channels for which this sales agent accepts and can meaningfully answer product-discovery briefs. When present, this is an exhaustive brief-routing allowlist: buyers MAY skip the agent when a brief's requested channels do not intersect it. Omission means channel scope is unknown and MUST NOT be interpreted as support for every channel. This is a routing pre-filter, not a promise of current product availability.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/channels.json" } }, "primary_countries": { "type": "array", "description": "Complete list of ISO 3166-1 alpha-2 countries for which this sales agent accepts and can meaningfully answer product-discovery briefs. When present, this is an exhaustive brief-routing allowlist: buyers MAY skip the agent when a brief's requested countries do not intersect it. Omission means country scope is unknown and MUST NOT be interpreted as global coverage. This is a routing pre-filter, not a promise of current product availability and not an executable geo-targeting declaration; media_buy.execution.targeting geo capabilities and each product's overlay_support remain authoritative for targeting execution.", "items": { "type": "string", "pattern": "^[A-Z]{2}$" } }, "description": { "type": "string", "description": "Markdown-formatted description of the inventory portfolio", "maxLength": 5000 }, "advertising_policies": { "type": "string", "description": "Advertising content policies, restrictions, and guidelines", "maxLength": 10000 } }, "required": [ "publisher_domains" ] } }, "allOf": [ { "if": { "required": [ "proposal_refinement" ] }, "then": { "properties": { "lifecycle_tools": { "contains": { "const": "refine_proposals" } } }, "required": [ "lifecycle_tools" ] } }, { "if": { "properties": { "relationship_notifications": { "properties": { "event_types": { "contains": { "const": "indicators.changed" } } }, "required": [ "event_types" ] } }, "required": [ "relationship_notifications" ] }, "then": { "required": [ "supported_indicator_types" ] } } ] }, "signals": { "type": "object", "description": "Signals protocol capabilities. Only present if signals is in supported_protocols.", "properties": { "data_provider_domains": { "type": "array", "description": "Data provider domains this signals agent is authorized to resell. Buyers should fetch each data provider's adagents.json for published signal definitions and to verify authorization.", "items": { "type": "string", "pattern": "^[a-z0-9]([a-z0-9-]*[a-z0-9])?(\\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)*$" }, "minItems": 1 }, "discovery_modes": { "type": "array", "description": "Discovery modes this signals agent supports on get_signals. 'brief' (default — every signals agent supports this): semantic discovery driven by signal_spec or signal_refs, with deprecated signal_ids accepted for older clients. 'wholesale': raw wholesale signals feed enumeration — caller omits signal_spec, signal_refs, and signal_ids and the agent returns its full priced signals feed, paginated, scoped by filters/account/destinations/countries. Agents that do not declare 'wholesale' MAY return INVALID_REQUEST for wholesale calls. Absent declaration is treated as ['brief'].", "items": { "type": "string", "enum": [ "brief", "wholesale" ] }, "minItems": 1, "uniqueItems": true, "default": [ "brief" ] }, "features": { "type": "object", "description": "Optional signals features supported", "properties": { "catalog_signals": { "type": "boolean", "description": "DEPRECATED. Legacy wire flag for structured signal_ref references to provider-published signal definitions. New agents SHOULD omit this flag; callers MUST NOT require it before using signal_ref with the Signals protocol.", "deprecated": true } }, "additionalProperties": { "type": "boolean" } } } }, "governance": { "type": "object", "description": "Governance protocol capabilities. Only present if governance is in supported_protocols. Governance agents provide property and creative data like compliance scores, brand safety ratings, sustainability metrics, and creative quality assessments.", "properties": { "runtime_attestations": { "type": "object", "description": "Signal-activation policy for the portable attestation support declared in adcp.attestations. Presence means check_governance accepts runtime_attestations[] for purchase_type signal_activation. The claim_types list MUST be a subset of adcp.attestations.accepted_claim_types; issuer, resolver, verifier, proof-format, and delivery allowlists remain authoritative in the shared adcp.attestations block rather than being duplicated here.", "properties": { "signal_activation": { "type": "object", "properties": { "requirement": { "type": "string", "enum": [ "optional", "required" ], "description": "Whether an activate_signal activation check may omit runtime_attestations. When required, missing evidence fails an activation check. Deactivation and privacy-removal checks never require signal-quality evidence and remain available without it." }, "claim_types": { "type": "array", "description": "Signal-quality claim identifiers accepted for this governed action. Values are open absolute URIs and MUST be a subset of adcp.attestations.accepted_claim_types.", "items": { "type": "string", "format": "uri" }, "minItems": 1, "uniqueItems": true } }, "required": [ "requirement", "claim_types" ], "additionalProperties": false } }, "required": [ "signal_activation" ], "additionalProperties": false }, "aggregation_window_days": { "type": "integer", "minimum": 1, "maximum": 365, "description": "Trailing window (in days) over which this governance agent aggregates committed spend when evaluating dollar-valued thresholds (reallocation_threshold, human_review triggers, registry-policy floors). Required for fragmentation defense: without aggregation, a buyer can split a single large spend into many sub-threshold commits across plans / task surfaces / time and bypass every dollar-gated escalation. Aggregation is keyed on (buyer_agent, seller_agent, account_id) and spans all spend-commit task types. Upper bound 365 represents a one-year trailing window (fiscal-year alignment with grace); governance agents needing longer scopes negotiate via operator sign-off, not this capability. No schema default: absence of this field indicates the governance agent has not committed to any aggregation window and buyers MUST assume per-commit evaluation only (the fragmentation attack surface is open). A declared value of 30 is a common starting point but is not implied by omission. Buyers depending on a specific window for compliance MUST check this capability before relying on aggregation semantics — an agent declaring 7 days does not defend against fragmentation spread across a 30-day quarter-end push." }, "property_features": { "type": "array", "description": "Property features this governance agent can evaluate. Each feature describes a score, rating, or certification the agent can provide for properties.", "items": { "type": "object", "properties": { "feature_id": { "type": "string", "description": "Unique identifier for this feature (e.g., 'consent_quality', 'coppa_certified', 'carbon_score')" }, "type": { "type": "string", "enum": [ "binary", "quantitative", "categorical" ], "description": "Data type: 'binary' for yes/no, 'quantitative' for numeric scores, 'categorical' for enum values" }, "range": { "type": "object", "description": "For quantitative features, the valid range", "properties": { "min": { "type": "number", "description": "Minimum value" }, "max": { "type": "number", "description": "Maximum value" } }, "required": [ "min", "max" ] }, "categories": { "type": "array", "description": "For categorical features, the valid values", "items": { "type": "string" } }, "description": { "type": "string", "description": "Human-readable description of what this feature measures" }, "methodology_url": { "type": "string", "format": "uri", "description": "URL to documentation explaining how this feature is calculated or measured. Helps buyers understand and compare methodologies across vendors." } }, "required": [ "feature_id", "type" ] } }, "creative_features": { "type": "array", "description": "Creative features this governance agent can evaluate. Each feature describes a score, rating, or assessment the agent can provide for creatives (e.g., security scanning, creative quality, content categorization).", "items": { "type": "object", "properties": { "feature_id": { "type": "string", "description": "Unique identifier for this feature (e.g., 'auto_redirect', 'brand_consistency', 'iab_casinos_gambling')" }, "type": { "type": "string", "enum": [ "binary", "quantitative", "categorical" ], "description": "Data type: 'binary' for yes/no, 'quantitative' for numeric scores, 'categorical' for enum values" }, "range": { "type": "object", "description": "For quantitative features, the valid range", "properties": { "min": { "type": "number", "description": "Minimum value" }, "max": { "type": "number", "description": "Maximum value" } }, "required": [ "min", "max" ] }, "categories": { "type": "array", "description": "For categorical features, the valid values", "items": { "type": "string" } }, "description": { "type": "string", "description": "Human-readable description of what this feature measures" }, "methodology_url": { "type": "string", "format": "uri", "description": "URL to documentation explaining how this feature is calculated or measured." } }, "required": [ "feature_id", "type" ] } } } }, "sponsored_intelligence": { "type": "object", "description": "Sponsored Intelligence protocol capabilities. Only present if sponsored_intelligence is in supported_protocols. SI agents handle conversational brand experiences.", "x-status": "experimental", "properties": { "endpoint": { "type": "object", "description": "SI agent endpoint configuration", "properties": { "transports": { "type": "array", "description": "Available protocol transports. Hosts select based on their capabilities.", "items": { "type": "object", "properties": { "type": { "type": "string", "enum": [ "mcp", "a2a" ], "description": "Protocol transport type" }, "url": { "type": "string", "format": "uri", "description": "Agent endpoint URL for this transport" } }, "required": [ "type", "url" ], "additionalProperties": true }, "minItems": 1 }, "preferred": { "type": "string", "enum": [ "mcp", "a2a" ], "description": "Preferred transport when host supports multiple" } }, "required": [ "transports" ] }, "capabilities": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/sponsored-intelligence/si-capabilities.json", "description": "Modalities, components, and commerce capabilities" }, "brand_url": { "type": "string", "format": "uri", "description": "URL to brand.json with colors, fonts, logos, tone" } }, "required": [ "endpoint", "capabilities" ] }, "brand": { "type": "object", "description": "Brand protocol capabilities. Only present if brand is in supported_protocols. Brand agents provide identity data (logos, colors, tone, assets) and optionally rights clearance for licensable content (talent, music, stock media).", "properties": { "rights": { "type": "boolean", "description": "Supports get_rights and acquire_rights for rights discovery and clearance", "x-status": "experimental", "default": false }, "right_types": { "type": "array", "description": "Types of rights available through this agent", "x-status": "experimental", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/right-type.json" } }, "available_uses": { "type": "array", "description": "Rights uses available across this agent's roster", "x-status": "experimental", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/right-use.json" } }, "generation_providers": { "type": "array", "description": "LLM/generation providers this agent can issue credentials for", "x-status": "experimental", "items": { "type": "string" } }, "description": { "type": "string", "description": "Description of the agent's brand protocol capabilities", "maxLength": 5000 } }, "additionalProperties": true }, "creative": { "type": "object", "description": "Creative protocol capabilities. Only present if creative is in supported_protocols.", "properties": { "supports_compliance": { "type": "boolean", "description": "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." }, "has_creative_library": { "type": "boolean", "description": "When true, this agent hosts a creative library and supports list_creatives and creative_id references in build_creative. Creative agents with a library should also implement the accounts protocol (sync_accounts / list_accounts) so buyers can establish access.", "default": false }, "supports_generation": { "type": "boolean", "description": "When true, this agent can generate creatives from natural language briefs via build_creative. The buyer provides a message with creative direction, and the agent produces a manifest with generated assets. When false, build_creative only supports transformation or library retrieval.", "default": false }, "supports_transformation": { "type": "boolean", "description": "When true, this agent can transform or resize existing canonical manifests via build_creative. The buyer supplies a creative_manifest and an advertised target_capability_id.", "default": false }, "supports_transformers": { "type": "boolean", "description": "When true, this agent exposes account-scoped creative transformers via list_transformers (the creative analog of media-buy products) and accepts transformer_id + config on build_creative. Buyers SHOULD call list_transformers to discover available transformers, their typed config params (and account-scoped enumerable option values via expand_params), and pricing. When false or absent, the agent does not offer the transformer surface.", "default": false }, "supports_refinement": { "type": "boolean", "description": "When true, this agent retains produced build_variant leaves for an agent-defined retention window and can re-build from one via build_creative's refine_from_build_variant_id — applying a natural-language instruction in message plus an optional config delta, returning new lineage-linked variants. A build-time agent capability independent of generation/transformation. When false or absent, refine_from_build_variant_id is rejected with UNSUPPORTED_FEATURE; buyers refine instead via the transform path (creative_manifest + message).", "default": false }, "supports_spend_controls": { "type": "boolean", "default": false, "description": "When true, build_creative honors a per-call `max_spend` ceiling (producing partial paid results and returning budget_status:\"capped\" + a BUDGET_CAP_REACHED advisory rather than overspending) AND supports mode:\"estimate\" dry-runs (a projected cost band, producing/billing nothing). When false or absent, max_spend / mode:estimate are rejected with UNSUPPORTED_FEATURE. Out-of-band billers (bills_through_adcp:false) have no AdCP cost truth to cap against, so this is meaningful only alongside bills_through_adcp:true." }, "supports_evaluator": { "type": "boolean", "default": false, "x-status": "experimental", "description": "Experimental (x-status: experimental) — agents setting this true MUST also list `creative.evaluator` in `experimental_features`; the surface MAY change between 3.x releases with notice (see docs/reference/experimental-status). When true, build_creative accepts an advisory `evaluator` input (exemplars / account-arranged evaluator_id / agent_url, plus an optional `feature_requirement[]` gate, a `rank_by` ordering, and an allowlisted `feature_agent` pointer). Feature discovery uses this response's governance.creative_features catalog: rank_by, feature_requirement, and eval.features[] all share the same creative-feature vocabulary as get_creative_features. evaluator_id is not discovered from this catalog; it is a pre-provisioned account preset whose emitted feature_ids still come from it. The evaluator populates a per-leaf `eval` block of creative-feature values (creative-feature-result[], the same shape get_creative_features returns) on BuildCreativeVariantSuccess leaves, which is what the recommended/rank it sets on the best_of_n axis are computed over. The agent runs a gate-then-rank pipeline over its best_of_n exploration: it evaluates each leaf, DROPS leaves failing `feature_requirement[]` from its recommended survivors, then orders survivors by `rank_by`. The gate is internal pruning of which leaves the agent recommends/returns from its own exploration — it never blocks an already-produced billable leaf: what is produced and billed is governed by max_variants/max_creatives/max_spend, not the evaluator. When the evaluator names an external agent, it MUST appear in `creative_policy.accepted_verifiers[]` (off-list → EVALUATOR_AGENT_NOT_ACCEPTED), and the producing agent authenticates the outbound evaluator call on the transport. Evaluator credentials and caller-supplied trust material MUST NOT be passed in the build_creative payload; credential- or trust-material payload keys should be rejected with CREDENTIAL_IN_ARGS. When false or absent, the `evaluator` input is ignored and no `eval` block is emitted." }, "refinable_retention_seconds": { "type": "integer", "minimum": 0, "description": "When supports_refinement is true, the GUARANTEED-MINIMUM window (a floor, not a ceiling) during which a produced build_variant_id remains refinable via refine_from_build_variant_id: a ref within this window from production SHOULD resolve; the agent MAY retain longer. Omit when the retention window is agent-defined and not advertised — buyers then treat refinability as best-effort and handle REFERENCE_NOT_FOUND." }, "multiplicity": { "type": "object", "description": "Pre-call discriminators for build_creative fan-out, so a buyer knows BEFORE sending max_creatives / max_variants whether this agent supports them and the ceilings. Over-limit requests are CLAMPED to these ceilings (the agent produces up to the limit and signals the shortfall via items_returned < items_total on BuildCreativeVariantSuccess), not rejected — consistent with item_limit's 'use the lesser' rule. Absent means no fan-out: build_creative produces a single creative and max_creatives/max_variants>1 are not supported.", "properties": { "supports_catalog_fanout": { "type": "boolean", "default": false, "description": "When true, build_creative accepts max_creatives (one distinct creative per catalog item)." }, "max_creatives_limit": { "type": "integer", "minimum": 1, "description": "Ceiling on max_creatives. Omitted means no advertised ceiling." }, "supports_signal_fanout": { "type": "boolean", "default": false, "x-status": "experimental", "description": "Experimental (x-status: experimental) — agents setting this true MUST also list `creative.signal_fanout` in `experimental_features`; the surface MAY change between 3.x releases with notice (see docs/reference/experimental-status). When true, build_creative accepts signal_conditions[] (one distinct creative group per signal condition, keep-all). Mirrors supports_catalog_fanout." }, "max_signal_conditions_limit": { "type": "integer", "minimum": 1, "x-status": "experimental", "description": "Ceiling on len(signal_conditions). Over-limit requests are CLAMPED (not rejected), like max_creatives_limit. Omitted means no advertised ceiling." }, "supports_variants": { "type": "boolean", "default": false, "description": "When true, build_creative accepts max_variants > 1 / variant_axis (alternatives per creative)." }, "max_variants_limit": { "type": "integer", "minimum": 1, "description": "Ceiling on max_variants. Omitted means no advertised ceiling." }, "variant_dimensions": { "type": "array", "description": "Which variant_axis.dimension values this agent supports.", "items": { "type": "string", "enum": [ "voice", "theme", "best_of_n", "transformer_config", "custom" ] }, "uniqueItems": true }, "selection_strategies": { "type": "array", "x-status": "experimental", "description": "Which selection_strategy values this agent supports when sampling max_creatives < items_total. Sibling to variant_dimensions. Part of the experimental signal-fanout surface (feature id `creative.signal_fanout`).", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/creative-selection-strategy.json" }, "uniqueItems": true } }, "additionalProperties": true }, "supported_formats": { "type": "array", "description": "Canonical-format capability catalog for this creative agent. This is the 3.2 source of truth for discovering which format contracts the agent can build, validate, or preview; it replaces the deprecated `list_creative_formats` task. Each entry uses the same `ProductFormatDeclaration` shape as a product's inline `format_options[i]`. New 3.2 producers MUST publish a stable agent-local `capability_id` and explicit `operations` for task routing. Every emitted `capability_id` MUST be unique within this catalog so a route selects exactly one entry. During the 3.x compatibility window, consumers MUST also accept legacy entries that omit either field; absent `operations` means `[\"build\"]`, while an absent `capability_id` means the entry is discoverable by canonical contract but cannot be selected through a capability-ID route.\n\n**Publisher-specific support.** To claim exact support for a publisher declaration, `format` carries the declaration's `{publisher_domain, format_option_id}` pair plus its canonical `format_kind` and narrowed `params`. Generic creative agents MAY instead advertise a canonical parameter envelope without publisher identity. A generic capability matches a target declaration only when the capability can satisfy every target constraint; matching canonical names alone is insufficient. Registries MAY reverse-index these entries by `format.format_kind`, `format.publisher_domain`, and `format.format_option_id`.\n\nThis catalog describes creative operations, not sales-agent inventory deliverability. Sales agents publish the purchasable closed set on each `Product.format_options[]`; publisher acceptance lives in `adagents.json.formats[]`.", "items": { "type": "object", "properties": { "capability_id": { "type": "string", "pattern": "^[a-zA-Z0-9_-]+$", "description": "Stable identifier for this format capability within the creative agent (e.g., 'audio_narration_30s'). The value MUST be unique across this agent's supported_formats catalog. Route the advertised operation with this ID: build_creative.target_capability_id(s) for build, preview_creative.target_capability_id for preview, or validate_input targets[] kind capability for validate. Capability IDs are agent-local routes and do not appear on portable manifests or products." }, "format": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/product-format-declaration.json", "description": "Format declaration on which this agent can perform the listed operations. Same shape as a product's inline format_options entry: format_kind plus params and slots." }, "operations": { "type": "array", "description": "Creative operations this capability supports. `build` means the agent can produce a conforming manifest via build_creative; `validate` means it can evaluate inputs against the declaration; `preview` means it can render a preview. New 3.2 producers MUST emit this field so buyers and registries can distinguish producers, validators, and renderers without probing tasks. Consumers interpret omission from a legacy 3.x entry as `[\"build\"]`.", "items": { "type": "string", "enum": [ "build", "validate", "preview" ] }, "minItems": 1, "uniqueItems": true, "default": [ "build" ] } }, "required": [ "format" ], "additionalProperties": true } }, "localization": { "type": "object", "description": "Materialized creative-localization support for sync_creatives/list_creatives, including source-only monolingual topology. Presence opts the agent into exact locale-variant round-trip, strict RFC 4647 Lookup, optional buyer-declared language-family fallback rules, explicit final default/unmatched behavior, creative-wide review, transactional replacement, seller product-format locale-policy enforcement, and delivery attribution. This is a coarse structural capability, not a promise that every locale/format/account combination is accepted; sellers publish accepted ranges on product format declarations and validate each write before mutation. Omit this object when localization is unsupported.", "properties": { "max_target_variants": { "type": "integer", "minimum": 0, "maximum": 50, "description": "Maximum target locale variants accepted on one creative. Zero advertises source-only monolingual locale topology. Omit to inherit the protocol ceiling of 50." }, "locale_matching": { "type": "string", "const": "rfc4647_lookup", "description": "The required deterministic locale-matching algorithm." } }, "required": [ "locale_matching" ], "not": { "anyOf": [ { "required": [ "supported_locales" ] }, { "required": [ "translation_modes" ] }, { "required": [ "review_scope" ] } ] }, "additionalProperties": true }, "bills_through_adcp": { "type": "boolean", "description": "When true, this creative agent bills through the AdCP rate-card surface: list_creatives returns pricing_options when include_pricing=true with an authenticated account, build_creative populates pricing_option_id and vendor_cost on the response, and report_usage accepts records against the rate card. When false or absent, the agent bills out of band (flat license, SaaS contract, bundled enterprise agreement) and buyers should skip pricing fields and tolerate report_usage returning accepted: 0 with errors carrying BILLING_OUT_OF_BAND. A pre-call discriminator so buyer agents can route across many creative agents without first establishing an account to probe pricing.", "default": false }, "canonical_catalog_version": { "type": "string", "pattern": "^\\d+\\.\\d+(\\.\\d+)?$", "description": "Optional. The AdCP canonical-formats catalog version this agent's runtime is built against (e.g., `3.1`, `3.2.0`). Lets buyer SDKs detect canonical-catalog skew between their generated types and the seller's actual support. SDKs MAY declare the version they were generated against (typically the AdCP version they ship for); when seller and SDK versions disagree, SDKs SHOULD soft-warn rather than fail (the open-enum semantics on `canonical-format-kind.json` make unknown canonicals safe to retain, so skew is not a hard error — it just means the older side might not understand newer canonical values). Omitted by sellers who haven't yet generated against a versioned catalog; absence is interpreted as the AdCP version advertised by the broader capabilities response." } }, "additionalProperties": true, "allOf": [ { "if": { "required": [ "localization" ] }, "then": { "properties": { "has_creative_library": { "type": "boolean", "const": true } }, "required": [ "has_creative_library" ] } } ] }, "oauth": { "type": "object", "description": "Introduced in AdCP 3.2. OAuth 2.0 protected-resource support for inbound transport authentication. This is a capability claim, not a requirement that every caller use OAuth: `supported: true` means the agent publishes RFC 9728 protected-resource metadata for its advertised endpoint and RFC 8414 metadata for every referenced authorization server, and opts into the universal `oauth_setup` conformance storyboard. Agents that use only static Bearer, Basic, mTLS, or RFC 9421 authentication omit this block or declare `supported: false`. Operator credential acquisition remains separately described by `account.authorization_endpoint` when applicable.", "properties": { "supported": { "type": "boolean", "description": "Whether this agent accepts OAuth access tokens and publishes the discovery metadata needed to obtain and validate them. A true value is an explicit conformance claim: the RFC 9728 protected-resource document and every RFC 8414 authorization-server document it references MUST be reachable, internally consistent, and safe for clients to follow. False or absent means the OAuth metadata storyboard is not applicable; it does not weaken the universal requirement to implement at least one authentication mechanism." } }, "required": [ "supported" ], "additionalProperties": true }, "request_signing": { "type": "object", "description": "RFC 9421 HTTP Signatures support for incoming requests. Signing remains optional through 3.2, but every accepted 3.2 signature on a request with a body MUST cover content-digest. Request signing becomes required for spend-committing operations in 4.0. The full profile is defined in docs/building/by-layer/L1/security.mdx (Signed Requests (Transport Layer)).", "properties": { "supported": { "type": "boolean", "description": "Whether this agent verifies RFC 9421 signatures on incoming requests. When true, signatures present on requests are validated per the AdCP request-signing profile. When false or absent, signatures are ignored (requests are bearer-authenticated only)." }, "covers_content_digest": { "type": "string", "enum": [ "required", "forbidden", "either" ], "description": "Policy for content-digest coverage in request signatures. In AdCP 3.2 and later, an agent with request_signing.supported=true MUST explicitly emit 'required': every accepted signature on a request with a body covers content-digest, and a body-unbound signature is rejected with request_signature_components_incomplete. Omission retains the legacy effective default of 'either' only for a 3.0/3.1 response; 3.2 responses require this field explicitly. 'either' and 'forbidden' are deprecated legacy 3.0/3.1 postures retained only for version negotiation with pre-3.2 peers; they MUST NOT be advertised as a 3.2 signing posture and are removed in 4.0. A shared endpoint MUST select the verifier policy from trusted endpoint configuration and negotiated capabilities before dispatch, never from an unbound request-body version field." }, "required_for": { "type": "array", "description": "AdCP protocol operation names (e.g., 'create_media_buy') for which this agent rejects an unsigned request with request_signature_required unless an independently valid configured fallback authenticator succeeds. Not MCP tool names, A2A skill names, or any transport-specific rename — verifiers MUST NOT accept operation names that are not defined by the AdCP protocol spec. JSON-RPC protocol method names like `tasks/cancel` belong in `protocol_methods_required_for`, not here. Empty in 3.0 by default; sellers populate selectively during per-counterparty pilots. In 4.0 this list MUST include all spend-committing operations the agent supports (create_media_buy, acquire_*, etc.). Every operation listed MUST also appear in `supported_for`; see `x-adcp-validation`.", "items": { "type": "string" }, "default": [], "x-adcp-validation": { "subset_of": "request_signing.supported_for", "spec": "docs/building/implementation/security.mdx#signed-requests-transport-layer" } }, "warn_for": { "type": "array", "description": "AdCP protocol operation names for shadow-mode verification. The verifier records missing signatures and well-formed signatures that fail verification or body binding, but MUST NOT establish verified-signer identity from a failed signature; processing continues only when an independent bearer, API-key, or mTLS authenticator succeeds. A partial or malformed Signature / Signature-Input pair always hard-rejects. Used as a bridge between supported_for and required_for. Precedence: required_for > warn_for > supported_for. An operation MUST NOT appear in both warn_for and required_for; see x-adcp-validation.", "items": { "type": "string" }, "default": [], "x-adcp-validation": { "disjoint_with": "request_signing.required_for", "subset_of": "request_signing.supported_for", "spec": "docs/building/implementation/security.mdx#signed-requests-transport-layer" } }, "supported_for": { "type": "array", "description": "AdCP protocol operation names for which this agent verifies signatures when present but does not require them. Under the 3.2 profile, a presented signature on a body-bearing request without content-digest coverage rejects even though an unsigned request may use configured fallback authentication. Typically a superset of required_for and warn_for.", "items": { "type": "string" } }, "protocol_methods_supported_for": { "type": "array", "description": "JSON-RPC protocol method names (e.g., 'tasks/cancel', 'tasks/get') for which this agent verifies signatures when present. Under the 3.2 profile, a presented signature on a body-bearing request without content-digest coverage rejects. Disjoint from supported_for, which carries AdCP tool names only. Items MUST be wire-format JSON-RPC method strings containing `/`; plain AdCP tool names belong in supported_for.", "items": { "type": "string", "pattern": "^[a-z][a-z0-9_]*/[a-z][a-z0-9_]*$" }, "default": [], "x-adcp-validation": { "spec": "docs/building/by-layer/L1/security.mdx#signed-requests-transport-layer" } }, "protocol_methods_warn_for": { "type": "array", "description": "Protocol method names for shadow-mode verification, mirroring warn_for in the AdCP-tool namespace. Missing signatures and well-formed signatures that fail verification or body binding are recorded but MUST NOT establish verified-signer identity; processing continues only when an independent authenticator succeeds. A partial or malformed Signature / Signature-Input pair always hard-rejects. An item MUST NOT appear in both protocol_methods_warn_for and protocol_methods_required_for; see x-adcp-validation.", "items": { "type": "string", "pattern": "^[a-z][a-z0-9_]*/[a-z][a-z0-9_]*$" }, "default": [], "x-adcp-validation": { "disjoint_with": "request_signing.protocol_methods_required_for", "subset_of": "request_signing.protocol_methods_supported_for", "spec": "docs/building/by-layer/L1/security.mdx#signed-requests-transport-layer" } }, "protocol_methods_required_for": { "type": "array", "description": "JSON-RPC protocol method names for which this agent rejects an unsigned request with request_signature_required unless an independently valid configured fallback authenticator succeeds. Separate namespace from required_for: this bucket binds against the JSON-RPC method field, not tools/call params.name. Every listed method MUST also appear in protocol_methods_supported_for; see x-adcp-validation.", "items": { "type": "string", "pattern": "^[a-z][a-z0-9_]*/[a-z][a-z0-9_]*$" }, "default": [], "x-adcp-validation": { "subset_of": "request_signing.protocol_methods_supported_for", "spec": "docs/building/by-layer/L1/security.mdx#signed-requests-transport-layer" } } }, "required": [ "supported" ] }, "webhook_signing": { "type": "object", "description": "RFC 9421 webhook-signature support for outbound webhook callbacks (top-level peer of request_signing). Declares which AdCP webhook-signing profile version and algorithms this agent produces on delivery, and whether it supports the legacy HMAC-SHA256 fallback for receivers that have not yet adopted RFC 9421. See docs/building/implementation/webhooks.mdx.", "properties": { "supported": { "type": "boolean", "description": "Whether this agent signs outbound webhooks with the AdCP RFC 9421 webhook profile. When false or absent, webhooks are delivered with legacy Bearer or HMAC-SHA256 auth only and receivers MUST NOT expect a Signature header. When the seller advertises mutating-webhook emission (i.e., `media_buy.reporting_delivery_methods` includes `webhook`, `media_buy.content_standards.supports_webhook_delivery` is true, `media_buy.relationship_notifications.supported` is true, `wholesale_feed_webhooks.supported` is true, `adcp.capability_changes.notifications.supported` is true, or `account.notifications.supported` is true), this MUST be `true` — emitting state-changing webhooks unsigned is a downgrade vector that lets an on-path attacker forge delivery callbacks. See `x-adcp-validation`.", "x-adcp-validation": { "verifier_constraints": { "must_equal_when": { "value": true, "any_of": [ { "field": "media_buy.reporting_delivery_methods", "contains_item": "webhook" }, { "field": "media_buy.content_standards.supports_webhook_delivery", "equals": true }, { "field": "wholesale_feed_webhooks.supported", "equals": true }, { "field": "adcp.capability_changes.notifications.supported", "equals": true }, { "field": "account.notifications.supported", "equals": true }, { "field": "media_buy.relationship_notifications.supported", "equals": true } ] } }, "spec": "docs/building/implementation/webhooks.mdx" } }, "profile": { "type": "string", "enum": [ "adcp/webhook-signing/v1" ], "description": "Identifier of the webhook-signing profile version the agent emits. Value MUST match the `tag=` parameter emitted in the RFC 9421 `Signature-Input` header (see docs/building/implementation/webhooks.mdx) so receivers can statically validate the declared profile against the on-wire tag. Closed enum; future profile revisions will extend this enum in a follow-up schema bump." }, "algorithms": { "type": "array", "description": "Signature algorithms this agent uses on outbound webhooks. 3.0 profile permits 'ed25519' and 'ecdsa-p256-sha256' only; other values are reserved for future profile versions and MUST NOT be emitted under adcp/webhook-signing/v1.", "items": { "type": "string", "enum": [ "ed25519", "ecdsa-p256-sha256" ] }, "minItems": 1, "uniqueItems": true }, "legacy_hmac_fallback": { "type": "boolean", "deprecated": true, "description": "Whether this agent will fall back to HMAC-SHA256 on the legacy push_notification_config.authentication, accounts[].notification_configs[].authentication, or sync_agent_notification_configs.notification_configs[].authentication paths for receivers that have not adopted RFC 9421. Deprecated; removed in AdCP 4.0.", "default": false } }, "required": [ "supported" ] }, "identity": { "type": "object", "description": "Operator identity posture — trust-root pointer (`brand_json_url`) plus key-scoping and compromise-response controls the agent operates. `brand_json_url` is **load-bearing** for signature verification: when the agent declares any signing posture (`request_signing.supported_for`/`required_for` non-empty, `webhook_signing.supported === true`, or any `key_origins` subfield), `brand_json_url` MUST be present (storyboard-enforced in 3.x; schema-required in 4.0). Verifiers use it to bootstrap from the agent URL to the operator's brand.json (and from there to signing keys); see [security.mdx §Discovering an agent's signing keys](https://adcontextprotocol.org/docs/building/by-layer/L1/security#discovering-an-agents-signing-keys-via-brand_json_url). The remaining fields (`per_principal_key_isolation`, `key_origins`, `compromise_notification`) are advisory and receivers use them to reason about blast radius and revocation latency at onboarding. Empty-object semantics: `identity: {}` means \"posture block present but no posture claimed\" — schema-valid but advisory-neutral and receivers MUST treat it as equivalent to omitting the block, **except** that an agent declaring a signing posture elsewhere in the response with an empty `identity` MUST be rejected by storyboard runners as missing `brand_json_url`.", "properties": { "brand_json_url": { "type": "string", "format": "uri", "pattern": "^https://", "description": "HTTPS URL of the operator's brand.json (typically `https://{operator-domain}/.well-known/brand.json`). Trust-root pointer for this agent's signing keys. See [security.mdx §Discovering an agent's signing keys via `brand_json_url`](https://adcontextprotocol.org/docs/building/by-layer/L1/security#discovering-an-agents-signing-keys-via-brand_json_url) for the verifier algorithm and `x-adcp-validation` for structured constraints. Distinct from `sponsored_intelligence.brand_url`, which is a rendering pointer for SI agent visuals — verifiers MUST use this field for key discovery and MUST NOT fall back to `sponsored_intelligence.brand_url` as a trust-root pointer.", "x-adcp-validation": { "trust_root": true, "required_when": { "any_of": [ { "field": "request_signing.supported_for", "non_empty": true }, { "field": "request_signing.required_for", "non_empty": true }, { "field": "request_signing.protocol_methods_supported_for", "non_empty": true }, { "field": "request_signing.protocol_methods_required_for", "non_empty": true }, { "field": "webhook_signing.supported", "equals": true }, { "field": "identity.key_origins", "any_subfield_present": true } ] }, "schema_required_when": { "field": "adcp.supported_versions", "any_item_matches_pattern": "^4\\." }, "verifier_constraints": { "agent_url_match": "byte_equal", "origin_binding": "etld1_or_authorized_operators", "key_origins_consistency": "mandatory_when_signing" }, "distinct_from": "sponsored_intelligence.brand_url", "spec": "docs/building/implementation/security.mdx#discovering-an-agents-signing-keys-via-brand_json_url" } }, "per_principal_key_isolation": { "type": "boolean", "description": "When true, this multi-principal operator scopes signing keys per-principal so a single principal's key compromise does not silently re-scope across principals served by the same operator. `kid` values remain opaque to verifiers per RFC 7517; any operator-side naming convention (e.g., `{operator}:{principal}:{key_version}`) is internal bookkeeping and MUST NOT be parsed by verifiers. See docs/building/understanding/security-model.mdx.", "default": false }, "key_origins": { "type": "object", "description": "Map of signing-key surface/purpose → publishing origin, so counterparties can verify origin separation (e.g., governance keys served from a separate origin than transport/webhook keys) at onboarding. Absent means the operator has not declared a separation scheme; receivers SHOULD assume shared-origin. Every entry listed MUST have a corresponding signing posture declared elsewhere — `request_signing` requires non-empty `request_signing.supported_for`/`required_for`/`protocol_methods_supported_for`/`protocol_methods_required_for`; `webhook_signing` requires `webhook_signing.supported === true` and names the webhook delivery surface, not a required live `adcp_use: \"webhook-signing\"` key purpose — otherwise the consistency check at signature-verification time has nothing to anchor against. See `x-adcp-validation` and docs/building/implementation/security.mdx §Origin separation.", "properties": { "governance_signing": { "type": "string", "format": "uri", "description": "Origin (scheme + host) serving the governance-signing JWKS." }, "request_signing": { "type": "string", "format": "uri", "description": "Origin (scheme + host) serving the request-signing JWKS." }, "webhook_signing": { "type": "string", "format": "uri", "description": "Origin (scheme + host) serving the JWKS used for webhook delivery. Webhooks are signed with `adcp_use: \"request-signing\"` keys; the deprecated `adcp_use: \"webhook-signing\"` value remains accepted during the backward-compatibility window." }, "tmp_signing": { "type": "string", "format": "uri", "description": "Origin (scheme + host) serving the TMP-signing JWKS, when this operator participates in TMP." } }, "additionalProperties": false, "x-adcp-validation": { "verifier_constraints": { "purpose_anchoring": { "request_signing": "request_signing.supported_for | request_signing.required_for | request_signing.protocol_methods_supported_for | request_signing.protocol_methods_required_for non-empty", "webhook_signing": "webhook_signing.supported === true", "governance_signing": "governance protocol declared in supported_protocols", "tmp_signing": "trusted_match.surfaces non-empty (TMP participation)" } }, "spec": "docs/building/implementation/security.mdx#origin-separation" } }, "compromise_notification": { "type": "object", "description": "Whether this agent emits the `identity.compromise_notification` webhook event on key revocation due to known or suspected compromise (as opposed to scheduled rotation). Subscribers use this to bound the window between compromise detected and verifiers converging on revocation. See docs/building/implementation/webhooks.mdx §identity.compromise_notification.", "properties": { "emits": { "type": "boolean", "description": "Whether this agent emits `identity.compromise_notification` events.", "default": false }, "accepts": { "type": "boolean", "description": "Whether this agent subscribes to `identity.compromise_notification` events from counterparties it verifies signatures from.", "default": false } }, "additionalProperties": false } }, "additionalProperties": true }, "measurement_gateway": { "type": "object", "x-status": "experimental", "description": "Buyer-controlled task gateway between an orchestrator and measurement providers. In the first experimental tier, providers read buyer-approved cross-seller delivery through get_media_buy_delivery and return compact assertions through provide_performance_feedback, without receiving seller credentials. Orchestrators implementing this block MUST include measurement in supported_protocols and measurement.gateway in experimental_features; this gateway role does not claim the media_buy seller protocol.", "properties": { "delivery_task": { "type": "string", "const": "get_media_buy_delivery", "description": "Task providers call on the orchestrator gateway to read buyer-approved delivery." }, "feedback_task": { "type": "string", "const": "provide_performance_feedback", "description": "Task providers call on the orchestrator gateway to return one compact assertion." } }, "required": [ "delivery_task", "feedback_task" ], "additionalProperties": true }, "measurement": { "type": "object", "x-status": "experimental", "description": "Experimental measurement capability block. Presence indicates this agent computes one or more quantitative metrics about ad delivery, exposure, or effect, and is willing to be discovered as a measurement vendor. Agents implementing this block MUST list `measurement.core` in experimental_features. Returns metric definitions and whether the provider produces compact performance feedback, not pricing/coverage (negotiated via `measurement_terms` on `create_media_buy`) or raw/live datasets. Per-buy vendor values remain on delivery reports; optimizer-ready projections use provide_performance_feedback. AgenticAdvertising.org crawls each measurement agent's `metrics[]` on a TTL to populate the federated cross-vendor index.", "properties": { "produces_performance_feedback": { "type": "boolean", "description": "Whether this measurement agent produces compact provide_performance_feedback assertions for a buyer-controlled orchestrator gateway. In the first experimental tier the provider reads delivery through the gateway's get_media_buy_delivery task and returns assertions through its provide_performance_feedback task. The gateway decides what to forward to each seller.", "default": false }, "metrics": { "type": "array", "description": "Metrics this agent computes. Each entry is identified by `metric_id` within the vendor's vocabulary; the canonical reference everywhere a measurement value appears (`committed_metrics`, `vendor_metric_values`, `missing_metrics`) is the tuple `(vendor.domain, vendor.brand_id, metric_id)`.", "items": { "type": "object", "properties": { "metric_id": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/vendor-metric-id.json", "description": "Identifier for the metric within the vendor's vocabulary. Combined with the agent's BrandRef, forms the canonical tuple `(vendor.domain, vendor.brand_id, metric_id)`. Each metric_id MUST be unique within a single agent's catalog." }, "standard_reference": { "type": "string", "format": "uri", "description": "Optional URI pointing at the published standard this metric IMPLEMENTS (e.g., IAB Attention Measurement Guidelines, MRC Viewable Impression Measurement, GARM emissions framework). Distinct from `accreditations[]` — `standard_reference` is what the metric is built against; `accreditations[]` is third-party certification that the implementation actually conforms. Buyer agents normalizing across vendors SHOULD apply the AdCP URL canonicalization rules before comparing — vendors implementing the same standard MAY use different URL forms for the same canonical document." }, "accreditations": { "type": "array", "description": "Third-party accreditations this metric holds (MRC, ARF, JIC, ABC, BARB, AGOF, etc.). Distinct from `standard_reference`: a metric can implement a standard without being independently accredited. Buyers asking 'is this MRC-accredited?' SHOULD check this array, not just `standard_reference`. Each entry names the accrediting body and optionally pins a certification ID, validity date, and evidence URL.", "items": { "type": "object", "properties": { "accrediting_body": { "type": "string", "description": "Accrediting organization — open string (the global landscape includes MRC, ARF, ABC, BARB, JICWEBS, AGOF, JIC bodies in many markets). Use the canonical short name where one exists.", "examples": [ "MRC", "ARF", "ABC", "BARB", "JICWEBS", "AGOF" ] }, "certification_id": { "type": "string", "description": "Optional identifier for the certification in the accrediting body's records (when one exists; many bodies do not issue stable IDs)." }, "valid_until": { "type": "string", "format": "date", "description": "Optional ISO 8601 date when the current accreditation expires. Buyers MAY treat post-expiry data as un-accredited. Absence means the vendor does not assert an expiry — buyers SHOULD verify currency at the accrediting body's directory." }, "evidence_url": { "type": "string", "format": "uri", "description": "Optional URL pointing at the accrediting body's public listing for this certification (the buyer's path to verify the claim independently)." } }, "required": [ "accrediting_body" ], "additionalProperties": false }, "uniqueItems": true }, "unit": { "type": "string", "description": "Unit of the metric value when reported via `vendor_metric_values.value` (e.g., `score`, `seconds`, `persons`, `gCO2e`, `lift_percent`, `USD`). Buyers SHOULD render the unit alongside the value rather than computing units locally; sellers populating `vendor_metric_values.unit` MUST match this declaration when present.", "examples": [ "score", "seconds", "persons", "gCO2e", "lift_percent", "index", "USD" ] }, "description": { "type": "string", "description": "Human-readable description of what this metric measures and any relevant methodology notes. Surfaced in buyer-agent UX when explaining the metric to humans." }, "methodology_url": { "type": "string", "format": "uri", "description": "URL to the vendor's full methodology documentation for this metric. Buyers SHOULD link or fetch this when human review of the methodology is in scope (compliance, RFP review, accreditation audit). Field name mirrors `governance.property_features[].methodology_url`." }, "methodology_version": { "type": "string", "description": "Optional version identifier (semver, ISO date, or vendor-defined version string) for the methodology this metric currently implements. When present, buyer agents pin the contracted version on `committed_metrics` so silent vendor methodology changes are detectable; absence means the vendor does not version their methodology and buyers MUST treat any change as untracked.", "examples": [ "v2.1", "2026-Q1", "1.0" ] }, "ext": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/ext.json" } }, "required": [ "metric_id" ], "additionalProperties": false }, "minItems": 1, "uniqueItems": true } }, "required": [ "metrics" ] }, "compliance_testing": { "type": "object", "description": "Compliance testing capabilities. The presence of this block declares that the agent supports deterministic testing via comply_test_controller for lifecycle state machine validation. Omit the block entirely if the agent does not support compliance testing. Sellers SHOULD list every canonical controller scenario they implement so buyers and runners can distinguish full deterministic coverage from partial coverage without probing each scenario one by one; the runtime source of truth remains comply_test_controller with scenario: 'list_scenarios'.", "properties": { "scenarios": { "type": "array", "description": "Compliance testing scenarios this agent supports. Must be non-empty — at least one scenario. Values SHOULD include every canonical controller scenario the agent implements, excluding list_scenarios because that value is a discovery operation rather than a test capability. Values MAY also include implementation-specific scenarios. Callers can use comply_test_controller with scenario: 'list_scenarios' to discover supported scenarios at runtime.", "items": { "type": "string" }, "minItems": 1 } }, "required": [ "scenarios" ], "additionalProperties": true }, "specialisms": { "type": "array", "description": "Optional — specialized compliance claims this agent supports. Values MUST be kebab-case enum IDs (e.g., 'creative-generative', 'sales-non-guaranteed'). An agent that implements a specialism's tools but omits its ID from this array will receive 'No applicable tracks found' from the compliance runner — tracks for that specialism are not evaluated even if every tool works. Omitting the field means the agent declares no specialism claims (it still passes the universal + domain-baseline storyboards implied by supported_protocols). Each specialism maps to a storyboard bundle at /compliance/{version}/specialisms/{id}/ that the AAO compliance runner executes to verify the claim. Each specialism rolls up to one of the protocols in supported_protocols — the runner rejects a specialism claim whose parent protocol is missing. Only list specialisms your agent actually implements — the AAO Verified badge enumerates which specialisms were demonstrably passed.", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/enums/specialism.json" }, "uniqueItems": true }, "extensions_supported": { "type": "array", "description": "Extension namespaces this agent supports. Buyers can expect meaningful data in ext.{namespace} fields on responses from this agent. Extension schemas are published in the AdCP extension registry.", "items": { "type": "string", "pattern": "^[a-z][a-z0-9_]*$", "description": "Extension namespace (lowercase alphanumeric with underscores, e.g., 'iab_tcf', 'iab_gpp')" }, "uniqueItems": true }, "experimental_features": { "type": "array", "description": "Experimental AdCP surfaces this agent implements. A surface is experimental when its schema carries x-status: experimental and the working group has not yet frozen it. Sellers that implement any experimental surface MUST list its feature id here. Buyers inspect this array before relying on experimental surfaces — a seller that does not list a surface is asserting it does not implement it. Experimental surfaces MAY break between any two 3.x releases with at least 6 weeks notice; the full contract is in docs/reference/experimental-status.", "items": { "type": "string", "pattern": "^[a-z][a-z0-9_]*(\\.[a-z][a-z0-9_]*)*$", "description": "Experimental feature id (dot-separated lowercase identifiers, e.g., 'brand.rights_lifecycle', 'governance.campaign', 'measurement.core', 'trusted_match.core')" }, "uniqueItems": true }, "wholesale_feed_versioning": { "type": "object", "description": "Conditional-fetch token capabilities for get_products and get_signals. Independent of wholesale feed webhooks: an agent MAY support cheap version probes via if_wholesale_feed_version without pushing change payloads (and vice versa). When supported is true, the agent returns wholesale_feed_version on every get_products / get_signals response and honors if_wholesale_feed_version on subsequent requests. When absent or supported is false, callers MAY still send if_wholesale_feed_version — pre-3.1 agents that ignore it just return the full payload (correct, just inefficient). Pre-flight declaration here lets buyers fast-path which agents to bother caching versions for. See get_products / get_signals 'Wholesale feed versioning' sections.", "properties": { "supported": { "type": "boolean", "description": "Whether the agent returns wholesale_feed_version on responses and honors if_wholesale_feed_version on requests. When absent, treated as false; buyers MAY still probe (the field-presence detection path) but cannot pre-flight-decide." }, "pricing_version_separate": { "type": "boolean", "description": "Whether the agent tracks pricing_version independently of wholesale_feed_version. When true, the agent returns both tokens and honors if_pricing_version separately — useful for rate-card sweeps that don't change product and signal metadata. When false or absent, the agent collapses both into wholesale_feed_version; callers SHOULD NOT send if_pricing_version (it will be ignored and may produce INVALID_REQUEST when sent without if_wholesale_feed_version per the dependencies rule)." }, "cache_scope_account": { "type": "boolean", "description": "Whether the agent ever returns cache_scope: 'account' (i.e., publishes per-account overlays distinct from the public rate card). When true, buyers MUST be prepared to maintain account-overlay caches alongside the public layer. When false or absent, all responses are cache_scope: 'public' regardless of whether account was provided — the agent's rate card is universal. Confidentiality note: declaring true advertises that the agent runs custom-pricing deals (low-grade market-posture signal); agents preferring not to disclose this MAY omit the field and let consumers detect-on-call via cache_scope on response." } }, "required": [ "supported" ] }, "last_updated": { "type": "string", "format": "date-time", "description": "ISO 8601 timestamp of when capabilities were last updated. Buyers can use this for cache invalidation." }, "errors": { "type": "array", "description": "Task-specific errors and warnings", "items": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/error.json" } }, "context": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/context.json" }, "ext": { "$ref": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/core/ext.json" }, "wholesale_feed_webhooks": { "type": "object", "description": "Per-agent wholesale product-feed and wholesale signals-feed webhook capabilities. Consumers register durable sync_accounts notification subscribers and receive actual product.*, signal.*, or wholesale_feed.bulk_change payloads without polling. Product mirrors bootstrap and repair through list_products(if_feed_version); signal mirrors use get_signals(if_wholesale_feed_version). Deprecated wholesale get_products remains the 3.x product compatibility path. Webhook emission MUST apply the same caller/account authorization and cache-scope predicate as the corresponding read.", "properties": { "supported": { "type": "boolean", "description": "Whether this agent can push wholesale feed change payloads through account-level sync_accounts.accounts[].notification_configs[]. When false or absent, consumers fall back to wholesale polling, optionally with if_wholesale_feed_version probes." }, "event_types": { "type": "array", "description": "Wholesale feed webhook event types this agent can emit. Sales agents emit product.* events and MUST expose list_products or the deprecated 3.x wholesale get_products compatibility path. Signals agents emit signal.* events and MUST support wholesale get_signals. wholesale_feed.bulk_change requires at least one corresponding repair path.", "items": { "type": "string", "enum": [ "product.created", "product.updated", "product.priced", "product.removed", "signal.created", "signal.updated", "signal.priced", "signal.removed", "wholesale_feed.bulk_change" ] }, "minItems": 1, "uniqueItems": true, "x-adcp-validation": { "verifier_constraints": { "wholesale_feed_webhook_capability_consistency": { "product_events_require": { "field": "media_buy.buying_modes", "contains_item": "wholesale" }, "signal_events_require": { "field": "signals.discovery_modes", "contains_item": "wholesale" }, "bulk_change_requires_any": [ { "field": "media_buy.buying_modes", "contains_item": "wholesale" }, { "field": "signals.discovery_modes", "contains_item": "wholesale" } ], "bulk_change_affected_entity_type_must_match_declared_repair_path": true } }, "spec": "specs/wholesale-feed-webhooks.md#capability-declaration" } } }, "required": [ "supported" ], "additionalProperties": true } }, "required": [ "adcp", "supported_protocols" ], "additionalProperties": true }