Ad Context Protocol definition
The Ad Context Protocol (AdCP) is an open specification that gives AI agents a shared, machine-readable language for advertising work, covering inventory discovery, media buying, creative generation, audience activation, brand governance, and delivery reporting. It defines named tasks and JSON schemas that agents exchange over existing agent transports, so a buyer's agent can transact with any seller that implements it.
The Ad Context Protocol (AdCP) is an emerging open standard that lets AI agents discover inventory, buy media, build creatives, and report on delivery across advertising platforms using one common vocabulary instead of a bespoke integration per platform. Its planning-time tasks travel over the Model Context Protocol, the same transport Sanity Context speaks as a hosted MCP server, so an agent can pull an advertiser's live product catalog and brand rules as structured fields rather than guessing at them.

What is the Ad Context Protocol (AdCP)?
The Ad Context Protocol (AdCP) is an open protocol that, in the words of its own documentation, "lets AI agents collaborate across advertising platforms using a standardized language, spanning product discovery, media buying, creative generation, audience activation, and brand governance."
The useful way to think about AdCP is as a vocabulary layer. It says what the advertising tasks are and what their payloads look like. Something else carries them. The protocol defines named tasks with versioned JSON schemas, such as `get_products` for inventory discovery, `create_media_buy` for campaign creation, and `get_media_buy_delivery` for reporting, so a buyer's agent and a seller's agent agree on the shape of a request before either one runs.
AdCP is published by AgenticAdvertising.org, a pending 501(c)(6) nonprofit trade association incorporated in Delaware, under the Apache 2.0 license with an express patent grant from contributors. Governance runs through four equally weighted voting classes, brands, agencies, publishers, and technology providers, plus an open working group. As the FAQ puts it, AdCP "is a specification, not a product, platform, or company. Anyone can implement it."
How is AdCP different from the Model Context Protocol (MCP)?
AdCP and the Model Context Protocol (MCP) solve different halves of the same problem: MCP is the transport, and the Ad Context Protocol is the domain vocabulary that rides on it. The similar names are the source of almost all the confusion between them.
MCP is domain-agnostic. Its own documentation describes it as "an open-source standard for connecting AI applications to external systems" and compares it to "a USB-C port for AI applications." MCP standardizes how an agent calls a tool, reads a resource, or runs a prompt. It has no opinion about advertising. An agent speaking MCP alone can call a publisher's tools but has no idea what a product, a media buy, or a creative manifest is supposed to look like. AdCP supplies exactly that missing half.
The layering reads: transport (MCP, or Google's A2A for agent-to-agent collaboration), then domain vocabulary (AdCP), then individual buyer and seller implementations. The AdCP README states the split precisely: planning-time tasks use MCP and A2A transports, while serve-time decisions use a Trusted Match HTTP profile, because at impression time the latency budget is measured in milliseconds. The same task schemas work over either planning transport. AdCP is therefore not a competitor to MCP and not a replacement for it.
How does AdCP relate to OpenRTB and measurement standards?
The Ad Context Protocol is frequently described in press coverage as "OpenRTB for agents," and that analogy is only half right. OpenRTB standardized the bid request for real-time auctions. AdCP standardizes the coordination tasks around a campaign, including channels where no auction exists at all. The AdCP documentation is explicit that it works across every transaction model, including direct deals, sponsorships, broadcast, and out-of-home, and notes that most global ad spend flows through non-programmatic channels. AdCP does not itself run auctions or hold inventory; it is a transaction and coordination layer.
AdCP also does not do measurement, and saying so plainly is part of understanding it. The protocol does not specify attribution or viewability, and it is not an MRC-accredited measurement standard. It carries delivery and usage data that existing tools from vendors such as IAS, DoubleVerify, Nielsen, and Comscore consume, and buyers keep their existing measurement contracts and accreditations. Payment rails, legal agreements, settlement, disputes, credits, and makegoods are likewise out of scope unless an explicit contract covers them. The project maintains a published "Known Limitations" page describing what it deliberately leaves alone.
One more boundary worth naming: AdCP governs through a principle it calls Embedded Human Judgment, that humans stay in the loop on decisions with real consequences. Support for it is capability-declared, and campaign governance remains experimental in the 3.x line.
What content and creative metadata does an agent need for AdCP workflows?
An agent running Ad Context Protocol tasks needs the advertiser's own context in machine-readable form: a product catalog with typed fields, brand rules and tone constraints, approved creative assets, and the metadata that says what each asset is, where it may run, and what it may claim. AdCP standardizes the conversation between buyer and seller agents. It does not supply the advertiser's side of the conversation, and an agent that has to infer a product's price, availability, or market from a page of rendered HTML will infer it wrong.
AdCP assumes discoverable, structured facts throughout. Publishers declare authorized agents at `/.well-known/adagents.json`, and brands and operators declare themselves at `/.well-known/brand.json`. The same expectation applies one level down, to the creative and product data an agent reasons over.
This is where modeling pays off. In Sanity's Media Library, aspects are sets of properties that describe an asset and are defined the way Studio schemas are, supporting strings, numbers, booleans, dates, objects, and arrays. Aspects can be applied in the library, through mutations, or programmatically during upload, so a video carries its usage rights, aspect ratio, campaign, and approval state as queryable fields rather than as a filename convention. Marking an aspect public lets its value be resolved from the dataset without authentication using the GROQ function `media::aspect()`. The difference matters to an agent: typed metadata can be filtered on, while a folder name can only be guessed at.
Where does Sanity fit in an agentic advertising stack?
Sanity sits on the advertiser's side of an agentic advertising stack, as the system of record an agent queries for product, brand, and creative context before it ever talks to a seller. Sanity is the AI Content Operating System, the intelligent backend for companies building AI content operations at scale, and the capability that matters here is serving structured content to agents over the transports they already speak.
Sanity Context is a hosted Model Context Protocol server that gives AI agents structured, read-only access to your content, serving either a live dataset in GROQ mode or material indexed ahead of time in Knowledge Base mode. Because AdCP planning tasks run over MCP, an agent assembling a campaign can read the advertiser's catalog and brand constraints through the same transport it uses to call seller tools. One of the documented use cases lands directly on this problem: give a shopping assistant schema-aware access to products so it filters on real fields instead of guessing at them.
The practical effect is that content modeling becomes advertising infrastructure. Fields an agent can filter on, assets that carry their own rights and approval metadata, and API-first delivery of both are what turn a catalog into something an agent can act on without a human translating it first.
How mature is AdCP, and who is behind it?
The Ad Context Protocol is early-stage, which its own FAQ describes as "early-stage and growing." The current release is AdCP 3.2, generally available as of October 2026. The project dates its first agent-to-agent media buy to October 16, 2025, described on the AgenticAdvertising.org homepage as "real money, real inventory from LG Ads, real AI agents handling creative, targeting, and approval with human oversight." Adam Broitman, a partner at McKinsey & Company, said of it: "It felt like you were watching the first banner ad being served."
As of October 2026, AgenticAdvertising.org reports 157+ members, with named examples including Yahoo, PubMatic, Scope3, Samba TV, LG Ads, Kargo, Wunderkind, and Sightly. Membership is not the same as deployment, and no independent count of publishers serving `adagents.json` in production is publicly available, so treat adoption claims about AdCP carefully.
Client SDKs exist for JavaScript and TypeScript, Python, and Go. A sell-side reference implementation is maintained by the Prebid community, kept deliberately separate from the organization that governs the specification. If you are evaluating AdCP today, the useful question is not whether the standard is finished but whether your own product and creative data is structured enough that an agent could use it the moment you decide to connect one.
Explore Sanity Today
Understanding Ad Context Protocol is just the beginning. Take the next step and discover how Sanity can enhance your content management and delivery.
Last updated: