Unknown connection regression

[kentcdodds]

Describe the bug

Note in the screenshot below with version 0.16.3, the initialization request is successful, but it says there's an error connecting:

In 0.16.2 the connection works without issue:

To Reproduce
Steps to reproduce the behavior:

git clone https://github.com/epicweb-dev/epic-me-mcp.git
cd ./epic-me-mcp
git checkout a34cb30e8fb921b6d28341e8ddff20693bd214a3
npm install
npm run dev

In another tab:

npx @modelcontextprotocol/inspector@0.16.3

Connect to http://localhost:8787/mcp over streamable http

Expected behavior

Connection should show as successful and it should show the tools.

Logs

All logs appear normal, check them out below:

inspector logs

npx @modelcontextprotocol/inspector@0.16.3
Need to install the following packages:
@modelcontextprotocol/inspector@0.16.3
Ok to proceed? (y) 

Starting MCP inspector...
⚙️ Proxy server listening on localhost:6277
🔑 Session token: 31e0f9a5899dd05457dc93fe8fe07337b786584f20f62b0bf0073334327dcad1
   Use this token to authenticate requests or set DANGEROUSLY_OMIT_AUTH=true to disable auth

🚀 MCP Inspector is up and running at:
   http://localhost:6274/?MCP_PROXY_AUTH_TOKEN=31e0f9a5899dd05457dc93fe8fe07337b786584f20f62b0bf0073334327dcad1

🌐 Opening browser...
New StreamableHttp connection request
Query parameters: {"url":"http://localhost:8787/mcp","transportType":"streamable-http"}
Created StreamableHttp server transport
Created StreamableHttp client transport
Client <-> Proxy  sessionId: 5175848e-3e9f-4d1a-8fbb-8e3ec64d1599
Error from MCP server: Error: Error POSTing to endpoint (HTTP 401): {"error":"invalid_token","error_description":"Missing or invalid access token"}
    at StreamableHTTPClientTransport.send (file:///Users/kentcdodds/.npm/_npx/7e8b431f3a526226/node_modules/@modelcontextprotocol/sdk/dist/esm/client/streamableHttp.js:284:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
New StreamableHttp connection request
Query parameters: {"url":"http://localhost:8787/mcp","transportType":"streamable-http"}
Created StreamableHttp server transport
Created StreamableHttp client transport
Client <-> Proxy  sessionId: 91484b63-9d2c-4384-af77-dcee85104bc5
Proxy  <-> Server sessionId: fa1f46413b2235a12f1befeee4345a33fb8ea8c6cb6031ab8d5031127841dca9
Received POST message for sessionId 91484b63-9d2c-4384-af77-dcee85104bc5
Received GET message for sessionId 91484b63-9d2c-4384-af77-dcee85104bc5
Received POST message for sessionId 91484b63-9d2c-4384-af77-dcee85104bc5

MCP Server Logs

npm run dev

> dev
> wrangler dev


 ⛅️ wrangler 4.28.1
───────────────────
Using vars defined in .env
Your Worker has access to the following bindings:
Binding                                                        Resource                  Mode
env.EPIC_ME_MCP_OBJECT (EpicMeMCP)                             Durable Object            local
env.OAUTH_KV (8008746588ab4b6e8d3396cdb588700f)                KV Namespace              local
env.EPIC_ME_DB (epic-me)                                       D1 Database               local
env.MOCKS ("(hidden)")                                         Environment Variable      local

╭──────────────────────────────────────────────────────────────────────╮
│  [b] open a browser [d] open devtools [c] clear console [x] to exit  │
╰──────────────────────────────────────────────────────────────────────╯
⎔ Starting local server...
[wrangler:info] Ready on http://localhost:8787
▲ [WARNING] OAuth error response: 401 invalid_token - Missing or invalid access token


[wrangler:info] POST /mcp 401 Unauthorized (6ms)
[wrangler:info] OPTIONS /.well-known/oauth-protected-resource/mcp 404 Not Found (1ms)
[wrangler:info] GET /.well-known/oauth-protected-resource/mcp 404 Not Found (0ms)
[wrangler:info] OPTIONS /.well-known/oauth-protected-resource 404 Not Found (0ms)
[wrangler:info] GET /.well-known/oauth-protected-resource 404 Not Found (0ms)
[wrangler:info] OPTIONS /.well-known/oauth-authorization-server/mcp 404 Not Found (0ms)
[wrangler:info] GET /.well-known/oauth-authorization-server/mcp 404 Not Found (1ms)
[wrangler:info] GET /.well-known/oauth-authorization-server 200 OK (1ms)
[wrangler:info] POST /oauth/register 201 Created (4ms)
Starting migration process...
Schema versions table ready
Current schema version: 1
Migration process completed successfully
[wrangler:info] GET /authorize 302 Found (8ms)
[wrangler:info] OPTIONS /.well-known/oauth-protected-resource/mcp 404 Not Found (1ms)
[wrangler:info] GET /.well-known/oauth-protected-resource/mcp 404 Not Found (0ms)
[wrangler:info] OPTIONS /.well-known/oauth-protected-resource 404 Not Found (1ms)
[wrangler:info] GET /.well-known/oauth-protected-resource 404 Not Found (1ms)
[wrangler:info] OPTIONS /.well-known/oauth-authorization-server/mcp 404 Not Found (0ms)
[wrangler:info] GET /.well-known/oauth-authorization-server/mcp 404 Not Found (1ms)
[wrangler:info] GET /.well-known/oauth-authorization-server 200 OK (0ms)
[wrangler:info] POST /oauth/token 200 OK (4ms)
Starting migration process...
Schema versions table ready
Current schema version: 1
Migration process completed successfully
{
  displayMessage: 'State updated',
  id: '0lryhIIjknIIqeXaIn7ng',
  payload: { previousState: {}, state: { userId: null } },
  timestamp: 1754949017002,
  type: 'state:update'
}
[wrangler:info] POST /mcp 200 OK (14ms)
[wrangler:info] POST /mcp 202 Accepted (3ms)
Connection established
Connection FRbEJZjSMT1I8IU_7CYwc connected to _a:0542610fbeefbb5bc80ff66f1e04439bfffe8f02b50ba43969ec696b1000896a
[wrangler:info] POST /mcp 200 OK (3ms)
[wrangler:info] GET /mcp 405 Method Not Allowed (1ms)
Connection established
Connection OdOxxjlIz0peb-cESP_PQ connected to _a:0542610fbeefbb5bc80ff66f1e04439bfffe8f02b50ba43969ec696b1000896a
Connection established
Connection eKr5cvSpGnedKRVmGlw0d connected to _a:0542610fbeefbb5bc80ff66f1e04439bfffe8f02b50ba43969ec696b1000896a

Additional context
I'm pretty sure the 404s on the /.well-known are acceptable and the 405 on the GET /mcp is fine as well (though I did raise an issue about that over here cloudflare/agents#403).

[pahlers]

I have the same error, but with Transport Type STDIO and Command Node. Let me know if I need to supply more information.

(OP Nice logging 👍)

[KKonstantinov]

Hello,

Had this myself.

Managed to trace it back to #611 in browser, specifically in the following circumstances:

• Whenever the MCP server has capabilities.logging enabled
• Then the client after the merged PR above (initalize logging after connection #611) is doing logger/setLevel and this is where we get an MCP error.

The root cause code seems to be:

https://github.com/modelcontextprotocol/inspector/pull/611/files#diff-1308b8974395372ca4d89e566b653312adcb1a690a926bb21431639928db2701R566-R569

Temporary workarounds (if server in your control)

• Disable the "logging" capabilities of your server
• If you wish to leave them enabled, add a requestHandler to your server like so

server.setRequestHandler(SetLevelRequestSchema, request => {
                        console.log(`--- Logging level: ${request.params.level}`);
                        return {};
                    });

[KKonstantinov]

Linking to original issue #610

[cliffhall]

@kentcdodds The inspector is operating in spec - if the server advertises support for logging, the Inspector sends a setLevel request, as it "MAY" do according to spec. The server is operating out of spec. It advertises support for logging but fails to implement it, i.e., handle the setLevel request.

Servers that emit log message notifications MUST declare the logging capability:

{
"capabilities": {
   "logging": {}
 }
}

To configure the minimum log level, clients MAY send a logging/setLevel request:

{
 "jsonrpc": "2.0",
 "id": 1,
 "method": "logging/setLevel",
 "params": {
   "level": "info"
 }
}

Other clients in the wild which follow spec will naturally do this and when it fails with them, it's more likely a real "getting in the way of work" problem.

If we revert the automatic setLevel request, I think we're encouraging server developers to continue doing the wrong thing. This is after all, a tool for developers to inspect their servers and determine if they're operating correctly. We could possibly detect this particular case and display a toast to that effect? Would that be reasonable?

[kentcdodds]

I guess I assumed that handling the log level would be done by the SDK. I'll open an issue to explore that.

I have confirmed that once I implemented a handler for SetLevelRequestSchema my server connects without issue.

Thank you for the help here!

[kentcdodds]

The mentioned issue: modelcontextprotocol/typescript-sdk#871