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: a server exposes tools with typed inputs and outputs, a client discovers them, and the model calls them. It is plumbing, and good plumbing 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.

That is worth having. It is also worth being clear about what it does not touch: the protocol has no opinion about whether the operations behind it are safe, auditable or reversible.

Several advertising platforms already expose MCP capabilities, and the number is rising. A vendor whose primary claim is that they have an MCP server is claiming something increasingly ordinary.

The honest version of the claim is narrower and more useful: not that an agent interface exists, but 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 funding gates 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 seventy-six-tool surface and are human-only signed actions: resolving an approval, resolving a provider attempt, acknowledging a booking-workflow step, resolving an asset job, replacing or revoking a mandate, closing a mission, saving or verifying a supplier dossier, and issuing or revoking a live execution grant. An integration test proves an agent attempting to approve its own work receives a refusal requiring human approval.

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.

Five questions separate a serious agent product 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 — 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.