Optionalmajor_Optionalsupported_OptionalfeaturesOptionalaccountOptionalcreativeOptionalextensions_Optionalrequest_RFC 9421 request-signing verifier capability. See
docs/building/implementation/security.mdx#signed-requests-transport-layer.
Emitted verbatim in get_adcp_capabilities.request_signing. Omit unless
the agent actually verifies incoming signatures — a supported: true
claim without a working verifier is graded as FAIL by the conformance
runner (see @adcp/sdk/testing/storyboard/request-signing).
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).
Optionalcovers_content_digest?: "required" | "forbidden" | "either"Policy for content-digest coverage in request signatures. 'required': signers MUST cover content-digest (body is bound to the signature); body-unbound signatures rejected with request_signature_components_incomplete. 'forbidden': signers MUST NOT cover content-digest; body-bound signatures rejected with request_signature_components_unexpected. This is an opt-out for the narrow case of legacy infrastructure that cannot preserve body bytes. 'either' (default): signer chooses per-request; verifier accepts both covered and uncovered forms. 'required' is recommended for spend-committing operations in production; 4.0 recommends 'required' for those operations.
Optionalrequired_for?: string[]AdCP protocol operation names (e.g., 'create_media_buy') for which this agent rejects unsigned requests with request_signature_required. 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. 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.). Counterparties MUST sign any listed operation.
Optionalwarn_for?: string[]AdCP protocol operation names for which this agent verifies signatures when present and logs failures but does NOT reject the request. Used as a shadow-mode bridge between supported_for and required_for: the verifier surfaces failure rates in monitoring before flipping an operation to required. Precedence: required_for > warn_for > supported_for. An operation in required_for ignores warn_for. Counterparties SHOULD sign operations in warn_for; verifiers MUST NOT reject if the signature is missing or invalid.
Optionalsupported_for?: string[]AdCP protocol operation names for which this agent verifies signatures when present but does not require them. Counterparties SHOULD sign operations in this list. Typically a superset of required_for and warn_for.
OptionalspecialismsSpecialism claims the agent supports. Each entry maps to a storyboard
bundle under /compliance/{version}/specialisms/{id}/; the AAO
compliance runner executes the matching storyboards to verify. Only
list specialisms the agent actually implements.
OptionalidempotencySeller-declared idempotency replay window, required on get_adcp_capabilities
responses per AdCP spec. Defaults to 86400 (24h). Spec bounds are 3600
(1h) to 604800 (7d); clampReplayTtl enforces the range on output.
When using createIdempotencyStore from @adcp/sdk/server, omit
this — the framework reads idempotency.ttlSeconds from the wired
store so the declared capability always matches actual behavior.
OptionalportfolioOptionaloverridesPer-domain capability blocks deep-merged on top of the framework's
auto-derived response. Use when you need to surface fields the top-level
AdcpCapabilitiesConfig doesn't model — execution.targeting,
audience_targeting, content_standards channels, conversion_tracking
identifier types, compliance_testing scenarios, etc.
Deep-merge semantics:
Top-level fields the framework owns (adcp, supported_protocols,
specialisms, extensions_supported) are not accepted here — configure
them via their dedicated fields on AdcpCapabilitiesConfig.
Release-precision versions this seller supports (AdCP 3.1+ per spec PR
adcontextprotocol/adcp#3493). Each entry parses to a major viaparseAdcpMajorVersion— the union of these majors andmajor_versionsdefines the seller's accepted set for the wire-leveladcp_major_version/adcp_versionclaim a buyer may carry.3.0-pinned sellers can ignore this field. 3.1+ sellers should declare here the same release-precision strings they emit in
adcp_versionon responses, so buyers receivingVERSION_UNSUPPORTEDcan read the supported set off the error envelope and downgrade their pin.