MCP and ad platforms: letting an agent into your ad account
MCP makes it easy to plug an AI agent into Google or Meta ads. Here is how to scope permissions, keep a human in the loop and log every change.
Until recently, connecting an AI model to an ad account meant writing a custom integration for each platform's API, juggling tokens and hoping the model called the right endpoint. The Model Context Protocol changed the plumbing. It did not change the stakes. An ad account is a live wallet with your brand's name on it.
This piece covers what MCP is, what the major ad platforms expose through it today, and how to set up permissions and audit trails before an agent gets anywhere near live spend.
What MCP actually is
Anthropic introduced the Model Context Protocol on November 25, 2024, as an open standard for connecting AI assistants to the systems where data lives. Instead of every app building its own connector to every service, a service exposes an MCP server, and any MCP-compatible client can discover its tools and call them.
It has since outgrown its origin. In December 2025 Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI. For marketers, the practical upshot is that one connector can work across several AI clients instead of being tied to a single vendor.
It is worth being precise about what MCP is not. On its own, it is not a permission system. The protocol describes how tools are listed and called. Who may call which tool, on which account and with whose approval is decided by the server, the client and the platform's own access controls.
What the ad platforms expose today
The two largest ad platforms have taken noticeably different positions.
Google's official MCP server for the Google Ads API is read-only. Its documentation lists tools to see which accounts you can access, run GAQL reporting queries and fetch resource metadata, and states that the server cannot modify bids, pause campaigns or create assets.
Meta went further. When it opened its ads AI connectors in beta on April 29, 2026, external agents could create and edit campaigns, not only read data. AffHouse's guide to what an agent can and can't do through Meta Ads MCP walks through the tools, the permission scopes and an important default: new campaigns, ad sets and ads are created paused, and turning them on is a separate step.
Third-party MCP servers fill gaps for other platforms, and for write access that the official servers do not offer. They can be useful, but each one is another party holding a key to your account.
Permissions: decide in three layers
A clean way to think about agent access is three layers, each narrower than the last.
The first layer is the credential. Grant the smallest scope the job needs, for only the accounts the agent should touch. The MCP project's own security guidance warns that broad scopes granted up front widen the damage if a token leaks and muddy the audit trail. It recommends starting with a minimal set and asking for more only when a privileged operation is actually attempted.
The second layer is the tool list. Even with a write-capable token, a client can expose only read and draft tools to the model. If the agent cannot see a delete tool, nobody can talk it into using one.
The third layer is approval. The MCP specification says there should always be a human in the loop with the ability to deny tool calls, and that clients should ask for confirmation on sensitive operations and show tool inputs before sending them. For an ad account, a reasonable ladder looks like this:
- Read freely: reporting, diagnostics, change history.
- Draft new objects in paused status only.
- Change live spend only with a named approver for each change.
- Never let the agent activate unreviewed ads, delete objects, or touch billing, user roles or policy status.
The risks that are specific to agents
Prompt injection is the risk marketers most often underestimate. An agent that reads ad comments, landing pages, competitor ads or support tickets is reading text written by strangers. If that text contains instructions, a poorly guarded agent may treat them as commands. Keeping confirmations on for every write action is the backstop.
Token handling comes next. The MCP security guidance explicitly forbids token passthrough, where a server accepts tokens that were not issued to it and forwards them downstream. It breaks accountability and lets a stolen token be laundered through the server. On your side, long-lived tokens do not belong in chat windows or shared config files.
Then there are loops. The specification asks servers to rate-limit tool calls, and ad platforms throttle rapid edits anyway. An agent stuck in a retry loop will hit those limits. One that is not throttled can make dozens of changes before anyone looks.
Audit trails: build them before you need them
Platform change history tells you what changed. It does not tell you why, or which prompt led to it. The MCP specification suggests that clients log tool usage for audit purposes. In practice, that means recording the tool, its inputs, the account, the person who approved the call and the model's stated reason for every write.
Give the agent its own identity where the platform allows it, so its changes are distinguishable from a colleague's. Review a sample of the log every week, not only after an incident. And rehearse revocation: know where to disconnect the client and where to revoke the grant on the platform side, because those are often two different places.
MCP makes connecting cheap, which is exactly why the decisions around it now carry most of the risk: scope, tool list, approvals and logs. For ongoing coverage of how performance marketers are wiring these tools into real accounts, see affhouse.org.
