anthropics / anthropics/claude-ai-mcp

Custom remote MCP connector reports "Couldn't reach the server" despite valid 200 responses, correct auth, GET support, and Mcp-Session-Id (matches issue #143)

Open
#1,001 1 comment 1 reaction 0 assignees View on GitHub
auth bug server-developer-report
Dominant language
No language data
Stars
471
Forks
77
PR merge metrics
No merged PRs in 30d

Description

### MCP server URL

https://mcp.pousch.org/message

### Where does the issue occur?

When pressing the Connect button

### Transport used

streamable-http

### Client registration type

Static

### 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-09-08 09:09:27 AM CET

### Browser and OS

_No response_

### Describe the issue

A self-hosted remote MCP server (Streamable HTTP transport, TypeScript/Express,
based on pnocera/bookstack-mcp-server) consistently fails Claude's custom
connector connection check with "Couldn't reach the server" / "Connection
issue", even though every single request from Claude's own client reaches the
server and receives a fully valid, spec-compliant response.

This appears to be the same unresolved issue reported in
https://github.com/anthropics/claude-ai-mcp/issues/143 (closed as not
planned), which I could not resolve on the server side despite extensive
debugging.

### Issue details

```shell
Setup
-----
- Remote MCP server URL: https://mcp.pousch.org/message
- Transport: Streamable HTTP (single endpoint, both GET and POST implemented)
- Auth: static request header (Authentication: None + Request headers beta),
Authorization: Bearer
- Hosted behind Cloudflare (proxied, Cloudflare Tunnel to origin)

What I verified server-side (with request-level logging added temporarily)
----------------------------------------------------------------------------
1. Auth header arrives correctly and matches exactly (confirmed byte-for-byte).
2. GET /message (same endpoint as POST) returns a proper response instead of
404 - added specifically because a missing GET handler is a known cause of
this exact error.
3. POST /message with a JSON-RPC "initialize" request returns HTTP 200 with a
fully valid MCP response body:
{"result":{"protocolVersion":"2025-06-18","capabilities":{...},
"serverInfo":{"name":"bookstack-mcp-server","version":"2.1.0"}},
"jsonrpc":"2.0","id":1}
4. The response includes a proper Mcp-Session-Id header (added stateful
session handling specifically to rule this out as a cause).
5. Cloudflare Security Events confirm Claude's requests (source IPs in
160.79.104.0/21, e.g. 160.79.106.160/163) reach the origin and are NOT
blocked/mitigated by Cloudflare or any WAF rule.
6. Server access logs confirm: every single "Reconnect" click in the Claude
UI produces exactly one successful POST /message with status 200 at the
exact timestamp of the click. No errors, no timeouts, no malformed
responses on any attempt.

Despite all of the above being correct on every attempt, the Claude UI
consistently shows:
"Connection issue - Couldn't connect to the server. Check that the URL
points to a valid MCP server."
```

### Expected behavior

Since the MCP handshake (initialize) succeeds with a valid response, correct
auth, and a proper Mcp-Session-Id on every single attempt, the custom
connector should show as "Connected" and expose the server's 59 tools -
not report "Couldn't connect to the server".

### Logs from your server

```shell
Reference IDs collected from failed attempts
---------------------------------------------
ofid_9c33eca50ea5c45e
ofid_db64f91519908b0f
ofid_e70f8831fd8b1539
ofid_a040fce8ce7541fc
ofid_d630aada0338f220
ofid_a040fce8ce7541fc
```

### Additional context

_No response_

Contributor guide

No contributing guide indexed for this repository

Research direction

The payload names no repository file or test; start at the custom connector's Connect flow and reproduce the failure against https://mcp.pousch.org/message. Compare the recorded initialize request and response, including Mcp-Session-Id and the supplied reference IDs. Done means a valid handshake is shown as Connected and the server's 59 tools are exposed.

Written by the indexing model from the issue text.

Assessment

Tech stack
express, typescript
Domain
api, backend
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.