invalid client_id format error with Supabase Auth

[tleyden]

I have a basic FastMCP based script with Supabase Auth:

import os
from dotenv import load_dotenv
from fastmcp import FastMCP
from fastmcp.server.auth.providers.supabase import SupabaseProvider

load_dotenv()

auth = SupabaseProvider(
    project_url=os.environ["SUPABASE_PROJECT_URL"],
    base_url=os.environ["BASE_URL"],
)

mcp = FastMCP("Hello Supabase", auth=auth)

@mcp.tool
def hello_supabase() -> str:
    """Simple authenticated hello world."""
    return "Hello from Supabase-protected MCP server!"

if __name__ == "__main__":
    mcp.run(transport="http", port=8000)

But it gets stuck at this error when trying to connect to it:

Here's a longer snippet from the Authorization URL that contains the client_id:

/auth/v1/oauth/authorize?response_type=code&client_id=https%3A%2F%2Fwww.mcpjam.com%2F.well-known%2Foauth%2Fclient-metadata.json&redirect_uri=

Here is my MCPJam config for that server:

(I wasn't sure what to put here TBH)

And my supabase OAuth config has DCR enabled:

Any idea what causes this error? {"code":400,"error_code":"oauth_client_not_found","msg":"invalid client_id format"}. Is that basically Supabase complaining that it doesn't like the client id format?

[dosubot]

This looks like a client registration strategy mismatch. The client_id being sent is https://www.mcpjam.com/.well-known/oauth/client-metadata.json — that's a CIMD (Client ID Metadata Document) URL, which is a feature of the MCP 2025-11-25 protocol version. Supabase Auth is rejecting it because it doesn't understand URL-formatted client IDs.

The Inspector is supposed to check if the authorization server advertises client_id_metadata_document_supported: true in its metadata and fail early if it doesn't [1]. It seems like either that check isn't triggering correctly, or Supabase's metadata endpoint is being parsed in a way that bypasses it.

There's actually a very similar issue just reported in #1926 — same root cause with LogTo instead of Supabase, where the URL-formatted client_id gets rejected by the auth provider.

Workaround: Try switching the registration strategy away from CIMD. In the Inspector config, you should be able to select "DCR" or "Pre-registered" as the registration strategy instead. If you use "Pre-registered", you'd need to manually register an OAuth client in Supabase and provide the resulting client_id and client_secret in the Inspector config. If you use "DCR" (which you already have enabled in Supabase), the Inspector should dynamically register itself and get a proper client ID back from Supabase rather than sending the metadata URL.

The core issue is that CIMD support is relatively new and many OAuth providers (including Supabase) don't support it yet.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[tleyden]

Try switching the registration strategy away from CIMD. In the Inspector config

I'm not using CIMD in my flow.

Does MCPJam Inspector support DCR?

[dosubot]

Yes, the Inspector does support DCR — it's available across all protocol versions (2025-03-26, 2025-06-18, and 2025-11-25) [1].

However, the client_id in your authorization URL (https://www.mcpjam.com/.well-known/oauth/client-metadata.json) tells us that CIMD is actually being used in your flow, even if you didn't explicitly choose it [2]. That URL-formatted client_id is the hallmark of CIMD — with DCR or pre-registered, the client_id would be a normal string, not a URL.

This is likely happening because:

• If you're on protocol version 2025-11-25 (the latest), the default registration strategy is CIMD, not DCR [3].
• If registration mode is set to "Automatic" (the default), the Inspector will prefer CIMD when the auth server appears to support it, falling back to DCR only if CIMD isn't available [4].

To force DCR, you can explicitly select "DCR (Dynamic Client Registration)" in the registration strategy dropdown in the Inspector's OAuth config modal [5]. Alternatively, switching to protocol version 2025-03-26 or 2025-06-18 would also avoid CIMD since it's only available on 2025-11-25.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[tleyden]

Since I filed the issue, I got further along with my MCP server. It now works end to end, as documented here: PrefectHQ/fastmcp#4066. (works on Goose, Claude and Chatgpt)

I'll retest the latest version with MCPJam Inspector, and if I hit any issues, I'll file a new ticket with better steps to repro.