Skip to main content
If your product creates advertising content and also needs to buy media, it can bring a finished creative from its own pipeline or, when available, use a connected creative engine to build one. Both paths should meet at the same handoff: durable assets, a creative manifest, an exact approved version, and the campaign that will use it. Connect the application—or a buyer agent it operates—to Apostra for the buying loop. Apostra is the multi-seller transaction layer; it is not necessary to build and maintain a separate adapter for every seller. This page describes ways to compose a buying workflow. It does not treat every MCP client as a buyer agent. Claude or ChatGPT can call the same tools in an authorized user’s interactive session without becoming software installed in the buyer organization.

​
An MCP client is not automatically a buyer agent

Registration is about durable software identity and governance, not which V3 calls the software makes or how intelligent it is. If a user tells Claude what to buy and Claude calls V3 under that user’s connection, they are using an agent-assisted Apostra workflow. They have not built or installed a buyer agent. Register an external buyer agent only when the software needs an identity, authority, and lifecycle separate from a human’s interactive session. “Light” and “heavy” are useful implementation descriptions, not product identity classes. A light agent may keep only durable workflow checkpoints and Apostra object/report references; a heavier runtime may also orchestrate creative pipelines and external data tools. Either becomes a buyer agent only through the registered-principal boundary above. Your MCP client, application, or registered buyer agent should call the single Apostra V3 MCP endpoint. It should not call each seller independently or recreate seller-specific commercial, authorization, execution, and reporting adapters underneath Apostra.

​
Creative Engines and existing creative

Creative Engines is Apostra’s AdCP-based creative integration. An engine declares its supported generation and transformation capabilities; models and provider-specific controls belong to those declarations. The backend preview lets enrolled Buyer Accounts discover registered engines and manage their connections. The Creative Engines Page is available in interactive MCP Apps hosts; V3 generation-session tools are not included in this preview. The existing generative creative workflow uses campaign-scoped sessions to generate, inspect, refine and finalize a selected output. Where your account and client expose those V2 tools, use that workflow. A catalog entry alone does not establish that a capability is usable in your session or that its funding is configured. You can also create with your own provider or tools and bring the finished creative into Apostra. Upload and save_creative remain ordinary import operations. They do not require an Apostra connection to the tool that made the asset. Generic MCP connection management and a customer-defined pipeline editor are not part of Creative Engines.

​
What is available now

v3 is MCP-only. If your server requires REST rather than acting as an MCP client, use the stable v2 REST API against the same Apostra account data.

​
Application, agent, or both?

For a production product today, use a hybrid architecture:
  1. Let an application-controlled durable store own IDs, idempotency keys, retries, customer approvals, workflow checkpoints, and immutable Apostra report references. A buyer agent may drive those checkpoints, but one model turn should not be their only record. Keep canonical delivery facts, aggregation, and reporting results in Apostra instead of building a second reporting warehouse in the orchestrator.
  2. Use an agent for judgment-heavy steps such as turning a goal into a brief, comparing proposals, explaining tradeoffs, and suggesting an allocation.
  3. Require an explicit application-controlled confirmation before the save_campaign call that makes a campaign active.
Pure application orchestration is a good fit when every transition is deterministic. An interactive Claude or ChatGPT connection is a good fit for a human-guided workflow and requires no buyer-agent registration. A registered, customer-operated external buyer agent is appropriate when the software must continue independently with its own identity, grants, lifecycle, and machine notifications. All three use the same V3 buying tools; Apostra remains the execution layer. Do not rely on one long model turn to own the workflow. Proposal requests, creative reviews, and delivery happen asynchronously. Persist the returned advertiser, asset, creative, campaign, proposal, product-query, media-buy, and revision identifiers in an application or agent control plane, then resume from fresh get and search results. A future hosted buyer agent can provide that control plane without becoming a second reporting warehouse.

​
Example: AI-created radio spot to media buy

The following example uses a finished radio creative with V3 buying tools. A user can drive it interactively from Claude, an application can encode it deterministically, or a registered external buyer agent can run it under its own grants. The buying calls are the same; identity, durability, and governance are not.
  1. Create the spot. Use an eligible audio engine through the existing V2 creative-session workflow, or your own provider outside Apostra. Retain the selected master and its provenance. Engine discovery and connection setup alone do not create the audio. V2 sessions require a draft campaign; select or create it before generation and reuse it in step 3.
  2. Collect customer content approval. Record who approved which immutable creative version. This is your product’s approval and does not replace a seller or ad-server creative review.
  3. Open the buying workspace. Call get_status, create or select the advertiser, and use save_campaign to create a draft with the brief, flight, and budget.
  4. Discover suitable inventory. Call request_proposals, poll the same execution to a terminal result, follow every result cursor, and present the returned proposals or products. Preserve qualified IDs exactly.
  5. Prepare the delivery-ready rendition. Check the selected product’s accepted formats. If the approved master does not already satisfy them, create a compliant rendition outside Apostra and approve that exact version. Attach its HTTPS URL or supported inline data URL with save_creative, using assetType: "AUDIO".
  6. Stage the buy. Call save_media_buy with the selected qualified proposal or product identities and allocation. This creates draft buying state; it does not spend or launch.
  7. Review readiness. Use get on the campaign and media buys, including creative detail where offered, or open open_campaign_receipt in an MCP Apps host. Resolve format, creative-review, funding, or seller-readiness blockers before launch.
  8. Confirm and launch. Preview save_campaign with desiredPhase: "active" and an idempotency key, show the returned budget, flight, and staged buys to the authorized user, then send a second call with confirmLaunch: true, the returned revision, and its own idempotency key.
  9. Report. Query get_delivery for explicit date ranges, metrics, and dimensions. This is seller-reported delivery; it is not independent buyer measurement or proof of billing finality.
If the product insists on creating and approving the finished spot before inventory selection, treat that file as a master. Inventory can impose a different duration, codec, bitrate, channel layout, or other format constraint, so the workflow may still need a destination-ready rendition and a second approval before attachment.

​
Keep the approvals separate

Never infer one decision from another. In particular, a customer-approved spot can still fail destination format validation or seller review, and a staged media buy is not evidence that the campaign has launched.