> ## 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.

# Creative Specification

> The AdCP Creative Protocol specification defines format discovery, manifest validation, AI creative generation, and preview rendering.

<Info>
  **AdCP 3.0 Proposal** - This specification is under development for AdCP 3.0. Feedback welcome via [GitHub Discussions](https://github.com/adcontextprotocol/adcp/discussions).
</Info>

> **Canonical formats in 3.1**: this page describes the v1 specification model. For the canonical-formats model (inline `format_options` on products, `validate_input` primitive), see [canonical-formats](/docs/creative/canonical-formats) and the [migration guide](/docs/creative/canonical-formats-migration).

**Status**: Request for Comments
**Last Updated**: March 2026

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119).

## Abstract

The Creative Protocol defines a standard interface for creative format discovery, manifest validation, creative generation, and preview rendering. This protocol enables AI agents to discover format specifications, build compliant creative assets, and generate previews across advertising platforms.

## Protocol overview

The Creative Protocol provides:

* 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

Creative agents MUST support at least one of the following transports:

| Transport | Protocol               | Description                         |
| --------- | ---------------------- | ----------------------------------- |
| MCP       | Model Context Protocol | Tool-based interaction via JSON-RPC |
| A2A       | Agent-to-Agent         | Message-based interaction           |

Creative agents SHOULD support MCP as the preferred transport.

Creative agents MUST declare Creative Protocol support via `get_adcp_capabilities`:

```json theme={null}
{
  "$schema": "https://adcontextprotocol.org/schemas/v3/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
  }
}
```

The `creative` capabilities tell the buyer which interaction models this agent supports. See [Interaction models](#interaction-models) below.

## Core concepts

### Creative agents

A creative agent is any agent that implements the Creative Protocol. This includes standalone services (ad servers, creative management platforms, generative tools) and sales agents that declare `"creative"` in `supported_protocols`. A creative agent:

* 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

Sales agents that implement both the Media Buy Protocol and the Creative Protocol serve both roles from a single endpoint. See [Creative capabilities on sales agents](/docs/creative/sales-agent-creative-capabilities).

### Interaction models

Creative agents serve different roles depending on their capabilities. Buyers use `get_adcp_capabilities` to determine which interaction model applies:

| Model                    | Description                                         | Capabilities                    | Examples                    |
| ------------------------ | --------------------------------------------------- | ------------------------------- | --------------------------- |
| **Transformation agent** | Resizes or adapts existing manifests to new formats | `supports_transformation: true` | Format conversion services  |
| **Generative agent**     | Creates manifests from natural language briefs      | `supports_generation: true`     | AI creative platforms       |
| **Creative ad server**   | Hosts a creative library, generates ad-serving tags | `has_creative_library: true`    | Flashtalking, CM360, Celtra |

These models compose — an agent can support multiple. A creative ad server with `supports_generation: true` and `has_creative_library: true` can both generate creatives from briefs and retrieve existing ones from its library. The `supports_compliance` flag is orthogonal — any interaction model can support compliance requirements in briefs.

**Buyer workflow by model:**

* **Transformation**: `list_creative_formats` → `build_creative` (with `creative_manifest` + `target_format_id`)
* **Generation**: `list_creative_formats` → `build_creative` (with `message` + `target_format_id`)
* **Library retrieval**: `list_creatives` → `build_creative` (with `creative_id` + `target_format_id`)

Agents that host a creative library should also implement the [accounts protocol](/docs/accounts/overview) so buyers can establish access before querying. Sales agents that already implement accounts for media buys do not need to do anything additional.

A transformation or generation agent that charges for its services implements the Accounts Protocol, exposes `pricing_options` on `list_creative_formats`, and returns pricing in `build_creative` responses. Agents that persist `creative_id` on build output can also expose pricing on `list_creatives`. Free transformation agents remain stateless and unchanged.

### Format authority

Each format has exactly one authoritative creative agent, identified by the `agent_url` in the format ID:

```json theme={null}
{
  "format_id": {
    "agent_url": "https://creative.adcontextprotocol.org",
    "id": "display_300x250_image"
  }
}
```

Creative agents MUST only return authoritative format definitions for formats they own.

Creative agents MAY reference other creative agents that provide additional formats.

### Formats

Formats define how assets are assembled and rendered. A format specifies:

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

### Assets

Assets are the building blocks of creatives. Asset types include:

* **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

Manifests pair format specifications with actual asset content. A manifest provides:

* Format reference (agent\_url + id)
* Asset values keyed by asset\_id from the format
* Tracking URLs and macros

Creative agents MUST validate manifests against format requirements before accepting them.

### Universal macros

AdCP defines universal macros for cross-platform tracking. Creative agents MUST support these macros in tracking URLs:

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

Sales agents MUST translate universal macros to their ad server's native syntax.

## Creative Status Lifecycle

**Schema**: [`enums/creative-status.json`](https://adcontextprotocol.org/schemas/v3/enums/creative-status.json)

Creatives in a library progress through a defined set of states. Most transitions are seller-initiated (processing, review, approval/rejection). `suspended` is a recoverable offline state for approved creatives whose dependencies become unavailable, such as an expired published-post authorization. `archived` is reached either by buyer cleanup or by seller-side lifecycle policy on creatives without active assignments — see the rules below.

```
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)
```

**Rules:**

* `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](/docs/creative/creative-libraries#creatives-outlast-campaigns) — 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.

Creative agents MUST reject operations that reference a `rejected` creative for delivery (e.g., assigning it to a package) with error code `CREATIVE_REJECTED`. Creative agents MUST also prevent delivery of `suspended` creatives until the dependency is restored.

Creative agents MUST include `status` and `rejection_reason` (when rejected) in `list_creatives` responses.

### Lifecycle webhooks

Seller-initiated and system-initiated transitions fire push notifications against the account's [`notification_configs[]`](/docs/accounts/tasks/sync_accounts#account-level-webhook-subscriptions) subscribers — each entry whose `event_types[]` includes the fired type receives an independent fire. Two event types cover the surface:

* **`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`](https://adcontextprotocol.org/schemas/v3/creative/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`](https://adcontextprotocol.org/schemas/v3/creative/creative-purged-webhook.json).

Buyer-initiated transitions (archive, unarchive, resubmit) do NOT fire — those are acknowledged on the `sync_creatives` response path. The push channel exists only for transitions the buyer did not initiate.

Both events carry a categorical `reason_code` drawn from [`creative-event-reason-code.json`](https://adcontextprotocol.org/schemas/v3/enums/creative-event-reason-code.json). Buyer-side remediation per reason code is documented inline on the enum's `enumDescriptions`.

When a creative transitions to a state that breaks active serving (`approved → suspended`, `approved → rejected`, `suspended → rejected`, or seller-initiated `approved → archived` while assignments exist — which is non-conformant; see the transition rules above), the seller MUST also surface a corresponding `impairment` on every media buy referencing the creative (see [Media buy health](/docs/media-buy/media-buys/lifecycle#health-and-impairments)). The creative-side `creative.status_changed` and the buy-side `impairment` are paired but distinct signals; buyers correlate by `creative_id`. The two surfaces have different anchors: creative events fire account-level (subscriptions outlive any one buy); impairments fire per-buy. **No ordering guarantee** between the paired fires — buyers MUST NOT assume one arrives before the other; reconcile via the snapshot (`list_creatives` and `get_media_buys`).

Sellers declare which event types they support and per-type coalescence windows via `get_adcp_capabilities`. Default coalescence is 5 minutes for `creative.status_changed`; sellers MUST NOT coalesce `creative.purged`. Retroactive contract: when a seller declares support for these event types, the obligation covers all creatives in the library — no grace period for pre-existing creatives.

Buyers MAY pull recent webhook fires per creative via `list_creatives` with `include_webhook_activity: true`. The read surface follows the [`webhook_activity[]` adoption checklist](/docs/protocol/snapshot-and-log#webhook-activity-log-pattern) — 30-day retention, three-state presence semantics, `idempotency_key` correlation to buyer-side endpoint logs.

## Pricing

Creative agents that charge for their services expose pricing through the same discover → build → report loop used by signals agents and content standards agents.

### Pricing discovery surfaces

Pricing is discovered via two surfaces depending on the agent's interaction model:

* **`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_creative_formats`** — transformation and generation agents expose `pricing_options[]` on each format. The buyer discovers pricing for the formats the agent can produce, before any creative exists.

Both surfaces use the same `pricing_options[]` array of [`vendor-pricing-option`](https://adcontextprotocol.org/schemas/v3/core/vendor-pricing-option.json) objects. Both require `account` and `include_pricing: true` on the request.

An agent MAY expose pricing on both surfaces (e.g., a creative management platform that has both a library and transformation capabilities).

### Pricing flow

1. **Account setup** — rate card agreed. Determines pricing for all subsequent operations.
2. **Discovery** — `list_creatives` or `list_creative_formats` with `account` and `include_pricing: true` returns `pricing_options[]`. Vendors may offer multiple options (volume tiers, context-specific rates, different models per product line).
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

Creative agents reuse the vendor pricing models defined in [`vendor-pricing-option.json`](https://adcontextprotocol.org/schemas/v3/core/vendor-pricing-option.json):

| Model              | Creative use case                                                                                       |
| ------------------ | ------------------------------------------------------------------------------------------------------- |
| `cpm`              | Cost per thousand impressions served — ad server model, DCO platforms                                   |
| `percent_of_media` | Percentage of media spend — agency/platform model                                                       |
| `flat_fee`         | Fixed charge per period — licensed creative suites, subscription access                                 |
| `per_unit`         | Fixed price per unit of work — per format adapted, per image generated, per token, per variant rendered |

### Consumption details

**Schema**: [`core/creative-consumption.json`](https://adcontextprotocol.org/schemas/v3/core/creative-consumption.json)

The `build_creative` response includes a `consumption` object with structured details about what was consumed. Well-known fields: `tokens` (LLM tokens consumed), `images_generated`, `renders` (render passes), `duration_seconds` (processing time). Agents MAY include additional fields.

The `consumption` object is informational — it lets the buyer verify that `vendor_cost` is consistent with the rate card. `vendor_cost` is the billing source of truth.

### Accounts requirement

Creative agents that charge for their services MUST implement the [Accounts Protocol](/docs/accounts/overview). This applies to any creative agent with pricing — ad servers, generation platforms, and transformation agents that bill for usage.

### Bundled mode

When a publisher uses a creative agent internally (bundled), the buyer never sees the creative agent's pricing. The cost is absorbed into product pricing. The sales agent is the buyer in the creative agent relationship — it establishes an account, calls `build_creative`, and handles `report_usage`. The protocol surface is the same.

## Tasks

The Creative Protocol defines the following tasks. See task reference pages for complete request/response schemas and examples.

### list\_creative\_formats

**Reference**: [`list_creative_formats` task](/docs/creative/task-reference/list_creative_formats)

Discover creative formats and their specifications.

**Requirements:**

* Creative agents MUST return full format specifications for formats they own
* Creative agents MUST include `agent_url` identifying the authoritative agent for each format
* Creative agents MUST include technical constraints (dimensions, duration, file types) in format definitions
* Creative agents MAY include references to other creative agents providing additional formats
* When filtering by `format_ids`, creative agents MUST return only the requested formats

### list\_transformers

**Reference**: [`list_transformers` task](/docs/creative/task-reference/list_transformers)

Discover the account-scoped transformers a creative agent offers — the creative analog of media-buy products: agent-offered, selectable units of build capability (voices, models, styles) that you select with `transformer_id` in `build_creative`. Offered only by agents that declare `creative.supports_transformers: true` in `get_adcp_capabilities`.

**Requirements:**

* 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

**Reference**: [`build_creative` task](/docs/creative/task-reference/build_creative)

Transform, generate, or retrieve creative manifests. Supports three modes:

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)

**Requirements:**

* 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

**Reference**: [`preview_creative` task](/docs/creative/task-reference/preview_creative)

Generate preview renderings of creative manifests.

**Requirements:**

* 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

**Schema**: [`creative/list-creatives-request.json`](https://adcontextprotocol.org/schemas/v3/creative/list-creatives-request.json) / [`creative/list-creatives-response.json`](https://adcontextprotocol.org/schemas/v3/creative/list-creatives-response.json)

**Reference**: [`list_creatives` task](/docs/creative/task-reference/list_creatives)

Browse and filter creative assets in a creative library. Implemented by any agent that hosts a creative library — ad servers, creative management platforms, and sales agents that manage creatives.

**Requirements:**

* 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 `format_ids` 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`.
* When `account` and `include_pricing=true` are provided, agents that charge MUST include `pricing_options` on each creative — an array of [`vendor-pricing-option`](https://adcontextprotocol.org/schemas/v3/core/vendor-pricing-option.json) objects. Vendors may offer multiple options per creative (volume tiers, context-specific rates, different pricing models).

**Account requirements:**

* Creative agents that charge for their services MUST implement the [Accounts Protocol](/docs/accounts/overview). 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

**Schema**: [`creative/sync-creatives-request.json`](https://adcontextprotocol.org/schemas/v3/creative/sync-creatives-request.json) / [`creative/sync-creatives-response.json`](https://adcontextprotocol.org/schemas/v3/creative/sync-creatives-response.json)

**Reference**: [`sync_creatives` task](/docs/creative/task-reference/sync_creatives)

Upload and synchronize creative assets in a library. Implemented by any agent that hosts a creative library — ad servers, creative management platforms, and sales agents that manage creatives.

**Requirements:**

* 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 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

**Reference**: [`get_creative_delivery` task](/docs/creative/task-reference/get_creative_delivery)

Retrieve creative delivery data with variant-level metrics.

**Requirements:**

* 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

Creative agents MUST return errors using the [standard AdCP error schema](/docs/building/implementation/error-handling).

Common error codes:

* `REFERENCE_NOT_FOUND`: Requested format does not exist or is not accessible (`error.field` identifies the `format_id`)
* `VALIDATION_ERROR`: Manifest failed format validation
* `ASSET_MISSING`: Required asset not provided in manifest
* `ASSET_INVALID`: Asset does not meet format constraints
* `GENERATION_FAILED`: Creative generation could not be completed

## Security considerations

### Transport security

All Creative Protocol communications MUST use HTTPS with TLS 1.2 or higher.

### 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

A conformant Creative Protocol agent MUST:

1. Support at least one specified transport (MCP or A2A)
2. Implement `list_creative_formats` for format discovery
3. Return authoritative format definitions only for formats it owns
4. Validate manifests against format specifications
5. Use specified error codes

A conformant Creative Protocol agent SHOULD:

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

A conformant Creative Protocol consumer MUST:

1. Use the `agent_url` from format IDs to identify the authoritative creative agent
2. Validate manifests against format specifications before submission
3. Handle validation errors appropriately
4. Track visited URLs when recursively discovering formats to avoid infinite loops

## Implementation notes

### Response time expectations

Creative agents SHOULD target the following response times:

| Operation Type                           | Target Latency |
| ---------------------------------------- | -------------- |
| Format listing (list\_creative\_formats) | \< 1 second    |
| Library query (list\_creatives)          | \< 1 second    |
| Creative sync (sync\_creatives)          | \< 5 seconds   |
| Preview generation (preview\_creative)   | \< 5 seconds   |
| Batch preview (10 creatives)             | \< 10 seconds  |
| Creative generation (build\_creative)    | \< 60 seconds  |

### Recursive format discovery

Creative agents MAY reference other creative agents in their `list_creative_formats` response:

```json theme={null}
{
  "creative_agents": [{
    "agent_url": "https://creative.adcontextprotocol.org",
    "agent_name": "AdCP Reference Creative Agent",
    "capabilities": ["validation", "assembly", "preview"]
  }]
}
```

Consumers MAY recursively query referenced agents to discover additional formats.

Consumers MUST track visited URLs to prevent infinite loops during recursive discovery.

### Format-aware validation

Manifest validation MUST be performed in the context of the format specification:

1. Look up the format definition from the authoritative creative agent
2. For each asset in the manifest, find the corresponding entry in the format's `assets` array
3. Validate the asset value against the type and constraints defined in the format

The format definition determines what type each asset\_id should be. Asset type information is NOT included in the manifest itself.

### Standard vs custom formats

* **Standard formats**: Based on IAB specifications, hosted by the reference creative agent (`https://creative.adcontextprotocol.org`)
* **Custom formats**: Defined by individual publishers or creative platforms for specialized inventory

Both work identically—the `agent_url` field identifies which agent is authoritative for each format.

## Schema reference

<Note>
  Some creative protocol schemas (`build_creative`, `list_creative_formats`, `preview_creative`) have paths under `media-buy/` because they were originally released as part of the media-buy protocol. The schema paths are stable identifiers and do not affect which protocol the task belongs to.
</Note>

| Schema                                                                                                                                    | Description                      |
| ----------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- |
| [`core/format.json`](https://adcontextprotocol.org/schemas/v3/core/format.json)                                                           | Format definition                |
| [`core/creative-manifest.json`](https://adcontextprotocol.org/schemas/v3/core/creative-manifest.json)                                     | Creative manifest                |
| [`core/creative-asset.json`](https://adcontextprotocol.org/schemas/v3/core/creative-asset.json)                                           | Asset definition                 |
| [`media-buy/list-creative-formats-request.json`](https://adcontextprotocol.org/schemas/v3/media-buy/list-creative-formats-request.json)   | list\_creative\_formats request  |
| [`media-buy/list-creative-formats-response.json`](https://adcontextprotocol.org/schemas/v3/media-buy/list-creative-formats-response.json) | list\_creative\_formats response |
| [`creative/list-creatives-request.json`](https://adcontextprotocol.org/schemas/v3/creative/list-creatives-request.json)                   | list\_creatives request          |
| [`creative/list-creatives-response.json`](https://adcontextprotocol.org/schemas/v3/creative/list-creatives-response.json)                 | list\_creatives response         |
| [`creative/sync-creatives-request.json`](https://adcontextprotocol.org/schemas/v3/creative/sync-creatives-request.json)                   | sync\_creatives request          |
| [`creative/sync-creatives-response.json`](https://adcontextprotocol.org/schemas/v3/creative/sync-creatives-response.json)                 | sync\_creatives response         |