Google Ads MCP · hosted OAuth
With NotFair, the operator authorizes an existing Google account and selects accessible ad accounts. NotFair hosts the MCP server and Google Ads API integration, so the customer does not need to create a Cloud project, submit a developer-token application, run Python, or store Google credentials in Claude or Codex.
Last verified · August 21, 2026 · NotFair product team
Two identities, one flow
Self-hosted servers make the operator own both layers. A hosted server separates them: NotFair maintains the application-level Google Ads API integration, while the customer grants scoped access as a Google user.
Use the same Streamable HTTP endpoint in Claude Web, Claude Code, Codex CLI, Cursor, OpenClaw, Hermes, or another compatible client.
The MCP resource advertises its authorization server. Discovery uses the exact apex or www origin requested by the client so the issuer remains byte-for-byte consistent.
The browser-facing flow asks the Google account owner to approve access. Passwords are never pasted into the MCP client.
NotFair lists directly accessible accounts and active client accounts reachable through manager accounts. The user chooses the intended scope.
The client completes its OAuth code exchange and stores its NotFair connection. Platform credentials stay on the hosted service.
Ask the agent to list connected accounts, identify managers and clients, then inspect one campaign before staging any write.
Evidence table
| Responsibility | NotFair hosted MCP | Self-hosted Google Ads MCP |
|---|---|---|
| Google Cloud project | Operated by NotFair | Created and maintained by your team |
| Google Ads developer token | No customer token required | Your team supplies and maintains it |
| OAuth application | Hosted authorization flow | Your team creates credentials and redirect URIs |
| MCP runtime | Remote Streamable HTTP endpoint | Local or cloud process you deploy |
| Account consent | Customer still approves Google access | Customer approves access to your OAuth app |
| Secrets | Platform tokens remain server-side | Your team stores and rotates credentials |
| Updates | Service maintained by NotFair | Your team tracks API and MCP changes |
Limits and honest boundaries
No. NotFair operates the hosted Google Ads API integration. You authorize access to the Google Ads accounts you already have permission to use; you do not create a Cloud project or provide a developer token to the AI client.
No. OAuth proves which Google user is granting access and which accounts that user can reach. A developer token identifies the application calling the Google Ads API. With a hosted service, NotFair operates the application integration while each customer still grants account access through OAuth.
No. The hosted service keeps platform credentials server-side. The MCP client receives the tools and results authorized for its connection, not your Google password or raw platform refresh token.
Yes. The account picker can discover eligible client accounts beneath a manager account. MCP calls can then route explicitly to a selected account ID instead of assuming the manager root contains campaigns.
Yes. The apex origin is canonical for new setup, while both origins remain valid OAuth and MCP resources for backward compatibility. OAuth discovery preserves the exact request origin so RFC 9207 issuer matching succeeds on either hostname.
Continue evaluating
Copy the production URL and see the live read/write tool surface.
Read moreSee what happens after authentication when an agent proposes a change.
Read moreCompare setup ownership, write access, MCC routing, and recovery.
Read more
