The nightmare version of this question is vivid: an AI misreads an instruction and a year of campaign history vanishes. The realistic answer is structural, and calmer. A connected agent can read and run your entire Google Ads account at the speed of a sentence — but it holds exactly the capabilities its server exposes as tools, no more. It can delete a campaign only if someone shipped it that power, and whether yours did was decided by the vendor before you ever typed a prompt.
The answer first: it depends on the server's tool list
An MCP-connected AI does not have arms. It has a list of named tools — a query, a campaign update, and so on — and it can only do what a listed tool does. If the server ships a campaign-removal tool, then yes, the AI can delete, gated by whatever approvals your client enforces. If the server does not ship it, the AI cannot delete a campaign any more than it can print a document on your desk. The question to put to any vendor is therefore concrete: which tools, exactly, does your server expose?
What deletion means in Google Ads — and why removed is forever
Google Ads has three statuses for a campaign: enabled, paused, removed. The first two are recoverable states; the third is an ending. Per Google's own help on enabling, pausing and removing campaigns, a removed campaign is stopped permanently and cannot be resumed or restored — reporting data remains viewable, but the campaign, its settings and its accumulated optimisation history are unrecoverable. In the API, the same finality wears a technical costume: setting status to REMOVED is the delete.
That asymmetry — every other change can be walked back, this one cannot — is the entire design problem. It deserves a different class of protection from everything else.
How AdCopilot removes the possibility at the protocol level
As of v2.16.0, hosted connectors are given 54 Google Ads tools: every one
AdCopilot's underlying server implements except the four remove_* tools.
Those four are not hidden or disabled — they are absent from the tool list
your AI client ever sees. An agent cannot call a tool it was never given.
The server then refuses the delete itself, twice over, and neither refusal depends on what the model was told. The tools that set a status — on a campaign, an ad group, an ad, a keyword or an attached asset — accept enabled or paused and refuse REMOVED outright, before any request goes to Google. And every call, through any tool, for any connected product, is checked by the connector first: an argument carrying a REMOVED status, in any letter case, at the top of the request or nested inside it, is refused before it reaches Google. Ask your connected agent to delete a campaign, deliberately, and you get the server's refusal back in the conversation, with the advice to pause instead. The assistant is not being asked to behave; the server will not do it — which is the difference between a safety property and a promise. The full argument for building it this way is in the case for AI that cannot delete, and the wider model in the security overview.
The remaining risk surface, honestly sized
No delete tools does not mean no risk. It means the risk that remains is bounded and recoverable, and it is worth naming plainly:
- A wrong pause. Approved in haste, a healthy campaign stops delivering until re-enabled. Cost: the hours it sat paused.
- A wrong budget or bid change. Spend shifts until you notice and revert. Cost: bounded by the size of the change and your reaction time.
- An unwanted addition. A keyword or asset you did not want, created paused or live. Cost: pausing it.
Every item on that list is undone with the same class of action that caused it, using change history to find it and flip it back — the full mechanics are in can AI changes be undone. What is absent from the list is any entry reading "gone forever". That is the entire point of the design: risk did not vanish, it changed species, from permanent to recoverable — and recoverable risk is the kind that approvals, logs and habit are actually good at managing.
How to audit any tool's delete capability before connecting
Four checks, five minutes, no trust required:
- Ask the vendor for the tool list. A written inventory of exposed tools, with the delete answer explicit. Refusal to publish one is an answer too.
- Ask the agent itself. Once connected, "list your available tools"
returns ground truth — look for
remove_ordelete_prefixes. - Try it, once, deliberately. Ask it to delete a test campaign. You want a refusal from the server, not a compliant approval prompt.
- Check where enforcement lives. "The AI is instructed not to" is a prompt rule; instructions lose to confusion and injection. Server-side refusal is architecture.
The worst-case walkthrough
Assume everything goes wrong that can: the agent misunderstands you, you approve without reading, and the change is bad. Through a connector with no delete tools, that sequence ends with a campaign paused or a budget moved — visible in Google's change history with a timestamp, attributed to your sign-in, put back in one action. The same sequence through a tool that ships delete ends, at its worst, with something permanent. Choose the failure mode before you choose the tool, and the vivid version of this question stays hypothetical.
The four checks above cost five minutes against any vendor — start free and run them against AdCopilot first, deliberate delete request included.