Every ads platform now speaks MCP

MCP (Model Context Protocol) is the open standard that defines how an AI model connects to external tools. Until early 2026, connecting Claude or ChatGPT to a Google Ads or Meta account meant using community-built connectors: GitHub projects where the user pasted an API token by hand, with no official OAuth, no support, and the concrete risk that the platform would read that access as a terms-of-service violation. Those connectors still exist and plenty of people will keep using them, but something fundamental changed: the official path now exists, and staying in the gray zone became a choice.

The sequence was fast. Amazon opened the series on February 2, 2026 with the Amazon Ads MCP Server in global open beta: campaign creation, updates and deletion, reporting, account settings and access to billing data, available to any account with active Ads API credentials.

Google published its server on April 28, open source on GitHub, with the opposite design decision: read-only. Three tools (list accessible accounts, run GAQL queries, inspect resource metadata) built for diagnostics and analysis. It cannot pause campaigns, cannot change bids, cannot create anything. Mutations stay where they were, in the traditional API with the usual process.

Meta arrived one day later, on April 29, with Meta Ads AI Connectors in open beta: a remote MCP server at mcp.facebook.com/ads with 29 read and write tools covering campaign, ad set and ad creation, catalog, budgets, targeting and audience insights. Two governance decisions stand out. First: at connection time, the OAuth dialog offers three permission tiers (read-only, read-write, or read-write with financial access) that the user picks explicitly. Second: everything an agent creates is born paused, and a human activates it. Access is free during the beta.

TikTok announced its server on May 13 at TikTok World: read and write across the full campaign lifecycle (planning, launch, bids, budgets, targeting, optimization). As of this writing it is an announcement: there is no public documentation and no general availability date.

Pinterest and Microsoft Advertising closed the series on the same day, June 17, one week before Cannes Lions, both read-only. Pinterest in alpha with named partners (PMG, Pacvue, Dentsu, Havas, among others), with access to campaign performance, analytics, keywords and its Taste Graph signals. Microsoft in open pilot, aimed at analysis over live campaign data from M365 Copilot, Claude or ChatGPT.

The analysis: three answers to the same question

The aggregate matters more than any individual announcement. Six platforms converging on the same protocol in the same half-year is not a coincidence: it is industry consensus on what the interface of the next stage of advertising operations will be. The debate over whether agents will operate ads accounts is closed. The open question is how much power to give them, and the platforms themselves answered it in three incompatible ways.

Google, Pinterest and Microsoft chose read-only. It is the most conservative stance and the easiest to defend: an agent that can only read cannot burn budget. Google also left a door ajar in its own documentation, which describes the initial version as read-only, suggesting the stance may change.

Meta chose full write with a structural brake. The three OAuth permission tiers and the paused-by-default state encode a concrete answer to the governance question into the product: the agent can build everything, but activation is a human act, and financial access is a separate authorization the user has to grant explicitly.

TikTok and Amazon chose full write across the entire lifecycle, with no equivalent brake publicly documented as of this writing. It is the most aggressive bet, and the one that depends most on the user building their own control layer.

Three permission models for the same problem means no platform has a validated answer yet on how much write access an agent should get. And it means something more uncomfortable: the decision does not come solved out of the box. Every team has to make it, account by account, and the permission tier picked in an OAuth dialog is the mechanism, not the policy.

The second structural change is the status of access itself. Community connectors required pasting tokens into config files, with all-or-nothing permissions. Official OAuth changes the nature of the risk: it removes the risk of a ban for unauthorized access, and it leaves a record of which application accesses with which permission, with a revocation button for the account admin. It does not remove access risk itself: a connection with write permission is still an attack surface if the employee account that authorized it gets compromised. For an operation spending real money, the difference is still not cosmetic: it is the difference between a personal experiment and a tool you can defend in front of a client or a CFO.

The framework worth adopting is the one Meta ended up encoding in its OAuth: unrestricted read for reporting and analysis, write only with explicit human approval, and anything financial as its own category. Platforms offering this officially lowers the cost of entry, but it does not replace the policy decision: that remains the job of the team accountable for the budget.

For a paid media team, this week's action is not delegating operations: it is mapping access. First, audit whether anyone on the team already connected an unofficial connector with a pasted token, and if it exists, migrate it to the official path or shut it down. Second, connect the read-only servers for reporting and conversational analysis, where the risk is low. Third, if you try Meta's write access, start with the read-write tier without financial access, and use the paused state as designed: the agent proposes, a human reviews the full campaign before activating. It is worth being honest about the entry friction: depending on the platform, this may require API credentials that take time to get approved and a compatible MCP client, so the real cost of connecting is measured in hours or days, not minutes, and varies case by case.

The tensions

The speed gain is real but asymmetric. On the read side, the benefit is immediate and the risk near zero. On the write side, the benefit depends on process maturity: a team without review does not gain speed, it gains exposure. And there is a symmetric risk that hits precisely the teams that do have process: if an agent proposes forty paused campaigns a week, human review becomes the bottleneck and degrades into rubber-stamping. Meta's brake works only while the review is real. A paused state is not governance: it is an opportunity for governance.

There is an incentive tension worth facing directly. Platforms make money when more gets spent, and an agent connected with write permissions is the lowest spending friction the channel has ever had. That all three permission stances come from the platforms themselves, not from a neutral third party, is not a detail: the long-term pressure points toward more agent autonomy, not less. Meta's paused default mitigates this today, but it is beta behavior, not a contractual commitment, and no platform has published rollback policies for agent actions. Anyone who needs documented guarantees to defend this in front of a board does not have them yet.

The third tension is about data. When an agent reads an account's performance, that information flows through the AI model provider. For an operation whose audiences contain customer data, the compliance questions (what stays in the provider's logs, which data processing agreements apply, what changes under GDPR or LGPD) have no answers published by the platforms yet. That is a legitimate reason for a regulated company to wait, and an insufficient one for a startup without that data to do the same.

The last tension is timing: all of this is beta, alpha or pilot. Capabilities, limits, permissions and pricing can change in weeks. Building the team's workflow on top of a beta carries rework cost if the platform changes the rules, and this topic ages by the week, not by the quarter.

Who this is for (and who it is not for)

For a small team already using Claude or ChatGPT for analysis, official read access is the immediate win: it replaces the ritual of exporting CSVs and pasting data, with low risk and no hard decisions. Write access, on the other hand, demands a review process that a two-person team rarely has, and without that process Meta's brake is decorative.

For a scaled operation with a dedicated paid team, the value is in the permission map and in designing the policy before the team connects things on its own: define who authorizes connections, at which tier, and how agent-made changes get audited. The questions around multi-account structures and change-history traceability have no clear public documentation yet, which reinforces the order of operations: policy first, connection second.

For a corporate company with procurement and compliance, this is innovation-committee material on a 6 to 12 month horizon, not a quarterly implementation. Nothing launched so far carries contractual guarantees, and the data layer is the first question legal will ask.

This note reads best alongside the analysis we already published on the evolution of the agency model: that note argues why the AI-agentic, human-led operating model is the one that survives; this one documents the concrete infrastructure that makes it possible on the platforms.

What we don't know

Exact regional availability per server is not fully documented: Meta declares a gradual global rollout in beta, Amazon declares a global beta, TikTok published no documentation. There is no specific, uniform confirmation for LATAM.

Post-beta pricing has not been published by anyone. Meta stated access is free during the beta, without defining what comes after.

There are no public benchmarks yet of real savings (reporting hours, operating speed) and no reports of agent incidents in production accounts. The absence of published incidents says more about how new the channel is than about how safe it is.

It is also unclear whether changes executed by agents are identified as such in platform change histories, or how permissions behave in agency multi-account structures. And there is no independent data comparing agent-based operations against manual operations: the practice exists (we run it ourselves), the comparable public evidence does not yet.

*Built with AI. Reviewed by humans. If any data point ages badly, blame the ecosystem, not us.*