MCP for marketers: what the protocol actually changes

Before a standard existed, connecting an assistant to a piece of software meant a bespoke integration per pairing. MCP defines a common interface: in the specification's words, it lets servers expose tools that language models can invoke, with typed inputs and outputs a client discovers. Removing that bespoke integration work is genuinely valuable.

For a media buyer the change in daily experience is that a request in conversation can become a sequence of real operations against real data (compile this audience, show me what it becomes on each channel, produce a plan against this budget) rather than a description of how you would do it yourself.

The protocol itself says nothing about whether the operations behind it are safe, auditable or reversible.

The advertising platforms already expose MCP servers of their own. Meta's and Amazon's can create and change campaigns, and Google's, Microsoft's and Snap's are read-only, according to their own pages checked on 24 September 2026. A vendor whose primary claim is that they have an MCP server is claiming something increasingly ordinary.

The claim worth checking is narrower and more useful: that the agent path and the human path are the same path. If the assistant exercises the same REST routes, the same tenant boundary, the same spending checks and the same approval records as the browser, then pointing an agent at the product does not mean accepting a weaker set of rules. If it exercises a separate, more permissive path, the protocol has made things worse rather than better.

This is the question to put to any vendor pitching agentic media buying, and it is answerable: ask whether the agent surface is a wrapper over the same endpoints the interface uses, or a parallel implementation.

Permissions can be misconfigured. A far stronger guarantee is that an operation has no tool at all, because an agent cannot call something that does not exist in the surface.

In AdBuyMCP eleven consequential operations are deliberately absent from the 105-tool surface and are human-only signed actions, among them resolving an approval, replacing or revoking a mandate, closing a mission, verifying a supplier dossier, and issuing or revoking a live execution grant. An agent that tries to approve its own work is refused, and the refusal says a person has to approve it.

Alongside that, authority is a data structure rather than a setting: a mandate enumerates the allowed actions, the currency, the validity window and a money ceiling, and high-consequence work needs a single-use approval bound to an exact action digest, so a request that does not match the approved bytes fails closed rather than proceeding on the strength of a similar-looking one.

These questions tell a serious agent product apart from a chat window. Does the agent path use the same endpoints as the interface, or a parallel one? Which operations have no agent tool at all? Is authority scoped with an explicit money ceiling and expiry, or is it a role? What happens when a supplier returns an ambiguous response, and is it retried? And are the tool safety annotations presented as enforcement, which would be a bad sign, or as discovery hints with enforcement at the API?

That fourth question is the one that most reliably separates them. An agent that cannot read a supplier's response and tries again has just created a second campaign nobody knows about. The correct behaviour is to stop the run, raise an exception, and require an explicit human resolution before resuming.

The answers are architectural rather than aspirational, which means they can be verified rather than believed.