Custom connector forces OAuth on public/no-auth MCP server — "Couldn't register with sign-in service" even with no OAuth advertised(ofid_46fad6d84a4cce17 @ claude.ai; ofid_7f7d0d225e4a87bd @ Claude Desktop/Cowork/Code))

[happypig]

MCP server URL

https://cbdata.dila.edu.tw/dev/mcp

Where does the issue occur?

When pressing the Connect button

Transport used

streamable-http

Client registration type

My server does not have auth

SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

When did you last reproduce this?

2026-06-17

Browser and OS

Chrome on Windows 11

Describe the issue

Our MCP server is intentionally public (no auth required) — it returns HTTP 200 to any POST /dev/mcp request without requiring any Authorization header. This works correctly with ChatGPT, Codex, Claude Code (STDIO), and other MCP clients.

However, claude.ai's custom connector refuses to connect to a public/no-auth MCP server. It always attempts OAuth registration and fails.

Issue details

What we tested

Test A — No OAuth advertised (current state):
- GET /.well-known/oauth-authorization-server → 404
- GET /.well-known/oauth-protected-resource → 404
- POST /dev/mcp → 200 (no auth required)
- Result: claude.ai shows "Couldn't register with CBETA_search_by_mcp'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_345258b3ba153c80"

Even with zero OAuth metadata advertised, claude.ai still tries to "register with sign-in service" and fails. Our server is public and requires no sign-in.

Test B — Full OAuth implemented:
We implemented the complete OAuth flow:
- /.well-known/oauth-authorization-server → 200 with valid RFC 8414 metadata
- /.well-known/oauth-protected-resource → 200 with valid RFC 9728 metadata
- POST /oauth/register → 201 (DCR via Doorkeeper)
- GET /oauth/authorize → 302 (Doorkeeper PKCE flow)
- POST /oauth/token → 200 (access token issued)

Result: claude.ai still failed with the same "Couldn't register with sign-in service" error. The OAuth flow could not complete successfully even though all endpoints responded correctly. We did not capture the ofid_ from this attempt, but it demonstrates the issue is not simply missing metadata — something in claude.ai's OAuth client/DCR integration is failing.

Test C — Verified by team account:
Another team member reproduced the same issue from their account, confirming it is not specific to our user or session.

Expected behavior

Claude.ai's custom connector should support connecting to public/no-auth MCP servers without forcing OAuth registration. When:

1. The MCP endpoint returns 200 (not 401) — indicating no auth required
2. .well-known OAuth metadata endpoints return 404 — indicating OAuth is not advertised
   …claude.ai should treat the server as a public connector and connect directly, skipping OAuth entirely. This is consistent with how ChatGPT, Codex, and Claude Code (STDIO) already work with our server.
   Alternatively, if the MCP spec requires OAuth support for HTTP-based transports, the error message should clearly indicate that public/no-auth servers are not supported, rather than showing a misleading "Couldn't register with sign-in service" error.

Logs from your server

$ curl -s -o /dev/null -w "%{http_code}" -X POST https://cbdata.dila.edu.tw/dev/mcp -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'
200

$ curl -s -o /dev/null -w "%{http_code}" https://cbdata.dila.edu.tw/.well-known/oauth-authorization-server
404

$ curl -s -o /dev/null -w "%{http_code}" https://cbdata.dila.edu.tw/.well-known/oauth-protected-resource
404

Additional context

• Server stack: Ruby on Rails, streamable-HTTP transport, stateless JSON mode (no SSE)
• Server is open-source: https://github.com/DILA-edu/cbeta-api/tree/dev (see config/routes.rb for the commented-out OAuth routes and explanation in Chinese)
• Other clients affected: This blocks DILA (Dharma Drum Institute of Liberal Arts) from using claude.ai, Claude App, Claude Cowork, Claude Code with our CBETA Buddhist canon search tools. We can use ChatGPT and Codex without issues.
• Hard constraint: Our server must remain public (no auth) to serve multiple clients including ChatGPT and Codex. Implementing auth just for claude.ai is not viable.

About CBETA and its scholarly significance

CBETA (Chinese Buddhist Electronic Text Association) is the internationally authoritative digital edition of the Chinese Buddhist canon — over 100 million characters spanning the Tripitaka (Taishō, Xùzàngjīng, Jiaxing, and other canonical collections) with rigorous digital textual criticism, variant apparatus, and structured metadata. It is the standard reference used daily by Buddhist studies scholars, historians, linguists, and philologists worldwide for scriptural research, intertextual analysis, and historical citation.
This MCP server is the first structured API gateway that makes CBETA's corpus directly accessible to LLM-based research workflows (semantic search, passage retrieval, citation resolution, variant analysis). Being blocked from Anthropic's ecosystem means an entire academic discipline's worth of structured scholarly data — with no equivalent alternative — is unavailable to Claude users, while it is already accessible via ChatGPT and Codex.

[localden]

Thank you for taking the time to report this.

We traced ofid_345258b3ba153c80 (2026-06-17 ~00:05 UTC). This is a connectivity problem, not an authentication one. When you clicked Connect, Claude could not complete a TLS handshake with your server on any request: the initial unauthenticated check, the OAuth metadata lookups, and the fallback client-registration attempt all failed the same way. The TCP connection opened but the TLS handshake was reset or rejected before any HTTP byte was exchanged. Because the no-auth check never got a response, the flow fell through to OAuth discovery, which also could not connect, so the error you saw came from the OAuth step even though OAuth is not the actual issue.

This is almost always one of:

1. A firewall, WAF, or intrusion-detection rule in front of the host that resets TLS from cloud-provider IP ranges. Claude's connector traffic originates from 160.79.104.0/21 (AS399358); the host needs to accept inbound HTTPS from that range.
2. An incomplete or non-publicly-trusted TLS certificate chain. Browsers often fetch a missing intermediate certificate on the fly; server-to-server HTTP clients do not.

Once the host is reachable over TLS from the public internet, Claude should detect that the server needs no authentication and connect without any OAuth prompt.

If you fix reachability and it still fails, please reopen with a fresh reference ID and we will re-trace.

[tomasdev]

@localden is there a way to trace or debug the error ourselves? ofid_1b64950ab574dc1d has the same failure, for the widely open and available https://design.googleapis.com/mcp which works fine in Gemini and ChatGPT.

[happypig]

@localden is there a way to trace or debug the error ourselves? ofid_1b64950ab574dc1d has the same failure, for the widely open and available https://design.googleapis.com/mcp which works fine in Gemini and ChatGPT.

@tomasdev may check the following first if you missed it. However, Inspector can't help in registration debug.

https://modelcontextprotocol.io/docs/tools/inspector

[tomasdev]

Inspector works fine

[tomasdev]

@localden any tools to debug the auth portion? I'm assuming it goes through the Claude servers, and thus cannot be inspected via Charles proxy or similar