Creative Specification

​

Abstract

​

Protocol overview

• Format discovery with full technical specifications
• Manifest validation against format requirements
• AI-powered creative generation and transformation
• Preview rendering for creative verification
• Universal macros for cross-platform tracking

​

Transport requirements

{
  "$schema": "https://adcontextprotocol.org/schemas/3.2.0-beta.0/protocol/get-adcp-capabilities-response.json",
  "status": "completed",
  "adcp": {
    "major_versions": [2],
    "idempotency": { "supported": true, "replay_ttl_seconds": 86400 }
  },
  "supported_protocols": ["creative"],
  "creative": {
    "has_creative_library": true,
    "supports_generation": false,
    "supports_transformation": true,
    "supports_compliance": false,
    "supported_formats": [
      {
        "capability_id": "display_image_transform",
        "operations": ["build", "validate", "preview"],
        "format": {
          "format_kind": "image",
          "params": { "width": 300, "height": 250 }
        }
      }
    ]
  }
}

​

Core concepts

​

Creative agents

• Defines and documents formats it owns
• Validates manifests against format requirements
• Generates previews showing how creatives will render
• Optionally generates or transforms creatives from natural language briefs

​

Interaction models

• Transformation: get_adcp_capabilities → choose creative.supported_formats[].capability_id → build_creative with creative_manifest + target_capability_id
• Generation: get_adcp_capabilities → choose a build capability → build_creative with message + target_capability_id
• Library retrieval: list_creatives → build_creative with creative_id + target_capability_id

​

Format authority and creative capability

​

Formats

• Media family (display, video, audio, dooh)
• Required and optional asset types
• Technical constraints (dimensions, duration, file size, codecs)
• Rendering behavior and interaction expectations

​

Assets

• image: Static images (JPEG, PNG, WebP, GIF)
• video: Video files (MP4, WebM, MOV) or VAST tags
• audio: Audio files (MP3, M4A) or DAAST tags
• text: Headlines, descriptions, CTAs
• html: HTML5 creatives or third-party tags
• javascript: JavaScript tags
• url: Tracking pixels, clickthrough URLs

​

Manifests

• Canonical format_kind and optional product/publisher format_option_ref
• Asset values keyed by canonical slot name
• Tracking URLs and macros

​

Native creative localization

• The creative’s top-level assets are the source variant.
• localization.source binds those assets to a canonical BCP 47 tag and a buyer-assigned locale_variant_id.
• target_variants[] may be empty for a monolingual source-only creative. Every target entry has a unique locale and stable locale_variant_id plus locale-specific materialized asset overrides; missing slots inherit source assets.
• default_locale_variant_id explicitly identifies the serving fallback. It may reference the source or a target; source does not imply default.
• locale_fallbacks[] optionally maps a canonical requested language range to a source or target variant. These are explicit buyer-approved substitutions, not inferred equivalence between regional variants.
• unmatched_locale_action is serve_default or do_not_serve.

​

Universal macros

• {TIMESTAMP}: Unix timestamp
• {CACHEBUSTER}: Random cache-busting value
• {CLICK_URL}: Click tracking URL
• {REDIRECT_URL}: Final destination URL

​

Creative Status Lifecycle

sync_creatives ──▶ processing ──▶ pending_review ──▶ approved
                       │                 │              │
                       │                 │              ├──▶ suspended ──▶ approved
                       │                 │              │        │
                       │                 │              │        └──▶ rejected
                       │                 │              ├──▶ pending_review
                       │                 │              ├──▶ rejected
                       │                 │              └──▶ archived
                       │                 │
                       └──────▶ rejected ◀──────────────┘
                                  │
                                  └── buyer fixes + resubmits ──▶ processing

archived ── buyer unarchives ──▶ approved (or pending_review when re-review is required)

• processing → pending_review: automatic when ingestion and transcoding succeed
• processing → rejected: automatic when processing fails (corrupt file, unsupported codec, constraint violation)
• pending_review → approved: seller approves after content policy review
• pending_review → rejected: seller rejects with rejection_reason
• approved → suspended: seller detects a recoverable dependency/authorization loss, such as identity_authorization_revoked, identity_authorization_expired, or source_private for a published_post reference. Sellers MUST surface a corresponding impairment on affected active buys.
• suspended → approved: seller observes that the dependency is restored and any required re-review passes.
• suspended → rejected: seller determines that a previously recoverable dependency/authorization loss cannot be restored for this creative, or that replacement/resubmission is required. Example: a revoked identity/post authorization for a published_post reference cannot be reauthorized. Sellers MUST keep affected active buys impaired until the creative is replaced, reassigned, or the package/buy is otherwise remediated.
• approved → archived (buyer-initiated): buyer issues archive via sync_creatives
• approved → archived (seller-initiated): seller archives an unassigned creative for inactivity, post-flight expiry, or storage policy. Sellers MUST NOT seller-archive a creative that has active package assignments — the approved → rejected (revocation) path with an impairment on the affected buy is the only conformant route when active serving is involved. State-change observability for seller-initiated archive follows the creative retention contract — minimally, the new status MUST be visible on the next list_creatives read.
• archived → approved: buyer-initiated via sync_creatives (unarchive). Sellers MAY require re-review, transitioning to pending_review instead.
• rejected → processing: buyer fixes the creative and resubmits via sync_creatives. The creative re-enters the full processing and review pipeline.
• approved → pending_review: seller-initiated re-review (e.g., policy change). Sellers MUST notify subscribers via creative.status_changed (fired to each notification_configs[] subscriber whose event_types[] includes this value — see below) when a previously approved creative is pulled back for re-review.

​

Lifecycle webhooks

• creative.status_changed — fires on every seller-initiated or system-initiated transition: pending_review → approved/rejected, approved → pending_review (re-review), approved → suspended (recoverable dependency/authorization loss), suspended → approved (recovery), suspended → rejected (terminal dependency/authorization loss), approved → rejected (post-approval revocation), approved → archived (seller-initiated). Payload: creative-status-changed-webhook.json.
• creative.purged — fires when a creative is destroyed (retention sweep, takedown, legal erasure). soft purges retain a tombstone on list_creatives (with include_purged: true) for 30 days; hard purges retain no record — the webhook is the buyer’s only signal. Payload: creative-purged-webhook.json.

​

Pricing

​

Pricing discovery surfaces

• list_creatives — ad servers and library-based agents expose pricing_options[] on each creative. The buyer discovers pricing for specific creatives they want to use.
• list_transformers — transformation and generation agents expose account-scoped pricing_options[] and canonical output_capability_ids on selectable transformers.

​

Pricing flow

1. Account setup — rate card agreed. Determines pricing for all subsequent operations.
2. Discovery — list_creatives or list_transformers with account and include_pricing: true returns pricing_options[]. Vendors may offer multiple options.
3. Build — build_creative with account. The agent computes the cost and returns pricing_option_id, vendor_cost, currency, and consumption in the response.
4. Report — report_usage with creative_id and pricing_option_id for reconciliation.

​

Pricing models

​

Consumption details

​

Accounts requirement

​

Bundled mode

​

Tasks

​

get_adcp_capabilities

• Every entry MUST carry a canonical format declaration; new 3.2 producers MUST also carry a stable capability_id
• Exact publisher-format claims MUST carry {publisher_domain, format_option_id}
• Generic capabilities MUST declare an honest parameter envelope
• New 3.2 producers MUST carry explicit operations to distinguish build, validation, and preview support. Consumers interpret omission on legacy 3.x entries as build.

​

list_transformers

• Creative agents that set creative.supports_transformers: true MUST implement list_transformers
• Creative agents MUST resolve transformers, their enumerable option values, and pricing for the calling account — including custom values configured for that account (e.g. cloned voices)
• Creative agents MUST return account-scoped option values inline on params[].options[] for each field named in expand_params, and SHOULD omit them otherwise
• When include_pricing is true, creative agents that charge MUST include pricing_options (the per_unit model) on each transformer

​

build_creative

1. Generation: Create a manifest from a brief or seed assets
2. Transformation: Adapt an existing manifest to a different format
3. Library retrieval: Resolve a creative_id from the agent’s library into a manifest with ad-serving assets (HTML/JavaScript/VAST tags)

• Creative agents MUST validate input manifests against format requirements
• Creative agents MUST return a valid manifest for the target format on success
• Creative agents MUST return validation errors if the transformation cannot be completed
• Creative agents SHOULD preserve tracking URLs and macros during transformation
• Creative agents SHOULD respect quality for generative tasks ("draft" for fast iteration, "production" for final delivery) and MAY ignore it for non-generative transforms
• Creative agents SHOULD honor item_limit when present, using the lesser of item_limit and the format’s max_items
• Creative agents MAY use AI/LLM processing for generation tasks
• When creative_id is provided, creative agents MUST resolve the creative from their library
• When macro_values is provided, creative agents SHOULD substitute the specified macros in the output manifest’s assets and leave unresolved macros as {MACRO} placeholders
• Creative agents MUST ignore unrecognized macro keys in macro_values — unknown macros are not an error
• Creative agents SHOULD assign globally unique creative_id values; when they cannot guarantee uniqueness, concept_id is REQUIRED on build_creative requests to disambiguate
• build_creative supports async responses (status: "working" with context_id polling) for generation and transformation tasks that take significant time. Library retrieval is typically synchronous.
• When account is provided and the agent charges, the response MUST include pricing_option_id, vendor_cost, and currency. The consumption object SHOULD be included when relevant.
• For async builds, pricing fields appear on the final completed response only, not on intermediate status responses.
• When a paid creative agent receives a build_creative request without account and the agent requires an account, the agent MUST return an error.

​

preview_creative

• Creative agents MUST validate manifests before generating previews
• Creative agents MUST return preview URLs or HTML for valid manifests
• Creative agents MUST keep preview URLs dereferenceable until their expires_at timestamp. When expires_at is omitted, preview URLs do not expire at the protocol layer and remain valid until the agent explicitly revokes them out of band.
• Creative agents SHOULD include expires_at for time-limited preview URLs
• Creative agents SHOULD support batch preview for multiple creatives
• Creative agents MAY support multiple output formats (URL, HTML, image)

​

list_creatives

• Agents MUST return creatives accessible to the authenticated account
• Agents MUST include approval status for each creative
• Agents SHOULD support filtering by format, status, tags, and date range
• Agents SHOULD support filtering by concept_ids and canonical format_kinds when the platform organizes creatives into concepts
• Agents MAY include dynamic content variable definitions when include_variables=true
• Agents MAY include a lightweight delivery snapshot when include_snapshot=true. The snapshot provides lifetime impressions and last-served date for operational use — detailed analytics belong in get_creative_delivery.
• Sales agents declaring list_creatives in media_buy.relationship_notifications.projection_tasks MUST scope creative indicators to assignments.assigned_packages[].indicators[]; they MUST NOT place package- or publisher-specific fatigue on the creative as a global property.
• Those sellers MUST include media_buy_id and approval_status on every assignment row, including rows whose indicator state is unknown. rejection_reason and approval_scopes mirror the media-buy projection. indicator_types_evaluated declares exact type coverage; indicators_evaluated_scope declares partial publisher/placement coverage.
• When the same relationship is visible through both reads, media_buy_id, package_id, creative_id, approval_status, rejection_reason, and approval_scopes MUST agree. Indicator timestamps and evaluation coverage SHOULD converge, but a later read MAY reflect a strictly newer evaluation; buyers reconcile toward the newer indicators_as_of rather than treating a legitimate reevaluation between calls as incoherence.
• Indicator polling is always available through get_media_buys when supported_indicator_types is declared. Sellers may additionally accept prospective indicators.changed and independently accept creative.assignment_changed, including when they are inline-only. Receivers of either event establish a complete all-status or known-ID baseline and repair through get_media_buys rather than treating payloads or the bounded reverse projection as complete relationship state.
• When account and include_pricing=true are provided, agents that charge MUST include pricing_options on each creative — an array of vendor-pricing-option objects. Vendors may offer multiple options per creative (volume tiers, context-specific rates, different pricing models).

• Creative agents that charge for their services MUST implement the Accounts Protocol. This applies to any creative agent with pricing — ad servers, generation platforms, and transformation agents that bill for usage.
• Creative agents that host a library but do not charge SHOULD implement the Accounts Protocol so buyers can establish access before querying.
• This is the same accounts protocol used by sales agents — there is no separate version.
• Sales agents that already implement accounts for media buys do not need to do anything additional.

​

sync_creatives

• Agents MUST validate creatives against format specifications
• Agents MUST return validation errors for non-compliant creatives
• Agents MAY require approval before creatives are available for use
• Agents SHOULD support dry_run for validation without applying changes
• Agents MUST reject requests that combine delete_missing: true with creative_ids — delete_missing applies to the entire library, not a filtered subset
• Agents that advertise creative.localization MUST reject unsupported localization before mutation and return exact localization readback on every accepted localized creative
• Agents that also manage media buys SHOULD support the assignments field for bulk creative-to-package mapping
• Standalone creative agents that do not manage media buys SHOULD ignore the assignments field

​

get_creative_delivery

• Agents MUST return delivery data for the requested creatives
• Agents SHOULD include variant-level breakdowns when available
• Sales agents implementing the Creative Protocol SHOULD support this task when their products generate or optimize creative variants

​

Error handling

• FORMAT_NOT_SUPPORTED: Requested creative capability does not exist or is not accessible (error.field identifies target_capability_id or the indexed plural field)
• VALIDATION_ERROR: Manifest failed format validation: a required asset is missing from the manifest, or an asset does not meet the format’s constraints (error.field identifies the offending asset path)

​

Security considerations

​

Transport security

​

Asset security

• Creative agents SHOULD validate that asset URLs are accessible
• Creative agents SHOULD scan assets for malware and malicious content
• Creative agents MUST NOT execute untrusted JavaScript during validation

​

Preview security

• Preview URLs SHOULD be time-limited (indicated by expires_at)
• Preview URLs MUST NOT depend on pod-local or process-local state unless the agent can guarantee that state for the advertised lifetime of the URL
• Creative agents SHOULD sandbox HTML previews to prevent script execution
• Consumers of output_format: "html" MUST only use trusted creative agents

​

Conformance

​

Creative agent conformance

1. Support at least one specified transport (MCP or A2A)
2. Implement get_adcp_capabilities and publish canonical creative.supported_formats[]
3. Give every supported-format entry a stable capability_id and accurate operations
4. Validate manifests against format specifications
5. Use specified error codes

1. Implement build_creative for creative generation
2. Implement preview_creative for preview rendering
3. Support universal macros in tracking URLs
4. Implement list_creatives when the agent hosts a creative library
5. Implement sync_creatives when the agent accepts creative uploads
6. Support creative_id in build_creative when the agent hosts a creative library
7. Implement the accounts protocol (sync_accounts / list_accounts) when hosting a creative library
8. Declare supports_generation, supports_transformation, and has_creative_library in get_adcp_capabilities so buyers can determine the correct interaction model

​

Consumer conformance

1. Discover creative operations through creative.supported_formats[] and route builds with target_capability_id(s)
2. Validate manifests against format specifications before submission
3. Handle validation errors appropriately
4. Confirm the selected registry candidate directly with get_adcp_capabilities

​

Implementation notes

​

Response time expectations

​

Creative-agent discovery

​

Format-aware validation

1. Resolve the selected canonical product/publisher declaration
2. For each manifest asset, find the corresponding declared slot
3. Validate its explicit asset_type discriminator and constraints against that slot

​

Standard vs custom formats

• Canonical formats: Registered AdCP format_kind contracts shared across publishers, sellers, and creative agents
• Custom formats: format_kind: "custom" plus a recognized format_shape and digest-pinned format_schema

​

Schema reference