Our Mixpanel connector said "connected" and read nothing. It was the region.

For months I had a Mixpanel MCP connector sitting in my tools list marked connected, with 65 tools loaded and no OAuth errors anywhere. Every time I asked it a question about our funnel it came back empty, so every time I shrugged and went to the Mixpanel UI instead. "The Mixpanel MCP doesn't work" became a thing I believed without ever checking why.

It worked fine. It was pointed at the wrong continent.

The symptom: a connector that is half alive

What made this take months rather than minutes is that the connector was not broken in any of the ways a connector is normally broken. Authentication passed. The tool list loaded in full. Two tools even returned correct answers:

• List-Organizations returned our real organization, by name and id.
• Get-Projects returned our real project and workspace ids.

So the connector could see our account. It just could not read a single event out of it. Every data tool failed, and I confirmed it was not one bad tool by running two of them, Get-Business-Context and Get-Events. Identical refusal both times.

The error had been telling me the answer the whole time

When I finally read the tool result instead of the connector status, the message was not ambiguous at all:

This project is hosted in eu.mixpanel.com … connect to mcp-eu.mixpanel.com

Mixpanel runs one MCP host per data region. Our project is on EU data residency, our connector was pointed at the US host, and the US host politely declined to serve data it does not hold. Our application code was never wrong: both our server and browser SDKs write to api-eu.mixpanel.com, and events were landing all along. The blindness was only on the read side, which is exactly why it never showed up as a product bug.

Why the protocol gives a client no chance to catch this

My first instinct was that our gateway should have detected the mismatch during discovery. It cannot. I probed all three Mixpanel MCP hosts today with an unauthenticated initialize call:

for h in mcp.mixpanel.com mcp-eu.mixpanel.com mcp-in.mixpanel.com; do
  curl -s -o /dev/null -w "%{http_code} $h\n" -X POST "https://$h/mcp" \
    -H 'content-type: application/json' \
    -H 'accept: application/json, text/event-stream' \
    -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}'
done
# 401 mcp.mixpanel.com
# 401 mcp-eu.mixpanel.com
# 401 mcp-in.mixpanel.com

Three live hosts, three identical 401s. Their OAuth protected-resource documents are identical too, apart from the hostname echoed back inside them. Same 18 scopes, and each host names itself as its own authorization server. There is no field in that handshake for "which region is this account in", because the server has no idea who is asking yet.

The WWW-Authenticate header makes it worse. All three hosts return the same advice on a bad token:

Bearer error="invalid_token", error_description="Authentication failed. … To resolve:
clear authentication tokens in your MCP client and reconnect. Your client should
automatically re-register and obtain new tokens."

That is good advice for an expired token and useless advice for a region mismatch. Clearing tokens and reconnecting re-runs OAuth against the same wrong hostname and lands you back where you started, feeling slightly more certain that the server is broken.

Mixpanel is not the odd one out

Once I knew what to look for, the same split turned up in the connector I get asked about most. Intercom documents two MCP endpoints, https://mcp.intercom.com/mcp for US-hosted workspaces and https://mcp.eu.intercom.com/mcp for EU-hosted ones, with AU-hosted workspaces not supported at all yet. Their tell is simpler than Mixpanel's: look at your own workspace URL. If it says app.eu.intercom.com, the US endpoint will never work for you no matter how clean the OAuth flow looks.

This is going to keep spreading. Data residency is a normal enterprise requirement, and the normal way to satisfy it is a region-specific hostname. MCP inherits that without having anywhere to put it: the spec has no notion of a home region, and a connector directory entry is a single URL string. Every provider that adds an EU host turns its one marketplace tile into a tile that is wrong for some fraction of the people who click it.

The check that takes two minutes

If a connector authenticates and then reads nothing, stop looking at the connection status and do this instead.

• Read the tool result, not the connector badge. A region refusal is a successful call that returns an error string, so it never turns the connector red.
• Check the host you actually log into. eu.mixpanel.com and app.eu.intercom.com in your browser's address bar are the same signal as a region-prefixed MCP hostname.
• Try a metadata tool and a data tool separately. Metadata passing while data fails is the fingerprint of a routing problem rather than a permissions problem, and it is a very different debugging session from "nothing works".
• Before assuming a provider only has one host, guess the regional one and curl it. A live 401 means the endpoint exists and wants OAuth. A DNS failure means it genuinely does not exist, which is the answer I got when I tried the same trick on Sentry.

What I took from it

The expensive part was not the fix, which was one URL. It was the months of quietly routing around a tool I had decided was unreliable, on evidence I never once read closely. The same pattern produced the ten OAuth false positives we found across our marketplace: a plausible status signal, believed instead of tested. Connector status tells you a handshake completed. It does not tell you the server on the other end holds your data, and those are not the same question.

Every connector we ship in the Command+K marketplace gets pointed at a real account before it goes live, which is how the OAuth false positives surfaced in the first place. Region coverage is the next thing on that list.