NotFairNotFair

Google Ads MCP · safety architecture

A write is not safe just because it has a confirmation button

Production safety is a lifecycle: inspect the current state, show the exact proposed change, bind execution to explicit approval, record provenance, measure what happened, and preserve a reversal path where Google Ads supports one.

Last verified · August 21, 2026 · NotFair product team

The NotFair write contract

Six checkpoints from prompt to reversal

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.

  1. 01

    Inspect live state

    The agent reads the target account, current value, recent performance, and freshness metadata before recommending a mutation.

  2. 02

    Prepare an exact operation

    The proposal identifies the account, entity, intended value, and the tool that would execute it. Ambiguous account targeting is resolved before the write.

  3. 03

    Apply server-side limits

    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.

  4. 04

    Wait for explicit approval

    The client surfaces the proposal. Execution begins only after the user approves the staged operation.

  5. 05

    Record and verify

    The result includes an operation or change identifier and is recorded with provenance. A follow-up read can verify the new state.

  6. 06

    Review impact or reverse

    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

What each safety control prevents

ControlWhat it protects againstWhat the operator sees
Explicit account routingReading or mutating the wrong MCC clientNamed account and account ID before action
Typed operationsInvented fields, invalid GAQL-shaped writes, and ambiguous mutation intentA documented tool with validated arguments
Server-side guardrailsModel compliance failures and changes outside accepted limitsA rejection with the violated boundary
Approval gateSilent or autonomous spend changesThe exact staged operation before execution
Operation provenanceUnattributed changes and weak incident reconstructionOperation ID, author context, timestamp, result
Impact reviewLeaving a harmful change in place because nobody checkedBefore/after evidence and a recommended next step
Undo metadataGuessing the old value during rollbackThe stored inverse where exact reversal is supported

Limits and honest boundaries

  • Approval reduces accidental execution; it does not make a strategically bad recommendation good.
  • A before/after comparison is evidence, not automatic proof that the change caused the outcome.
  • Some platform operations are not exactly reversible. NotFair surfaces that limit instead of manufacturing an undo claim.
  • Google Ads policy, permissions, API limits, and account-level restrictions still apply after approval.

Frequently asked questions

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.

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.

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.

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.