Google Ads MCP · hosted OAuth
Connect Google Ads to an AI client without building an OAuth app
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
OAuth identifies the user; the hosted integration identifies the app
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.
- 01
Add the hosted MCP URL
Use the same Streamable HTTP endpoint in Claude Web, Claude Code, Codex CLI, Cursor, OpenClaw, Hermes, or another compatible client.
- 02
The client discovers OAuth metadata
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.
- 03
Sign in and authorize Google
The browser-facing flow asks the Google account owner to approve access. Passwords are never pasted into the MCP client.
- 04
Choose eligible ad accounts
NotFair lists directly accessible accounts and active client accounts reachable through manager accounts. The user chooses the intended scope.
- 05
Return to the AI client
The client completes its OAuth code exchange and stores its NotFair connection. Platform credentials stay on the hosted service.
- 06
Verify with a real read
Ask the agent to list connected accounts, identify managers and clients, then inspect one campaign before staging any write.
Evidence table
Hosted OAuth versus self-hosting
| 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
- The Google user still needs legitimate access to the ad accounts they select.
- Hosted OAuth removes customer infrastructure work; it does not bypass Google Ads permissions, policies, or API restrictions.
- Claude, Codex, and other clients may present their connector settings differently even though the remote MCP URL is the same.
- The apex endpoint is canonical for new connections; www remains supported so existing OAuth grants and connectors keep working.
Frequently asked questions
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
Related evidence
Google Ads MCP endpoint
Copy the production URL and see the live read/write tool surface.
Read moreApproval and undo architecture
See what happens after authentication when an agent proposes a change.
Read moreHosted vs official vs open source
Compare setup ownership, write access, MCC routing, and recovery.
Read more