First impressions of the Advertising Context Protocol (AdCP)

adtechMCPA2AagentsAdCP

I finally spent a little time reading through the AdCP specification, and wanted to crystallise my initial impressions by getting something down on “paper”.

TL;DR

AdCP is a task-first, adtech specific semantic wrapper built on top of general agent protocols (MCP, A2A). It standardises a small set of advertising tasks (e.g. get_products, create_media_buy, sync_creatives) with JSON schemas so agents and platforms can interoperate without bespoke adapters. This makes for publisher led workflows and direct activation easy, but it also constrains agent autonomy and risks collapsing "agentic" flows back into familiar API contracts.

Introduction

The AdCP is a semantic wrapper around MCP and A2A, I won’t go into the details of these protocols here, but in short:

MCP is a standard for the way agents are integrated with tools or more simply external systems such as your calendar, email, weather API etc.
A2A is a protocol for how agents integrate with each other, you can view it as a messaging protocol so agents can delegate to other agents to perform tasks on their behalf.

AdCP provides adtech semantics to both of these protocols and effectively specialises them to the industry.

MCP & A2A are both general communication protocols and allow for the discovery and execution of arbitrary tools/tasks, through a traditional client-server architecture. The following is a simplified example of a what an MCP server can expose as a tool which would allow an agent to fetch a stock price.

{
  "name": "get_stock_price",
  "description": "Get current or stock price for a public listed company.",
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "ticker": {
      "description": "The stock exchange ticker for the public listed company.",
      "type": "string",
      "minLength": 1
    }
  },
  "required": ["ticker"]
}

The key things to note here are that each tool which a server exposes has a name which in this case is get_stock_price, a description which allows the agent to understand what this tool does, and some properties which means the agent knows the arguments this tool expects. In this case we would call this tool in the following manner: get_stock_price("AAPL"). The tool would return the current stock price for Apple, the agent would receive this value into the context window and either do further processing or output this back to the user, depending on what the agent was tasked with.

The MCP protocol is not opinionated about what tools can do in anyway, you as the developer of an MCP server could create any tool; get_fun_emoji, tell_me_a_joke, create_ad_copy etc. The AdCP protocol however defines a set of 9 media-buy tasks (MCP) and tasks (A2A) which they expect AdCP compliant systems to declare, below is an example of create_media_buy, with many fields omitted for brevity.

{
  "name": "create_media_buy",
  "description": "Create a media buy in the seller's platform.",
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "campaign_name": {...},
    "budget": {...},
    "start_date": {...},
    "end_date": {...},
    ...
  },
  "required": ["buyer_id", ...],
}

Hopefully the above gives you a flavour of what I mean by a semantic wrapper, the very general MCP and A2A protocols have been given adtech specific vocabulary and meaning. Now each AdCP compliant system (agent) should expose a specific set of tools, for which the definition (and semantics) are known and agreed upon in the protocol's specification.

Note: the above example is of MCP, the A2A version is very similar but we replace tools with tasks, the payload remains the same, but the envelope changes.

What does AdCP give us which MCP or A2A do not?

My first question was why would we want to take a very general protocol and effectively make it "hardcoded". The beauty of general protocols is that you can build anything your mind dreams up, which has been proven by the success of HTTP which allows for the whole diversity of the web to flourish by providing a way to communicate which is not opinionated about the contents of that communication.

A solid analogy seems that AdCP provides to MCP that which oRTB provided to HTTP.

It is clear that some form of create_media_buy is required, and defining this once inside of the protocol means we will not have each developer creating their own approach:

launchCampaign
run_media_execution
ExecuteMediaCampaign
...

The name being different is not the only problem here. Each payload (the data the tool expects) would also be different across platforms, and the expected next steps of this tool call would also diverge, meaning that your agent would need to know where in the workflow this step appears. A simple example is creative upload, your agent would need to discover if it is part of the launchCampaign tool, or is there a second call needed to the uploadCreative tool.

So in short any platform adhering to the protocol would expose the same tools and tasks and their payload (data they expect) and where they live in the workflow of a media campaign going live would be known and encoded into the protocol, meaning if your buyer agent can get a campaign live with seller A, they can do the same with seller B.

The drawback here is that you lose the expressivity of the underlying transport mechanism (MCP), and you are confined to methods which the protocol maintainers have deemed worthy of implementing. Also the main benefit of AI & LLMs is that they are excellent at working with unstructured data and discovering APIs by reading the specification at runtime and following links to get more information and reasoning about what they should call based on their task. So the primary benefit of the agentic protocol is something which ironically becomes less relevant in the world of agents. This neuters the agent's core strength (reasoning and discovery) and reduces it to a simple executor of a predefined workflow.

Open questions

Is this truly agentic?

The "agentic" promise is that AI can achieve a goal (e.g., "get my new spring campaign live on publisher X with a £50k budget"). The agent would then reason about how to do this, discover the available tools (upload_creative, set_targeting, activate_campaign), and execute a novel plan.

AdCP, seems to pre-define the entire plan. The "tool" isn't a simple building block; it's a massive, high-level command (create_media_buy). This reduces the "agent" to just a glorified API client. It's not reasoning; it's just filling out a pre-defined form. The "agentic" part becomes window dressing on what is effectively a standard REST API call (which is a planned part of the spec). You could argue that there is still quite a bit of benefit of having an standard API (OpenAPI) spec for each player in the adtech ecosystem, which I would argue was more true before the age of LLMs, but now we are in such a place where we could have self discovering APIs and more dynamic software to take away that integration burden yet still allow organisations to provide unique and differentiated product offerings.

What is the role of the DSP?

At first glance the AdCP may disintermediate the DSP. The most obvious agent flow described consists of a buyer and seller agent negotiating a campaign would bypass the DSP and be executed directly in the seller's adserver. The use of the signals protocol to buy an audience would most likely run on the SSP. In both scenarios it is the seller who decides the execution runtime of a product.

The spec mentions an Orchestrator role, which sounds like where a traditional DSP would fit in but for now only Scope3 are mentioned. So it seems as though the DSP role here would change into a strategy / optimisation layer which collaborates with seller agents to run a campaign and gather analytics for reporting and optimisation.

The skeptic may reason that the design of this protocol is more to create new business models for it's originators vs actually improving the ecosystem for advertisers and publishers, but I am reserving judgement for now.

Does AdCP address core industry challenges?

In my view the short answer here is at least for now, no. AdCP is unlikely to make the open web grow in appeal vs walled gardens which is really what the industry should be targeting.

The spec does include elements of trust and seller governance but they effectively piggy back on concepts which already exists such as ads.txt but sprinkled with some AI & agentic language.

Conclusion

The AdCP is an interesting and welcome approach to rethink how advertising on the open web could work in an AI native world. If adopted it could shift the power dynamics towards the sell-side and create an opportunity for direct media buys at scale. At the same time I feel it is not anywhere near ambitious enough, the adoption challenge would be large enough to warrant a more global rethink of how the open web can compete with walled gardens and to build a system from first principles with AI native workflows in mind.

I would like to explore the Signals and upcoming Curation protocols in the coming weeks and hopefully provide a more concrete take on the effects this protocols would have on the industry if adopted.