MCP for ad tech: tools, auth and governance

Every agentic buying standard in ad tech now runs over the Model Context Protocol. MCP is the plumbing that lets an AI agent find and call a publisher’s tools; it says nothing about what a media buy is, which is why AdCP and IAB Tech Lab’s AAMP sit on top of it. This explainer covers what MCP is, the version that is current in October 2026, how both ad standards use it, and what to ask before a buyer’s agent can call a server that books your inventory.

What is MCP?

MCP is an open protocol for connecting AI applications to external tools and data. Messages are JSON-RPC 2.0. There are three parties: a host (the AI application, such as an assistant or an agent runtime), a client inside the host that holds a connection, and a server that exposes capabilities.

Anthropic created MCP. On 9 December 2025 it contributed MCP to the Agentic AI Foundation, a new fund under the Linux Foundation, alongside Block’s goose and OpenAI’s AGENTS.md. The project is now “Model Context Protocol a Series of LF Projects, LLC”. Spec changes go through public Specification Enhancement Proposals (SEPs), and decisions sit with named lead and core maintainers. Governance seats belong to individuals, not companies.

Which version of MCP is current?

MCP versions are dates. The current revision is 2026-07-28, published on 28 July 2026 after a release candidate in May. The one before it was 2025-11-25.

2026-07-28 is a large change, and it matters if you run a server:

MCP is now stateless. The initialize handshake and the Mcp-Session-Id header are gone. Every request carries its protocol version and client capabilities in _meta, and servers must implement server/discover to advertise what they support.
Long-running work moved to an extension. Tasks now live in the optional io.modelcontextprotocol/tasks extension.
Servers no longer send requests to clients. When a tool needs more input, it returns an input_required result and the client retries the call with the answers.
Roots, Sampling and Logging are deprecated, as are the old HTTP+SSE transport and Dynamic Client Registration.

The ad tech stacks sit at different points. AdCP 3.2 publishes compact MCP 2026-07-28 schemas and tells implementers never to derive identity or authority from Mcp-Session-Id. IAB Tech Lab’s seller agent changelog records its Streamable HTTP endpoint against protocol 2025-06-18. The 2026-07-28 spec defines a fallback for older handshake-based peers, but ask every vendor which revision they actually speak.

What are MCP’s building blocks?

Tools

A tool is a function the model can call. Each has a name, a description, an inputSchema (JSON Schema) and optionally an outputSchema, and results can come back as structuredContent that matches it. Tools are “model-controlled”: the model decides when to call them. The spec says there SHOULD always be a human in the loop who can deny a tool call, and that clients MUST treat tool annotations as untrusted unless they come from a trusted server.

In ad tech almost everything is a tool: get_products, create_media_buy, sync_creatives.

Resources and prompts

Resources are data identified by a URI, such as a media kit or a creative spec sheet, and the host application decides how to use them. Prompts are templated messages a user can pick. The ad standards lean on tools far more than on either.

Transports

There are two standard transports. stdio runs the server as a local subprocess. Streamable HTTP sends each message as an HTTP POST to a single endpoint, with replies as JSON or a request-scoped SSE stream. A sales agent that buyers reach over the internet uses Streamable HTTP.

Authorization

Authorization is optional in MCP, but when an HTTP server uses it the rules are specific:

The MCP server is an OAuth 2.1 resource server and MUST publish OAuth Protected Resource Metadata (RFC 9728), which tells clients where to get tokens.
Clients MUST send a resource parameter (RFC 8707) naming the server, and the server MUST check that each token was issued for it.
Servers MUST NOT accept or pass on tokens issued for anything else. The security guidance calls forwarding a client’s token downstream “token passthrough” and forbids it.
Clients should identify themselves with Client ID Metadata Documents; Dynamic Client Registration is deprecated in 2026-07-28.

Why is AdCP built on MCP?

AdCP defines the advertising semantics and leaves the wire to MCP or A2A. Its glossary defines a sales agent as “an MCP server that exposes publisher inventory for discovery and purchase.” Each AdCP task is an MCP tool, the same task schemas also run over A2A, and a sales agent must support at least one of the two.

That split means a buyer’s agent can find and call your sales agent with standard MCP tooling, and AdCP only has to standardise the business objects: products, proposals, media buys, creatives and delivery.

Three AdCP rules sit on top of MCP and are worth knowing:

Buys outlive MCP calls. A create_media_buy can return submitted and wait hours or days for a person to approve it. That status is AdCP application state, not MCP task state, so buyers register a push_notification_config webhook or poll get_task_status.
Auth is tiered. get_adcp_capabilities is always public, product discovery may be, and every mutation needs credentials. In 3.x a Bearer token over TLS is still acceptable for buys; RFC 9421 request signing becomes mandatory for spend-committing operations in AdCP 4.0. AdCP’s own list of limitations says it has no normative OAuth 2.1 requirement, so MCP’s OAuth rules apply only if the server adopts them.
Credentials never go in tool arguments. AdCP tells sellers to reject a request that carries a token or key in its payload with CREDENTIAL_IN_ARGS, because anything in the arguments is visible to the model and its logs.

How does AAMP use MCP and A2A?

IAB Tech Lab’s agentic roadmap (6 January 2026) set out to combine OpenRTB, AdCOM, OpenDirect and the Deals API with MCP, A2A and gRPC, and promised a neutral MCP server. In the AAMP reference code today:

The seller agent SDK serves MCP at /mcp over Streamable HTTP as its primary interface (the README counts 46 tools), plus an OpenDirect REST API. Its A2A page says inbound A2A is “designed, not implemented” in the current release.
The buyer agent SDK uses an MCP client as its primary way to reach sellers, with A2A and REST clients alongside.
The Agent Registry lists both MCP and A2A agents and ties each registering company to its GPP ID.

IAB Tech Lab’s COO, Shailley Singh, states the limit plainly: “MCP is a communication substrate; it does not reconcile their advertising semantics.” AdCP’s FAQ agrees that the two frameworks are “not wire-compatible merely because both support MCP and A2A”. Speaking MCP gets an agent connected; it does not get an AdCP buyer transacting with an AAMP seller. We compared the two standards in AAMP vs AdCP.

What does an ad tech MCP server expose?

A representative slice of each standard’s tool surface:

Job	AdCP sales agent	AAMP seller agent SDK
Who are you?	`get_adcp_capabilities`	`get_config`, `health_check`
What can I buy?	`get_products`, or `list_products` and `request_proposals` in 3.2	`list_products`, `get_pricing`, `request_quote`
Book it	`create_media_buy`, or `buy_products` and `accept_proposal` in 3.2	`create_order`, `create_deal_from_template`
Change and report	`update_media_buy`, `get_media_buy_delivery`	`transition_order`, `get_gam_delivery_report`
Human review	Async `submitted` status and `get_task_status`	`list_pending_approvals`, `approve_or_reject`

The design difference matters. The AAMP seller SDK puts operator tools (approvals, rate cards, API keys) on the same MCP server that buyers call, and separates them with operator and buyer API keys. AdCP defines only the tasks that cross the buyer and seller boundary; how your staff approve a buy is left to the implementation. Either way, check which tools a buyer’s credential can see. Under MCP 2026-07-28, tools/list may vary by the authorization on the request, so a server can hide operator tools from buyers.

For how to model the products behind these tools, see How to make your inventory agent-ready for AdCP.

What should a publisher ask before agents call its server?

MCP’s security best practices and AdCP’s security model cover the main risks. Turn them into questions for whoever runs your sales agent, in-house or vendor:

Which versions? The MCP revision, the AdCP or AAMP version, and the upgrade policy.
Who can call which tool? Separate credentials per buyer, operator tools hidden from buyer credentials, and scopes no wider than the job. MCP’s guidance lists wildcard scopes such as * or full-access as a common mistake.
Are tokens audience-bound? The server should reject tokens issued for other services and never forward a buyer’s token to your ad server or an SSP. It should call Google Ad Manager with its own credentials.
What stops for a human? Which products activate automatically, which wait for approval, and who is notified.
Are retries safe? AdCP requires an idempotency_key on every mutating request, so a timed-out create_media_buy cannot book twice.
What about prompt injection? Briefs, creative metadata and product descriptions are untrusted text. AdCP’s security model calls injection that exfiltrates agent credentials “the most likely near-term breach vector in the space”, and warns about agents that hold credentials for several sellers or brands in one context.
Which URLs will it fetch? Webhook and OAuth metadata URLs come from the other side. Both specs call for HTTPS-only fetching and blocking private and cloud-metadata IP ranges to stop server-side request forgery.
Is every call logged? Caller, inputs, approver and outcome, kept long enough to settle a billing dispute.
Can you stop it? One step to pause or cancel buys and revoke a buyer’s access.

What to do next

Ask your sales agent vendor, in writing, for the MCP revision and the AdCP or AAMP version it implements.
Connect to your own server with a test buyer credential and list the tools it can see.
Set approval rules before you publish the endpoint in adagents.json or the IAB Tech Lab Agent Registry.
If you are deciding where agents should start, read Agents aren’t coming for the auction.

BidCliq builds header bidding and agentic tools for publishers, and our sales agent is verified by AgenticAdvertising.org against AdCP 3.1.

Frequently asked questions

What is the current MCP specification version?

The current revision is 2026-07-28, released on 28 July 2026. It replaced 2025-11-25 and made MCP stateless by removing the initialize handshake and protocol-level sessions.

Who maintains the Model Context Protocol?

Anthropic created MCP and contributed it to the Agentic AI Foundation, a fund under the Linux Foundation, in December 2025. Named lead and core maintainers run it, and spec changes go through public Specification Enhancement Proposals.

Does AdCP require MCP?

No. AdCP tasks run over MCP or A2A with the same schemas, and a sales agent must support at least one of the two.

Can an AdCP buyer agent talk to an AAMP seller agent because both use MCP?

No. AdCP's FAQ says the two frameworks are not wire-compatible merely because both support MCP and A2A, and IAB Tech Lab calls MCP a communication substrate that does not reconcile their advertising semantics.

Is OAuth mandatory for an MCP server?

Authorization is optional in MCP. When an HTTP server uses it, the spec requires OAuth 2.1 with audience-bound tokens and protected resource metadata. AdCP 3.x itself accepts Bearer tokens, mTLS or RFC 9421 signed requests.

About the author

Sharad Yadav

Founder, BidCliq

Sharad Yadav is the founder of BidCliq, a publisher-first ad monetization platform that helps publishers and ad ops teams run header bidding, Prebid and programmatic across display, video, app and CTV. Before BidCliq, he led AdTech and product at GeeksforGeeks, where he built an in-house ads product that doubled programmatic revenue within nine months and an anti-adblock solution that lifted ad yield by 10%. He is a founding member of AdCP.