Troubleshooting Your Google Ads Connector

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 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 truncated address, the wrong transport field, invalid JSON, or the wrong chat mode. The connector address is long — https://mcp.adcopilot.cloud/c/<your connector key>/mcp — and a copy that lost its tail fails quietly.

Fix. Re-paste the full address from your dashboard, 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; ChatGPT custom connectors live behind developer mode. Restart the client after any config edit — most read config at startup. The per-client shapes are collected on the clients page.

Every call fails with an expired-trial or subscription message

Symptom. Tools list fine, but calls return an error saying the trial has ended or the subscription is inactive.

Cause. Expiry is enforced server-side, so the client keeps showing tools it can no longer successfully call. The pilot is seven days; after that, calls refuse until there is an active subscription.

Fix. Nothing in the client will help — the state lives on the server. Sign in to your dashboard and follow the subscription step, or reply to your signup email. Once active, the same address works again with no re-configuration.

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. Open your connector's reconnect link — https://mcp.adcopilot.cloud/reconnect/<your connector key>, also shown in your dashboard — and consent again with the same Google account. Same address, same seat, history intact. 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.