MCP Servers Keep Breaking: The Real Cost for Ad Platforms

An entire session of ours ended with nothing delivered because a TikTok Ads MCP server kept failing with a -32000 error, even after we'd added a fresh access token. The 60-day performance review it was supposed to produce never happened. It became a handoff prompt instead.

That's not an edge case. Across six weeks of running AI agents against Meta, TikTok, and Google Ads through MCP connectors, connection and credential failures were the single biggest source of wasted sessions, ahead of bad code, ahead of scope misunderstandings. This is the reliability problem nobody puts in the launch posts: MCP servers for ad platforms demo beautifully and then fail unpredictably in actual daily use, usually from expired auth tokens or a connector that just stops responding mid-task. We've written before about what the official Meta Ads MCP can and can't do once it's working. This is about the more basic problem: staying connected at all, across every platform, not just Meta.

What Actually Fails, and How Often
Why This Happens More With Ad Platforms Specifically
The Fix: A Health Check Before the Real Work Starts
What to Do When It Fails Mid-Run Anyway
Frequently Asked Questions
Key Takeaways

What Actually Fails, and How Often

Two failure modes account for nearly every lost session:

Expired or stale auth tokens. Google Ads MCP in particular relies on ADC (Application Default Credentials) tokens that expire on a schedule most people don't track. We've had a multi-channel KPI pull blocked mid-run, twice, because the Google Ads token expired partway through a report that was supposed to cover 5 channels. The fix each time was a manual re-auth, which is fine, except it happens after the agent has already spent time building the rest of the report around a channel it can't finish.

Connector-level errors that don't explain themselves. A -32000 error from an MCP server tells you almost nothing actionable. It's not a permissions error, it's not a rate limit, it's the server-side equivalent of a shrug. When that happens on a platform-specific connector like TikTok Ads, there's often no fallback path, the whole task depends on that one connector staying up, and if it doesn't, the task doesn't happen.

Across a six-week sample of agency work run through Claude Code, tool failures and environment issues combined accounted for roughly a quarter of all recorded friction events, and one session ended completely unachieved specifically because of a dead MCP connection.

Why This Happens More With Ad Platforms Specifically

Ad platform APIs weren't built with AI agent access as a first-class use case, MCP servers wrapping them are relatively new, and the auth model for ad platforms tends to be heavier than a typical SaaS API: OAuth flows, refresh tokens, ADC credentials, sometimes a separate developer-app approval layer on top. Every one of those is a place a connection can silently go stale between sessions.

It also compounds with scale. A single-channel task has one point of failure. A multi-channel report, pulling Meta, TikTok, and Google Ads data into one KPI snapshot, has three, and the task doesn't partially succeed gracefully by default: one dead connector can stall the whole report unless you've explicitly built in a way to continue without it.

The Fix: A Health Check Before the Real Work Starts

The single highest-leverage change here is moving the failure earlier. Instead of discovering a dead connector three steps into a build, when creative has already been written and campaign structure already planned, verify every connector you'll need in one cheap call before starting real work.

In practice, that means a session-start check that pings each ad-platform MCP server (Meta, TikTok, Google Ads, whatever the task needs) and reports pass/fail before anything else runs. If a token's expired, you find out in the first ten seconds and can re-auth immediately, not after burning most of a session building around a gap you didn't know was there.

A few implementation notes that matter in practice:

Fail per-channel, not per-task. If Google Ads is down but Meta and TikTok are fine, the report should still run for the two that work and flag the gap for the third, not abort entirely.
Treat a dead connector as a first-class, reported outcome, not a silent skip. A report missing a channel with no explanation looks like a complete report. One that explicitly flags "Google Ads: token expired, re-auth needed" doesn't waste your time hunting for why a number is missing.
Don't retry blindly. A -32000 or similar opaque error retried in a loop rarely resolves itself and just burns more of the session. One retry, then surface it as a blocker.

What to Do When It Fails Mid-Run Anyway

Health checks catch most of this, but not all of it, tokens can expire mid-session even if they were valid at the start. When it happens:

Stop, don't route around it. If a tool call to mutate a live ad account gets blocked by a dead connection, don't silently fall back to a different method (browser automation, a different API path) without flagging it. The failure itself is information worth surfacing.
Report exactly what would have happened. Even without a working connection, you usually know what the intended action was. Handing that over as an explicit, ready-to-execute plan is more useful than a vague "something went wrong."
Draft the handoff, don't abandon the task. A session that ends in a clear, resumable handoff prompt is a fundamentally different outcome than one that just quietly fails. The work already done (research, structure, copy) shouldn't be lost because the last mile hit a dead connector.

Frequently Asked Questions

Q: Why does my Google Ads MCP connection keep expiring?

A: Google Ads MCP typically relies on ADC (Application Default Credentials) tokens, which expire on a refresh cycle. If a session runs long or spans multiple days, the token can go stale mid-task. Running an auth check before starting multi-step work catches this before it blocks a report partway through.

Q: What does a -32000 error from an MCP server mean?

A: It's a generic, non-specific server-side error that MCP servers use as a catch-all, it doesn't tell you whether the problem is auth, rate limits, or something else entirely. Treat it as a signal to stop retrying blindly and check the connector's status directly rather than assuming a fix.

Q: Should I build separate error handling for each ad platform's MCP server?

A: Yes, at minimum a lightweight health check per platform run before real work starts. Ad platform auth models differ enough (OAuth flows, ADC tokens, developer-app layers) that a single generic retry strategy won't catch platform-specific failure modes.

Q: Is this a reason to avoid using MCP servers for ad platform work?

A: No. The productivity gain from conversational access to ad platform data and actions is real and substantial. The fix isn't avoiding the tooling, it's treating connection health as something you verify upfront rather than discover mid-task.

Key Takeaways

Connection and credential failures, not bad code, were the single biggest source of wasted AI-agent sessions across six weeks of ad platform work.
Google Ads ADC token expiry and opaque TikTok Ads MCP errors were the two most common failure modes observed.
A cheap health check pinging every needed connector before real work starts turns a mid-task failure into a ten-second, fixable delay.
Multi-channel tasks should fail per-channel, not per-task, one dead connector shouldn't block the channels that are working.
When a connector fails mid-run anyway, stop and report the intended action rather than silently retrying or routing around it.

If AI-driven ad reporting and account work is part of your stack and you want it built with these failure modes handled upfront instead of discovered mid-crisis, that's exactly the kind of operational build we do for clients. Book a discovery call and we'll show you what that looks like.