Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.adcontextprotocol.org/llms.txt

Use this file to discover all available pages before exploring further.

​
Capabilities explorer

This page renders the actual top-level shape of the get_adcp_capabilities response so you can find the right place for a new capability before you propose it. The most common reason an extension RFC gets bounced is wrong-shape: the proposal puts a flag at a level that doesn’t match where similar flags already live. Walk the tree first. If you’re here to draft an RFC, the workflow is:
  1. Find the closest existing top-level domain for your flag below.
  2. Drill into that domain’s sub-namespaces (features, execution, etc.).
  3. If your flag fits an existing sub-namespace, propose it there. Use the propose extension here link at the relevant node — it pre-fills the issue title with the path.
  4. If nothing fits, scroll to Before proposing a new top-level key at the bottom and answer the gate questions in your RFC body.
The authoritative schema lives at static/schemas/source/protocol/get-adcp-capabilities-response.json. The tree below is curated to one level deep for the rich domains; for the full nested shape, read the schema. See also Design principles — capabilities are commitments, declared under existing buckets.

​
Top-level domains

The 14 domains below are the entire top-level surface of get_adcp_capabilities. Every capability flag eventually nests under one of these. New top-level keys are extremely rare and should not be the first move — see the gate questions at the end of this page.

​
adcp — core protocol identity

Version negotiation, idempotency contract, build identifier.
  • supported_versions — release-precision strings (e.g. "3.0", "3.1-beta"). Authoritative for buyer-side release pinning.
  • major_versions — DEPRECATED in favor of supported_versions; sellers MUST keep emitting through 3.x.
  • build_version — full semver build identifier; advisory metadata for buyer-side incident triage.
  • idempotency — discriminated union (IdempotencySupported / IdempotencyUnsupported) declaring replay semantics. A declaration here is a commitment — sellers that declare supported: true are probed by the conformance runner.
Propose an extension to adcp

​
supported_protocols — which AdCP protocols this agent implements

Array of protocol names. Each value commits the agent to (a) implement those tools and (b) pass the baseline compliance storyboard at /compliance/{version}/protocols/{protocol}/. Valid values cover media_buy, creative, signals, governance, sponsored_intelligence, brand, accounts, measurement (in development). Propose a new protocol to add to supported_protocols

​
account — account establishment and billing

How accounts are negotiated; whether one is required before product discovery; what billing models are supported.
  • required_for_products — boolean. If true, get_products requires an established account.
  • authorization_endpoint — OAuth/auth URL for account negotiation.
  • require_operator_auth — declares whether operator-level authentication is required.
  • supported_billing — array of billing models (e.g. prepaid, monthly_invoice).
  • account_financials — what financial data the seller exposes (credit limits, current balance, etc.).
  • sandbox — sandbox-account capabilities.
Propose an extension to account

​
media_buy — media buying capabilities

The largest domain. Sub-namespaces are where most media-buying flags belong.
  • features — boolean feature flags (e.g. inline_creative_management, property_list_filtering, catalog_management, committed_metrics_supported). Most new media-buy capability flags belong here.
  • execution — technical execution capabilities. Contains trusted_match (TMP), creative_specs (VAST/MRAID/VPAID/SIMID versions), targeting (geo / audience / device / temporal), axe_integrations (deprecated). See note in Design principles — Where the surface doesn’t yet follow these about the trusted_match placement.
  • audience_targeting — declared audience-targeting capabilities.
  • content_standards — content-standards enforcement capabilities.
  • conversion_tracking — conversion-tracking capabilities.
  • offline_delivery_protocols — supported offline delivery protocols (broadcast trafficking, etc.).
  • portfolio — portfolio-management capabilities.
  • reporting_delivery_methods — how reporting is delivered.
  • supported_pricing_models — array (CPM, CPC, CPCV, CPP, fixed, etc.).
Propose a flag for media_buy.features Propose an extension to media_buy.execution

​
signals — audience and contextual data activation

Authorization scope and feature flags for the signals domain.
  • data_provider_domains — array of domains this signals agent is authorized to resell. Buyers fetch each provider’s adagents.json to verify.
  • features — boolean feature flags. Currently catalog_signals (structured signal_id references). Additional signals capability flags belong here, not in a new top-level key. (E.g., a signal_enforcement_on_guaranteed flag for direct-sold targeting belongs at signals.features, not under media_buy.execution.trusted_match.)
Propose a flag for signals.features

​
governance — governance protocol capabilities

Property and creative governance capabilities.
  • property_features — what the governance agent does with property lists.
  • creative_features — what the governance agent does for creative review.
  • aggregation_window_days — how long the agent aggregates governance events.
Propose an extension to governance
For agents that handle SI sessions.
  • endpoint — SI endpoint URL.
  • brand_url — brand identity URL.
  • capabilities — SI-specific capabilities (commerce handoff, voice, UI components, etc.).
Propose an extension to sponsored_intelligence

​
brand — brand protocol capabilities

For brand agents.
  • description — agent description.
  • available_uses — what the brand data is licensed for.
  • generation_providers — supported generation providers.
  • right_types — right types the agent grants.
  • rights — concrete rights this agent issues.
Propose an extension to brand

​
creative — creative protocol capabilities

For creative agents.
  • has_creative_library — whether the agent maintains a creative library.
  • supports_compliance — creative compliance scanning.
  • supports_generation — generative-creative capabilities.
  • supports_transformation — creative transformation capabilities.
Propose an extension to creative

​
request_signing — RFC 9421 HTTP Signatures for incoming requests

Optional in 3.0; capability-advertised so counterparties can opt into signing selectively.
  • supported — boolean.
  • required_for — array of operations where signing is required.
  • supported_for — array of operations where signing is supported.
  • warn_for — array of operations where unsigned requests produce warnings.
  • covers_content_digest — whether signatures cover the request body digest.
Propose an extension to request_signing

​
webhook_signing — RFC 9421 signing for outbound webhooks

Top-level peer of request_signing.
  • supported — boolean.
  • profile — signing profile name.
  • algorithms — supported signature algorithms.
  • legacy_hmac_fallback — whether HMAC fallback is supported for legacy receivers.
Propose an extension to webhook_signing

​
identity — operator identity posture

Key-scoping and compromise-response controls. Advisory in 3.x; required in 4.0.
  • per_principal_key_isolation — whether each principal has an isolated key.
  • key_origins — declared key-management origins.
  • compromise_notification — notification posture for key compromise events.
Propose an extension to identity

​
measurement — measurement capabilities (in development)

Quantitative metrics about ad delivery, exposure, or effectiveness.
  • metrics — array of metric definitions this agent emits.
The protocol surface beyond capabilities discovery (reporting, attribution tasks) lands in subsequent minors. Propose an extension to measurement

​
compliance_testing — deterministic test scenarios

Declares the agent supports comply_test_controller and which scenarios are honored.
  • scenarios — array of compliance scenario IDs the agent supports.
Propose an extension to compliance_testing

​
specialisms — kebab-case specialty IDs

Optional. Specialty compliance claims (e.g., creative-generative, sales-non-guaranteed). Values are kebab-case enum IDs registered with the working group. Propose a new specialism

​
Things-this-agent-does that aren’t a domain

Three top-level lists carry capability metadata that doesn’t fit a single protocol domain. The shape inconsistency between them is on the open list (Design principles — Where the surface doesn’t yet follow these).
  • extensions_supported — array of extension namespaces this agent populates (ext.{namespace}).
  • experimental_features — array of experimental surface IDs this agent implements (e.g. trusted_match.core).
  • compliance_testing — covered above.

​
Before proposing a new top-level key

If your flag genuinely doesn’t fit any of the 14 domains above, open the RFC — but answer these gate questions in the body. Most reviewers expect them. RFCs that ignore them tend to bounce.
  1. Which existing top-level domain is closest? Name it. Explain why your flag isn’t an extension to that domain’s features, execution, or other sub-namespaces.
  2. Why isn’t this an ext.{vendor} extension? Vendor-specific behavior belongs in vendor namespaces (spec-guidelines on platform agnosticism). Why is your flag normative across all implementers?
  3. What’s the conformance probe? A capability declaration is a commitment, not an advertisement. How does the conformance runner verify a seller that declares your flag actually honors it?
  4. What does this rule out? What proposals does adding this top-level key make easier — and what does it make harder for someone scanning the top level a year from now?
These are the same questions reviewers will ask. Answering them in the RFC saves a round-trip. Propose a new top-level capability key (use only after answering the gate questions)