Claude MCP not working on self hosted Metabase

Get Help
1

Hey,

We’re self-hosting metabase, but we do have an issue regarding the installation of the Claude MCP, it doesn’t recognize our URL, whereas it is the url I do get from our admin settings interface.

We’ve followed the tutorial right there, but didn’t help.

Any idea? Did anyone have the same issue?

Thanks a lot!

image
image1708×1242 128 KB

2

Seems related to this bug:

3

Update, this bug is closer to the problem identified:

4

Update: this was a Cloudflare issue - not a Metabase issue.

I’m having this problem too and it’s very flaky. The MCP connection is incredibly handy for me (having Claude back up its theories with real data regularly results in better outcomes), but it’s down around 20% of the time.

Over the past month, the MCP has required reauthorization in Claude at least 20 times. Sometimes it will reconnect immediately, other times I have to wait an hour to two days. Currently, I’ve been waiting 2 days and it still won’t reconnect.

In Claude, I get this error:

Connection issue
Connection has expired. You can reconnect to re-authenticate.

Couldn’t register with Metabase’s sign-in service. You can try again, or add an OAuth Client ID in the connector settings. If this persists, share this reference with support: “ofid_114e4f1e450a89ae”

Only theories I have:

  • If the MCP connection touches base with metabase.com, even for local installs, then any outage or flakiness on Metabase’s side could cause this. That would be ridiculous though.
  • I pull new images nightly, so if new images regularly break the MCP, that would explain the flakiness. In that case, should I pin to a specific working version and stop getting updates?

What I’ve tried:

  • Reconnecting (results in error above)
  • Removing from Claude and readding the official MCP
  • Removing from Claude and adding a custom MCP (same “couldn’t register” error - although it picks up my favicon so it’s at least reaching the server)
  • Changing to a different Metabase installation on a different subdomain (same “couldn’t register” error)
  • Switching to “Metabase (Unofficial — Community)” also results in a connection error but has never worked for me
  • Verifying that the URL and Metabase itself is reachable and usable through the web interface
  • Going to try: pinning the Metabase image to different older versions to see if that fixes it

My setup:

  • Self-hosted on a public HTTPS subdomain
  • Directing MCP at the provided URL ~ https://metabase-dev.xxx.xxx/api/metabase-mcp
  • Docker image pinned at 0.62.4.5 (updated below) because it seemed to work more often
  • 7 other, working MCP connectors (GitHub, PostHog, etc.) with zero flakiness, but none self-hosted

Let me know if you need any more info.

5

May be related to this bug:

6

It might be related, but I’m not getting those specific token errors in my logs. I was just looking into them and noticed these from my connection attempts.

2026-Aug-21 13:34:132026-08-21 09:34:13,921 DEBUG middleware.log :: GET /api/health 200 0ms (0 DB calls) App DB connections: 0/3 Jetty threads: 3/50 (5 idle, 0 queued) (42 total active threads) Queries in flight: 0 (0 queued) {:metabase-user-id nil}
2026-Aug-21 13:34:432026-08-21 09:34:43,961 DEBUG middleware.log :: GET /api/health 200 0ms (0 DB calls) App DB connections: 0/3 Jetty threads: 3/50 (5 idle, 0 queued) (42 total active threads) Queries in flight: 0 (0 queued) {:metabase-user-id nil}
2026-Aug-21 13:35:102026-08-21 09:35:10,751 DEBUG middleware.log :: POST /api/metabase-mcp 401 0ms (0 DB calls) {:metabase-user-id nil}
2026-Aug-21 13:35:10"{\"jsonrpc\":\"2.0\",\"id\":null,\"error\":{\"code\":-32603,\"message\":\"Authentication required\"}}"
2026-Aug-21 13:35:10
2026-Aug-21 13:35:132026-08-21 09:35:13,736 DEBUG middleware.log :: POST /api/metabase-mcp 401 0ms (0 DB calls) {:metabase-user-id nil}
2026-Aug-21 13:35:13"{\"jsonrpc\":\"2.0\",\"id\":null,\"error\":{\"code\":-32603,\"message\":\"Authentication required\"}}"
2026-Aug-21 13:35:13

Uninstalling and reinstalling the MCP doesn’t fix it, so at first glance it doesn’t seem like a token issue, unless it’s server-side.

7

I had apparently already previously pinned the version to 0.62.4.5 because that version worked for a while. The previous messages were on 0.62.4.5.

I moved to 0.63.14.1 and now get these errors when trying to connect the MCP:

2026-Aug-21 14:06:262026-08-21 10:06:26,180 DEBUG middleware.log :: GET /api/health 200 0ms (0 DB calls) App DB connections: 0/10 Jetty threads: 3/50 (7 idle, 0 queued) (46 total active threads) Queries in flight: 0 (0 queued) {:metabase-user-id nil}
2026-Aug-21 14:06:262026-08-21 10:06:26,836 DEBUG middleware.log :: POST /api/metabase-mcp 401 1ms (0 DB calls) {:metabase-user-id nil}
2026-Aug-21 14:06:272026-08-21 10:06:27,517 DEBUG middleware.log :: POST /api/metabase-mcp 401 0ms (0 DB calls) {:metabase-user-id nil}

The error Claude produces is unchanged.

It doesn’t trigger the auth flow so it’s unsurprising that the metabase-user-id is blank.

8

Well I’ll eat my hat. I did it to myself.

I changed a few things in Cloudflare few days ago and thought maybe I should investigate that, too. Well, the problem was twofold in Cloudflare:

  1. A new rule I set up to block any requests for paths containing “/.” was blocking “/.well-known” paths for oAuth.
  2. Cloudflare’s bot-fight mode may have been the cause of the flakiness, letting it work sometimes and throttling/blocking at other times.

Turned both off and it now works! (You can probably also just set a higher skip path for “.well-known” if you prefer to keep blocking “/.”)

So it was never an issue with Metabase. Apologies if this ate anyone’s time and hopefully this helps anyone that made the same mistakes as me.

1 Like