When a Google Ads connector misbehaves, the fault is in one of three places: the client (config, transport, mode), the connector (trial, revocation, scoping, limits), or the Google account behind it. This page is the catalogue — symptom, cause, fix — ordered by how often each one is actually the answer. The product docs have a troubleshooting section too: troubleshooting in the docs.
The client lists no server, or a server with no tools
Symptom. Your MCP client shows nothing, or shows adcopilot with
zero tools.
Cause. Client-side, almost always: a mistyped address, the wrong
transport field, invalid JSON, or the wrong chat mode. The connector URL is
https://mcp.adcopilot.cloud/mcp — the same for everyone, so a wrong one is a
typo rather than a missing key.
Fix. Re-paste the URL https://mcp.adcopilot.cloud/mcp, then check the
client-specific trap: Gemini CLI needs the field
httpUrl, not url; Cursor
needs Agent mode and valid JSON;
Claude Code wants --transport http on
the add command, plus
--scope user — without it the server only shows in the folder you added
it from; Claude takes it as a custom connector (see the Claude section
below); ChatGPT
needs developer mode switched on before it can add the connector at all
(see its section below). Restart the client after
any config edit — most read config at startup. The per-client shapes are
collected on the clients page.
ChatGPT: the four places people get stuck
ChatGPT adds AdCopilot as an app you create yourself: developer mode on, then Plugins, then Create app, then Create MCP App, then a sign-in. The ChatGPT setup page has every click with screenshots, and the docs have the full step-by-step. These are the four snags on that path, in the order you meet them.
Developer mode is not in Settings. On a personal account it sits under Settings, then Security and login, near the bottom of the panel — scroll down. It works on the Free plan. If you use ChatGPT through a Business, Enterprise or Edu workspace and the switch is missing, that is most likely your workspace's policy: developer mode depends on it, and only your workspace admin can allow it. We cannot switch it on from our side.
The sign-in tab keeps spinning after you press Approve. The approval has gone through; the tab it lands on sometimes does not finish loading. Close it and go back to the ChatGPT tab, which should say "AdCopilot is installed."
The app's page says "No app tools available yet." This is ChatGPT's display catching up, not a fault: our server has already answered with its tool list, and the chat works regardless. Open a new chat and carry on.
ChatGPT searched the web instead of using AdCopilot. Start the message with @AdCopilot and pick it from the list that appears, then type your question. Picking it with @ tells ChatGPT to use AdCopilot for that turn; without it, ChatGPT may decide to search the web.
Claude: the four places people get stuck
Claude adds AdCopilot as a custom connector: open "Add custom connector", name it and paste the URL, leave the sign-in settings as they are, press Add, then Connect and approve. The Claude setup page has every click with screenshots, and the docs have the full step-by-step. These are the four snags on that path.
There is no "Customize" in your sidebar. Claude lays these screens out differently between accounts. Skip the menus: this link opens the "Add custom connector" box straight away on either layout — claude.ai/new?modal=add-custom-connector. Sign in to Claude first if it asks.
Your browser's autofill list covers the URL box. Chrome sometimes
drops a list of saved entries over the "MCP server URL" field. Press Esc
to close it, then paste https://mcp.adcopilot.cloud/mcp.
Claude asks permission before every report. Claude starts AdCopilot's read-only tools on "Needs approval", so the first run of each one stops to ask. Open Customize, then Connectors, then AdCopilot, and under "Tool permissions" set the "Read-only tools" group to "Always allow". Leave the write tools on "Needs approval": AdCopilot proposes every change in the chat first anyway, and it cannot delete.
You use Claude through a Team or Enterprise organisation. Adding custom connectors there may be kept to the organisation's owners. If you cannot add it yourself, ask an owner to add AdCopilot for the organisation; each person then presses Connect and approves under their own sign-in. We cannot change that setting from our side. On a personal account, custom connectors work on the Free plan.
Every call fails with an account-limit or subscription message
Symptom. Tools list fine, but calls for a particular account return an error saying it is outside your plan's account limit, or that a paid subscription has lapsed.
Cause. The trial is seven days on the full Pro plan for a new workspace; when it ends, the workspace drops automatically to the Free plan — one account keeps working at Free's limits, not a lockout, but any other accounts you connected during the trial go quiet until you upgrade. Separately, if a paid subscription's billing period ends without renewing, the connector keeps working through that period and then stops for the accounts it covered.
Fix. Nothing in the client will help — the state lives on the server. Sign in to your dashboard to see which plan is active and which accounts it covers; starting or resuming a paid plan restores the rest immediately, with no re-configuration on the client side.
Google access revoked — auth errors on every call
Symptom. Calls fail with an authorisation error against Google, on a connector that previously worked.
Cause. The stored Google credential was invalidated. Common triggers: you removed AdCopilot under your Google account's third-party access, a workspace admin policy did, or a password-reset/security event rotated your grants. This is Google's revocation model working as intended — you can withdraw access at any time without asking anyone.
Fix. Reconnect from your AI client — or the reconnect prompt in your dashboard — and complete Google's sign-in again with the same Google account. Same seat, history intact, and nothing to re-paste; the URL never changed. A reconnect from a different Google account is refused by design: the connector verifies identity, so a colleague cannot quietly re-point your seat at their credentials. The full revocation model is on the security page.
The wrong account is visible — or the right one is missing
Symptom. List the accounts you can see returns somebody's personal
test account, an unexpected MCC tree, or is missing the client account
you manage.
Cause. One of three, in likelihood order: you were signed into the wrong Google account in the browser when you connected (the classic — most people are signed into several); the Google account you connected genuinely lacks access to that Ads account (the connector can never see more than your Google sign-in can); or the connector is deliberately scoped to specific customer IDs and is filtering exactly as configured.
Fix. For the first: reconnect via your dashboard using the right Google account — for a different identity that means a fresh connector, since reconnect protects the original identity. For the second: get access granted in Google Ads itself, then ask again — no connector-side change needed. For the third: check the connector's scoping in the dashboard, or ask whoever administers your org, because an org can narrow a member's access and that narrowing wins.
Rate limited
Symptom. A run of rapid calls starts returning a rate-limit refusal, usually mid-way through a large scripted job.
Cause. Per-connector rate limits, deliberately part of the security model — they cap the blast radius of a runaway loop, yours or an agent's.
Fix. Wait briefly and continue; limits recover on their own. Then shape the work to need fewer calls: one GAQL query returning a table beats thirty single-entity look-ups, and scheduled jobs should run the compact report pattern rather than enumerating the account. If a legitimate workload hits limits repeatedly, tell us — that is a conversation, not a workaround.
Writes refused when reads work fine
Symptom. Reports flow, but every mutate is refused.
Cause. Either the connector was configured with narrowed access, an org admin flipped the per-connector kill switch, or the Google account itself has read-only rights in that Ads account. And if the refused call was a delete: that is permanent design, not configuration — see the FAQ below.
Fix. Check the connector's status and scope in the dashboard, ask your org admin what they have narrowed, and verify your own role in Google Ads. The refusal always has a reason, and the reason is recorded.
Still stuck — bring the audit trail
Every call through the connector is logged — tool, account, success or refusal, reason, timestamp — which means support conversations start from evidence rather than guesswork. Write to [email protected] with the approximate time of the failing call and what the client displayed; the log usually names the cause in one look. And if the connector is fine but the account work is the puzzle, the prompt library is the better page to be on.