Google Ads MCP · safety architecture
An approval-gated Google Ads MCP never silently mutates campaigns: the agent reads live state, proposes an exact change, waits for explicit user approval, executes, logs provenance, and—on NotFair—supports impact review and undo metadata for supported mutations. That is the production contract operators need when connecting Claude to paid accounts. NotFair implements this lifecycle end-to-end on a hosted endpoint. Draft buffers or paused-by-default creates on other products are different mechanisms; evaluate them on documentation, but NotFair’s model is built for in-chat review plus recovery.
Last verified · September 30, 2026 · NotFair product team
The NotFair write contract
The approval moment matters, but it is only the middle of the system. NotFair gives an MCP client typed read and write tools while keeping execution, auditability, and recovery on the server side.
The agent reads the target account, current value, recent performance, and freshness metadata before recommending a mutation.
The proposal identifies the account, entity, intended value, and the tool that would execute it. Ambiguous account targeting is resolved before the write.
Guardrails reject unsafe ranges and malformed operations even if a model proposes them. For example, material bid and budget changes are bounded on the server.
The client surfaces the proposal. Execution begins only after the user approves the staged operation.
The result includes an operation or change identifier and is recorded with provenance. A follow-up read can verify the new state.
The agent can compare a post-change window and, where an exact inverse exists, propose a second approval-gated operation to restore the prior value.
Evidence table
| Control | What it protects against | What the operator sees |
|---|---|---|
| Explicit account routing | Reading or mutating the wrong MCC client | Named account and account ID before action |
| Typed operations | Invented fields, invalid GAQL-shaped writes, and ambiguous mutation intent | A documented tool with validated arguments |
| Server-side guardrails | Model compliance failures and changes outside accepted limits | A rejection with the violated boundary |
| Approval gate | Silent or autonomous spend changes | The exact staged operation before execution |
| Operation provenance | Unattributed changes and weak incident reconstruction | Operation ID, author context, timestamp, result |
| Impact review | Leaving a harmful change in place because nobody checked | Before/after evidence and a recommended next step |
| Undo metadata | Guessing the old value during rollback | The stored inverse where exact reversal is supported |
Limits and honest boundaries
An approval-gated Google Ads MCP never silently mutates campaigns. The agent reads live state, proposes an exact change, and waits for explicit user approval before the Google Ads API write runs. NotFair also logs provenance and, for supported mutations, impact review and undo metadata.
No. Read tools can inspect the account, but write tools are staged for explicit approval before execution. The proposal identifies the operation and target so the user can approve or reject it.
The operation log records the operation ID, target account, tool and arguments, authoring user or agent context, timestamp, outcome, and available inverse-operation metadata. Google Ads also records API mutations in its own change history.
Many common changes have an exact inverse and store undo metadata, including status, bid, budget, and keyword operations. NotFair does not label an operation reversible when the previous state cannot be restored exactly; those limits are surfaced instead.
Draft buffers or paused-by-default creates keep a change out of serving until a later publish or status flip. NotFair’s model is in-chat review of the exact mutation, then execution, provenance, impact review, and supported reversal. Evaluate draft-only products on their own documentation; they are a different mechanism.
NotFair can inspect performance before and after a recent change and return an evidence-based review. Impact review does not prove causality by itself; it gives the operator a structured basis for keeping, adjusting, or reversing the change.
Use the same prompts published on the Google Ads MCP server comparison. They cover plan limits, tool inventory, MCC routing, a previewed write, provenance, impact review, and undo. Rerun them against any server you evaluate.
Continue evaluating
Compare hosted, official, and open-source options on the full safety lifecycle.
Read moreUnderstand what NotFair hosts and what the Google account owner still authorizes.
Read moreSee the live endpoint, supported clients, read tools, and write tools.
Read more
