v3 Preview Limitations

Availability and compatibility

v3 is available to every authenticated Buyer and Seller Account.
v2 remains the stable default and is not deprecated.
v3 is intentionally an agent-facing MCP contract, not a REST-version replacement. /api/v3/documents is limited to authenticated exact reads and downloads of approved public immutable agreement revisions. Discovery, comparison, private documents, and governing-agreement selection are not yet REST resources; other integrations should continue to use the stable v2 REST APIs.
The unversioned buyer and seller MCP aliases continue to resolve to stable v2.
Organisation accounts currently provide navigation and shared tools, not an organisation-specific noun catalog.
The active account still determines which buyer or seller catalog appears.

get_status and switch_account remain available in an unclassified account so a session can orient and move to a Buyer or Seller Account. No domain catalog is implied by a successful connection to an unclassified account.

Buyer limitations

The Buyer surface supports advertiser and campaign authoring, creative management, proposal requests, media-buy staging, and explicit campaign launch. The following gaps remain:

Capability	Current behavior
Creative generation	v3 can save and attach a finished creative, including audio, but it does not generate or revise the content. Generate externally and hand off the approved asset.
End-to-end workflow orchestration	v3 exposes the typed buying tools; the integrating application or its external agent owns durable workflow state, retries, and human checkpoints. There is no hosted end-to-end orchestrator in the preview.
Buyer-agent orchestration	External buyer-agent identity, credentials, exact advertiser access, and machine-notification administration are available through the buyer console and stable v2 API. A public v3 `buyer_agent` noun and hosted runtime are not in the current v3 catalog; treat them as unavailable until advertised by `tools/list`.
Campaign cancellation	`desiredPhase: "canceled"` is not implemented; use v2
Campaign restore	`isArchived: false` restores an archived campaign as a draft: its media buys were retired when it was archived, so inventory must be staged again before launch
Campaign autonomy	Accepted for forward compatibility but not persisted
Clear campaign brief or flight	`null` is currently a no-op, not a clear operation
Proposal evaluation policy	Instructions and policy fields are recorded but not applied to ranking
Media-buy creation flight	Stage first, then update the draft by `mediaBuyId`
Media-buy top-level budget	Creation: use `products[].budget`. Update: `budget` is accepted on a draft with one line item; a multi-line draft takes `products[].budget` per line item
Adding a product to a staged buy	Not supported by the update path; stage a new media buy (or archive the draft with `isArchived: true` and stage again)
Same product staged twice on one buy	Each line item on a media buy read carries a `lineItemRef`; pass it as `products[].lineItemRef` to change or remove exactly that line item. Without it, an update to a repeated product is refused as ambiguous
Changing a line item’s pricing option	Draft only. `products[].pricingOptionId` must be one of the product’s published options; moving to a fixed-price option clears a stale bid unless `bidPrice` is sent in the same call
Media-buy archive	`isArchived: true` archives a draft only; a dispatched buy is cancelled through the campaign or the v2 update contract
Media-buy restore	`isArchived: false` is not supported; an archived buy is retired for good
Buyer media-buy archive state	Reads currently project `isArchived: false`; use v2 when authoritative archive state is required
Proposal evidence on media-buy reads	Preserve `proposalSource` from the acceptance response; later Buyer reads do not include it
Tracked campaign adoption	Use the existing v2 adopt or duplicate workflow
Tracker delivery and rendered preview	Advertiser and campaign tracking configuration, inheritance, and headless `test_creative_macros` reports are available; attaching effective trackers to outbound creatives and rendering the report inside creative review remain follow-up work

Launching is supported, but only as a separate, two-call update to an existing campaign: a preview with desiredPhase: "active" and no confirmLaunch returns the campaign revision and what would launch; the confirm call sends confirmLaunch: true with that expectedRevision. Both calls require their own idempotencyKey. See Launch a campaign with explicit confirmation. A failed launch may report a partial write because downstream execution state was attempted. Re-read before retrying.

Seller limitations

Every Media Company account can use save_advertiser, save_campaign, save_creative, save_creative_collection, request_proposals, and save_media_buy directly from its Seller account. Sandbox Advertisers are available to every Media Company. Live Advertisers and campaigns are available only to organizations enrolled in the amc-campaign-management rollout. Every operation is pinned server-side to that company’s own Storefront. A missing, foreign, or wider Storefront, Proposal, qualified Product, or existing MediaBuy scope is rejected before dispatch.
Integrated search/get can list and read authorized sandbox or live Advertisers, scoped Campaigns, Creative, Creative Collections, Proposals, and buyer-side MediaBuys. get(kind: "seller", id, advertiserId, include: ["products"] ) opens the company’s own wholesale catalog, so callers can pass qualified Products directly to save_media_buy without requesting Proposals. When a Product advertises signal_targeting_options, its eligible Signals can be selected through products[].targetingOverlay.
The live rollout changes account access only. Live campaign launch still requires ordinary source currency compatibility, account mapping, publisher authorization, creative approval, funding, standing, and any seller-side approval. No sandbox or publish-validation bypass applies to live traffic.
Seller search(kind: "media_buy", filter: { campaignId }) or filter: { advertiserId } selects the integrated Buyer projection. Omitting both selects the Seller inventory/execution projection.
Seller Accounts use the left rail to move between Inventory, Advertisers, Buyers, and Agents. Setup progress appears on Inventory. Advertisers lists the account’s sandbox Advertisers, plus live own-supply Advertisers once the account is enrolled in amc-campaign-management; selecting an Advertiser opens its Campaigns, Creatives, and Reporting work. Campaign creation and delivery requests stay in Murph so the same V3 own-supply guards apply. Buyers lists external AdCP counterparties separately; selecting one shows media buys, synced creatives, and Delivery on your inventory for that relationship, plus its account admission case when setup needs attention. Advertisers uses the shared buyer advertiser picker and work rail for the accounts the seller operates; protected System accounts are read-only. Marketplace, Connections, Buyer Setup, and unbound production Advertisers are not part of this preview.
Shared Page hydration permits only three Seller-key Buyer REST reads: the Advertiser roster (sandbox by default; live only when enrolled in amc-campaign-management), Campaign listing for an explicitly bound Advertiser in either environment with wider-supply rows removed, and that Advertiser’s promoted Creative list in read-only mode. Buyer REST detail, mutations, and reporting remain unavailable to Seller keys.
Portable callers can use get_delivery({ report: "campaign_delivery" }) with explicit metrics, dimensions, a date range of at most 90 inclusive days or range: { lifetime: true }, and optional advertiser, campaign, or media-buy filters. A packageId filter requires a bounded date range (not lifetime), because the reporting operation fetches all campaign data before filtering by package. Integrated Media Companies must name an own-supply advertiser, campaign, or media buy.
Some credential, payout, approval, retry, and reassignment work intentionally remains in Pages rather than model-authored tools.
save_media_kit remains for compatibility but is deprecated; new clients should author Listing identity through save_seller’s listing field. get/save_media_kit’s deprecated kind/field is now canonically spelled listing, with media_kit/mediaKit accepted as deprecated aliases for the same handler.
Seller delivery is seller-reported. It is not Buyer measurement and does not establish billing eligibility by itself.

Catalog and host differences

The runtime catalog may be narrower than the tables in these docs because of account kind, permissions, feature rollout, and MCP App visibility. A principal that can reach both Buyer and Seller Accounts instead receives their deduplicated union at connection time, so hosts that cache tools/list retain both workflows after an account switch. Tools remain authorized only for the selected account. Always use tools/list and get_status for the active account. After switch_account, clients should process notifications/tools/list_changed and call get_status again. A stale tool call fails with typed wrong-account guidance rather than crossing the account boundary.

Payload, connection, and timing limits

Structured responses over 200 KB are truncated as a safety backstop.
One MCP connection is held open for at most 30 minutes; reconnect with the existing session when the client uses sessionful MCP.
A single tool call is also limited to 30 minutes.
Deploys can close connections and eventually interrupt long in-flight calls.
request_proposals durably schedules the full eligible cohort. Each background seller attempt has a 30-second bound; terminal result pages carry at most 50 seller outcomes and at most five bounded product projections. Product-heavy sellers continue on the returned cursor. Diagnostic pages carry at most 100 sanitized outcomes.
A returned productQueryId stays stageable while the buyer deliberates. The discovery-analytics sweep marks a product query inactive after 60 minutes without activity (DISCOVERY_SESSION_INACTIVITY_MS, an infrastructure setting), but save_media_buy reopens such a query on first use, so a long deliberation does not lose the offer. A query that was already executed or replaced is refused with PRODUCT_QUERY_EXPIRED; call request_proposals again. A quoted proposal expires at the seller’s own validUntil or after 90 days, whichever comes first; PROPOSAL_EXPIRED names which window lapsed.
Seller delivery ranges are inclusive and limited to 90 days.

Long-running work should use an asynchronous workflow where one is available instead of holding a single MCP call open.

Direct-client model usage

Interchange can observe API calls, server-side model calls, and Murph-hosted turns. It cannot observe the input/output token usage or model cost incurred by an external MCP client’s own model. Integrators remain responsible for that client-side budget and telemetry.

Choosing v2 or v3

Use v3 when:

an account-resolved MCP surface is useful;
the required workflow appears in the current tool catalog; and
the documented preview gaps do not require a v2 continuation.

Use v2 when:

the integration requires a stable production contract or REST;
the workflow is listed as incomplete above; or
migration would remove a capability the integration already depends on.

No migration is required. A client may keep v2 while evaluating v3 through a separate connector.

Start building

Understand v3

Build workflows

Shared reference

v3 Preview Limitations

Availability and compatibility

Buyer limitations

Seller limitations

Catalog and host differences

Payload, connection, and timing limits

Direct-client model usage

Choosing v2 or v3

​Availability and compatibility

​Buyer limitations

​Seller limitations

​Catalog and host differences

​Payload, connection, and timing limits

​Direct-client model usage

​Choosing v2 or v3

Availability and compatibility

Buyer limitations

Seller limitations

Catalog and host differences

Payload, connection, and timing limits

Direct-client model usage

Choosing v2 or v3