Local CLI MCP endpoint (http://localhost:54321/mcp) fails OAuth: Kong has no routes for .well-known/oauth-* — 'no Route matched with those values'

[tristanbes]

Bug report

Describe the bug

Following the official "Local Development" install docs (Platform: CLI → Server URL: http://localhost:54321/mcp), the Claude Code MCP client can never authenticate against the locally-bundled Supabase MCP server. The failure happens during OAuth discovery: Kong (the local stack's gateway on port 54321) has no routes for the .well-known/oauth-* metadata endpoints that the MCP server's auth flow depends on, so the client receives Kong's generic "no Route matched" 404 in place of an OAuth error response, and the SDK's Zod schema rejects the payload.

The MCP endpoint itself (/mcp) is reachable and responds, but the OAuth companion endpoints required to complete the authorization handshake are not proxied through Kong in the CLI's local stack. This makes the advertised http://localhost:54321/mcp URL effectively unusable from any MCP client that follows the standard OAuth 2.0 Protected Resource Metadata flow (RFC 9728).

Note: I'm filing here because this repo is where /docs/guides/getting-started/mcp + the "Platform: CLI" install instructions point users. The root cause likely lives in the Supabase CLI's Kong template (supabase/cli) — please feel free to transfer if appropriate.

To Reproduce

1. Install Supabase CLI 2.90.0 and run supabase start in any project.
2. Confirm the MCP URL is advertised by the CLI:

   $ supabase status
   ...
   │ MCP     │ http://127.0.0.1:54321/mcp │
   ...
   

3. Follow the official local install instructions for Claude Code — add to .mcp.json:

   {
     "mcpServers": {
       "supabase_local": {
         "type": "http",
         "url": "http://127.0.0.1:54321/mcp"
       }
     }
   }

4. In a terminal, run claude /mcp, select supabase_local, choose Authenticate.
5. Observe the failure dialog:

   Supabase_local MCP Server
   Status: failed
   Auth:   not authenticated
   URL:    http://127.0.0.1:54321/mcp
   
   Error: SDK auth failed: HTTP 404: Invalid OAuth error response: ZodError: [
     {
       "expected": "string",
       "code": "invalid_type",
       "path": ["error"],
       "message": "Invalid input: expected string, received undefined"
     }
   ]. Raw body: {"message":"no Route matched with those values"}
   

Reproducible via curl

The /mcp endpoint itself answers (POST, with the required Accept: application/json, text/event-stream), proving the MCP service is reachable through Kong:

$ curl -s -o /dev/null -w "%{http_code}\n" \
    -X POST http://127.0.0.1:54321/mcp \
    -H "Content-Type: application/json" \
    -H "Accept: application/json, text/event-stream" \
    -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"0"}}}'
400

But the OAuth discovery endpoints the client must fetch next are not routed:

$ curl -s http://127.0.0.1:54321/.well-known/oauth-protected-resource
{"message":"no Route matched with those values"}

$ curl -s http://127.0.0.1:54321/.well-known/oauth-authorization-server
404 page not found

The {"message":"no Route matched with those values"} payload is Kong's default no-route response, which is exactly what shows up in the Raw body: of the Claude Code error above — confirming the OAuth metadata fetch is the step that fails.

Running Docker containers in the local stack (no dedicated MCP container — the service is embedded in Studio, and hitting /mcp/.well-known/oauth-protected-resource actually falls through to Studio's Next.js 404 page, X-Powered-By: Next.js):

supabase_db_*        postgres:17.6.1.025
supabase_studio_*    studio:2026.01.27-sha-2a37755
supabase_pg_meta_*   postgres-meta:v0.95.2
supabase_rest_*      postgrest:v13.0.5
supabase_realtime_*  realtime:v2.73.2
supabase_inbucket_*  mailpit:v1.22.3
supabase_auth_*      gotrue:v2.182.1
supabase_kong_*      kong:2.8.1

Expected behavior

Following the documented Platform: CLI install path should yield a working, authenticated MCP connection. Concretely, the OAuth discovery endpoints advertised by the local MCP server (Protected Resource Metadata, Authorization Server Metadata, and the token/registration URLs they in turn point to) must all be reachable through Kong on port 54321, so that an MCP client can complete the standard RFC 9728 + OAuth 2.0 Dynamic Client Registration flow.

Either of the following would resolve this:

• Update the local Kong template shipped by the CLI to proxy the .well-known/oauth-* paths (and any downstream authorization/token/registration endpoints) to the MCP/Studio upstream.
• Have the local MCP server advertise OAuth URLs that resolve to endpoints Kong already routes (or a port/host that doesn't require going through Kong).
• Alternatively, ship a no-auth mode for the local CLI MCP (see related Local-only mode with no access token #22), since OAuth on a loopback-only dev stack is mostly ceremony anyway.

Screenshots

• Official install doc page (Platform: CLI, Client: Claude Code) showing http://localhost:54321/mcp as the recommended URL.
• Claude Code auth dialog showing the ZodError / Raw body: {"message":"no Route matched with those values"} failure.

(I'll add them via the web UI after the issue is created.)

System information

• OS: macOS 26.4.1 (Darwin 25.4.0)
• Supabase CLI: 2.90.0
• Kong image: public.ecr.aws/supabase/kong:2.8.1
• Studio image: public.ecr.aws/supabase/studio:2026.01.27-sha-2a37755
• Node.js: v24.14.0
• MCP client: Claude Code (HTTP transport)

Additional context

• The hosted MCP at https://mcp.supabase.com/mcp?project_ref=... works fine from the same machine / same client — the break is specific to the local CLI stack.
• Working workaround for anyone hitting this in the meantime: swap the HTTP transport for a stdio server pointed straight at the local Postgres, e.g.

  "supabase_local": {
    "command": "npx",
    "args": [
      "-y",
      "@modelcontextprotocol/server-postgres",
      "postgresql://postgres:postgres@127.0.0.1:54322/postgres"
    ]
  }

  This bypasses Kong and OAuth entirely and restores read-only SQL access against the local DB.
• Related existing issues: Local-only mode with no access token #22 (local-only mode with no access token), Functionality with Self Hosted Supabase Instances (non-local[?]). #69 (self-hosted functionality), Claude Desktop MCP Supabase - not working #5 (Claude Desktop MCP Supabase not working) — this one is narrower and specifically about the CLI-advertised local HTTP MCP + OAuth discovery gap.

[tristanbes]

Note that it has been months and months without possibility to use local supabase MCP. so it's not specific to 2.90.0 version.

[aantti]

@mattrossman

[Rodriguespn]

Thanks for reporting this @tristanbes. The local Supabase MCP server doesn't require authentication so you should have the MCP tools available after configuring the MCP server in .mcp.json and restart your claude code session.
The reason behind this is that, unlike the remote MCP server that points to your hosted Supabase project, the local MCP server points to your dev instance running on localhost, so you'll be the only one accessing your local project.

On step "4. In a terminal, run claude /mcp, select supabase_local, choose Authenticate.", you don't need to hit authenticate. supabase_local should display "connected" and "authenticated".

You can view all tools available for supabase_local if you select "View tools" option.

If you’re still running into any issues after step 4, feel free to reach out—we’re happy to help.

[gregnr]

@tristanbes Can you confirm if @Rodriguespn's suggestion worked for you? If yes, we can close this issue, otherwise we can try to debug why your local MCP server is requiring authentication (as @Rodriguespn said - it normally shouldn't)

[tristanbes]

Helllo @gregnr & @Rodriguespn

The issue is Claude is not seeing supabase_local MCP as connected
Nothing works for me (neither reconnect, nor authentitcate)

I have 2 instance of Supabase MCP, one local running on docker (supabase_local) and one for my production project on supabase cloud (supabase_prod). supabase_prod works just fine (don't mind the screenshot I just need to auth again)

[Rodriguespn]

Hi @tristanbes, thanks for sharing the screenshots, that’s really helpful.

I can see that your local project is running and that supabase_local is showing up but still asking for authentication, which definitely isn’t the expected behavior for the local MCP server.

On my side, I was able to reproduce something similar when the local project wasn’t running at first — after starting it and restarting Claude, the MCP server showed as connected and authenticated automatically (no manual auth step needed).

Could you share a bit more detail so we can dig into this?

• Your Claude Code version
• Your Supabase CLI version
• Your .mcp.json config for supabase_local
• Whether anything changes after restarting Claude after the local project is already running

As an alternative, depending on what you’re trying to do, you might not need the local MCP server at all. With Supabase CLI version v+2.81.3, you can interact directly with your local project (including querying the database and running advisors), which covers most of the MCP functionality today. The only tool that doesn’t yet have parity is get_logs.

For the best experience overall, I’d also recommend installing the Supabase agent skill

[tristanbes]

No specific version is impacted it's been at least 4/6 months on every up-to-date versions that i've been experiencing this.
Since.
Supabase is runninng, claude is being restarted 20 times a day, nothing changes after reboots.

{
  "mcpServers": {
    "shadcn": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "shadcn@canary", "registry:mcp"],
      "env": {
        "REGISTRY_URL": "https://alpine-registry.vercel.app//r/registry.json"
      }
    },
    "stripe": {
      "command": "npx",
      "args": ["-y", "@stripe/mcp@latest"],
      "env": {
        "STRIPE_SECRET_KEY": ""
      }
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    },
    "supabase_local": {
      "type": "http",
      "url": "http://localhost:54321/mcp"
    },
    "supabase_prod": {
      "type": "http",
      "url": "https://mcp.supabase.com/mcp?project_ref=XXXX&read_only=true&features=database"
    },
    "next-devtools": {
      "command": "npx",
      "args": ["-y", "next-devtools-mcp@latest"]
    }
  }

[tristanbes]

Update: I dug into this further and found the root cause. The OAuth discovery failure is only a symptom — the local MCP endpoint behind Kong can never work because Studio rejects every proxied POST with a 400.

Root cause

Kong's mcp route in the CLI's local stack is declared with strip_path: true and no preserve_host (defaults to false):

- name: mcp
  _comment: "MCP: /mcp -> http://studio:3000/api/mcp"
  url: http://supabase_studio_<project_id>:3000/api/mcp
  routes:
    - name: mcp
      strip_path: true
      paths:
        - /mcp
  plugins:
    - name: cors

With preserve_host: false, Kong rewrites the Host header to the upstream value (supabase_studio_<project_id>:3000) while forwarding X-Forwarded-Host: localhost:54321. Studio is a Next.js app, and Next.js rejects POST requests when Host and X-Forwarded-Host disagree (CSRF/host validation) → empty-body 400 for every JSON-RPC POST. GETs pass through fine, which is why the endpoint looks half-alive and why MCP clients surface this as a (mis)leading auth/connection failure.

Repro (CLI 2.105.0, Kong 2.8.1, Studio on Next.js 16.1.7, macOS/Docker Desktop)

# 1. Via Kong — always 400, empty body (X-Kong-Upstream-Latency proves Studio responded):
curl -i -X POST http://localhost:54321/mcp \
  -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'
# → HTTP/1.1 400 Bad Request (empty body)

# 2. Same request straight to Studio — works:
curl -X POST http://localhost:54323/api/mcp -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" -d '<same payload>'
# → 200 {"result":{"protocolVersion":"2025-03-26","capabilities":{"tools":{}},"serverInfo":{"name":"supabase","title":"Supabase","version":"0.7.0"}},...}

# 3. Proof the Host header is the trigger — direct to Studio but with Kong's rewritten Host:
curl -o /dev/null -w '%{http_code}\n' -X POST http://localhost:54323/api/mcp \
  -H "Host: supabase_studio_<project_id>:3000" -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" -d '<same payload>'
# → 400        (with "Host: localhost:54321" instead → 200)

Secondary bug

Even bypassing Kong entirely (http://localhost:54323/api/mcp), the server only gets as far as initialize. Any tools/list call fails:

{"jsonrpc":"2.0","id":2,"error":{"code":-32603,"message":"fetch failed"}}

with nothing useful in the Studio container logs. So there appear to be two stacked issues: the Kong/Host one (makes the documented URL unusable) and an internal fetch failure in Studio's MCP tool handlers.

Suggested fixes

• In the CLI's Kong template, set preserve_host: true on the mcp route (or have Studio's /api/mcp handler skip/accept the internal host) — this also matters for the .well-known/oauth-* routing mentioned in the original report.
• Separately, investigate the fetch failed in Studio's MCP tools/* handlers.

This explains why no Claude Code version/restart combination ever helped — the documented http://localhost:54321/mcp URL structurally cannot complete a single MCP POST.