MCP server never successfully get tool and resource listing

[imrehg]

What happened?

I use Fastmail's MCP server (see their blogpost) in other LLM interfaces and coding agents, and wanted to set it up in qwen.

The authentication works in qwen, but then getting tools times out, and never successfully completes.

What did you expect to happen?

I expected requesting tool/resource/prompt lists all succeed in a short time.

Client information

Client Information

Run qwen to enter the interactive CLI, then run the /about command.

Warning: MCP server(s) failed to start: fastmail. Continuing with built-in tools and any servers that did connect. Re-run with QWEN_CODE_DEBUG=1 to see per-server reasons.
Qwen Code v0.19.11
Model: qwen3.6-35b-a3b-mtp
Fast Model: openai:lfm2-2.6b
Auth: openai
Platform: linux x64 (7.1.3-arch2-1)
Node.js: v26.4.0
Session: f65b4b65-f1cd-4218-a7e6-272e76501c81
Git commit: a0f373c1c
LSP: disabled

Login information

API Config

Anything else we need to know?

The same Fastmail MCP server works just fine in LMStudio and in Claude Code.

Also context7 (also oAuth) and kagi (bearer token, remoete) MCP servers work just fine in qwen.

While trying to hunt down the issue, I replicated similar calls to the MCP server as qwen does it, with curl, and all of those worked as expected.

Some further debug seems to be suggesting something around qwen's handling of the long loved GET SSE streams seems funky, that something hangs there.

The logs show something like:

269:2026-07-18T01:26:53.843Z [DEBUG] [MCP_OAUTH] Starting OAuth for MCP server "fastmail"…
279:2026-07-18T01:27:14.418Z [DEBUG] [MCP_OAUTH] Getting valid token for server: fastmail
280:2026-07-18T01:27:14.419Z [DEBUG] [MCP_OAUTH] Found token for server: fastmail, expired: false
281:2026-07-18T01:27:14.419Z [DEBUG] [MCP_OAUTH] Returning valid token for server: fastmail
282:2026-07-18T01:27:14.419Z [DEBUG] [MCP] Found stored OAuth token for server 'fastmail'
303:2026-07-18T01:28:14.872Z [ERROR] [MCP] Error discovering prompts from fastmail: MCP error -32001: Request timed out
304:2026-07-18T01:28:14.872Z [ERROR] [MCP] Error discovering resources from fastmail: MCP error -32001: Request timed out
305:2026-07-18T01:28:14.873Z [ERROR] [MCP] Error discovering tools from fastmail: MCP error -32001: Request timed out
306:2026-07-18T01:28:14.873Z [ERROR] [MCP] Error during discovery for server 'fastmail': No prompts, tools, or resources found on the server.
308:2026-07-18T01:28:44.874Z [WARN] [MCP] Health check failed for server 'fastmail' (1/3)
310:2026-07-18T01:29:14.875Z [WARN] [MCP] Health check failed for server 'fastmail' (2/3)
312:2026-07-18T01:29:44.876Z [WARN] [MCP] Health check failed for server 'fastmail' (3/3)
313:2026-07-18T01:29:44.877Z [INFO] [MCP] Attempting to reconnect to server 'fastmail'...

here's a hacked-up patch that seems to work for the feature but produces some test failures that need checking

diff --git a/packages/core/src/tools/mcp-client.ts b/packages/core/src/tools/mcp-client.ts
index ea7ead8fe..250de3b1f 100644
--- a/packages/core/src/tools/mcp-client.ts
+++ b/packages/core/src/tools/mcp-client.ts
@@ -26,6 +26,7 @@ import {
   ReadResourceResultSchema,
 } from '@modelcontextprotocol/sdk/types.js';
 import { parse } from 'shell-quote';
+import { Agent, fetch as undiciFetch } from 'undici';
 import type { Config, MCPServerConfig } from '../config/config.js';
 import { AuthProviderType, isSdkMcpServerConfig } from '../config/config.js';
 import { GoogleCredentialProvider } from '../mcp/google-auth-provider.js';
@@ -57,6 +58,7 @@ import type { PromptRegistry } from '../prompts/prompt-registry.js';
 import type { ResourceRegistry } from '../resources/resource-registry.js';
 import { getErrorMessage, getErrorStatus } from '../utils/errors.js';
 import { createDebugLogger } from '../utils/debugLogger.js';
+import { isTlsVerificationDisabled } from '../utils/runtimeFetchOptions.js';
 import { retryWithBackoff } from './mcp-retry.js';
 import { normalizePathEnvForWindows } from '../utils/windowsPath.js';
 import type {
@@ -250,13 +252,48 @@ export function createStreamableHttpCompatibilityFetch(
   };
 }
 
+// Streamable HTTP servers may hold a long-lived GET SSE stream open for the
+// lifetime of the connection (the transport opens it automatically after
+// `notifications/initialized`, per the MCP spec). Node's default global
+// fetch dispatcher stalls subsequent requests to the same origin while that
+// stream is open, until the MCP SDK's own request timeout fires. A
+// dedicated undici Agent does not have this problem, regardless of its
+// connection cap. `headersTimeout`/`bodyTimeout` are disabled because the
+// GET stream is expected to sit idle between server-sent events.
+let mcpFetchDispatcher: Agent | undefined;
+function getMcpFetchDispatcher(): Agent {
+  if (!mcpFetchDispatcher) {
+    mcpFetchDispatcher = new Agent({
+      headersTimeout: 0,
+      bodyTimeout: 0,
+      keepAliveTimeout: 60_000,
+      ...(isTlsVerificationDisabled()
+        ? { connect: { rejectUnauthorized: false } }
+        : {}),
+    });
+  }
+  return mcpFetchDispatcher;
+}
+
+// Bound to undici's own fetch (not Node's global fetch) so the dispatcher
+// and fetch implementation always come from the same undici version — Node's
+// bundled undici can be a different major version than the `undici` package
+// installed here, and mixing dispatcher/fetch across versions throws
+// "invalid onError method".
+// eslint-disable-next-line @typescript-eslint/no-explicit-any
+const mcpGlobalFetch: any = (input: unknown, init?: unknown) =>
+  undiciFetch(input as string, {
+    ...(init as object),
+    dispatcher: getMcpFetchDispatcher(),
+  });
+
 function createMcpStreamableHttpFetch(
   mcpServerName: string,
   mcpServerConfig: MCPServerConfig,
 ): typeof fetch {
   return createStreamableHttpCompatibilityFetch(
     mcpServerName,
-    globalThis.fetch.bind(globalThis),
+    mcpGlobalFetch,
     mcpServerConfig,
   );
 }

[qwen-code-ci-bot]

Triage

• Type: bug
• Labels: type/bug, category/tools, scope/mcp, priority/P2
• Next: Investigate Node fetch dispatcher stall on long-lived GET SSE streams; the reporter's patch direction (dedicated undici Agent) looks correct.

Root cause analysis

The MCP Streamable HTTP transport opens a long-lived GET SSE stream after notifications/initialized (per spec). Node's global fetch shares a single dispatcher per origin — while that GET stream sits open, subsequent POST requests (tools/list, resources/list, prompts/list) to the same origin queue behind it and stall until the SDK's 60 s timeout fires. This is why:

• OAuth succeeds (different origin / short-lived request)
• Tool/resource discovery times out at exactly 60 s
• The same server works in Claude Code and LMStudio (different fetch implementations / connection pooling)
• curl against the same endpoints works fine (no shared dispatcher)

The affected code path is createMcpStreamableHttpFetch in packages/core/src/tools/mcp-client.ts, which currently passes globalThis.fetch.bind(globalThis) — no per-transport dispatcher isolation.

Fix direction

The reporter's patch is on the right track: a dedicated undici.Agent (already a packages/core dep at ^7.28.0) with headersTimeout: 0 / bodyTimeout: 0 avoids the stall. A few things to get right in the actual fix:

• Use undici.fetch (not globalThis.fetch with an undici dispatcher) to avoid version-mismatch errors between Node's bundled undici and the installed package — the patch already accounts for this.
• Honor NODE_TLS_REJECT_UNAUTHORIZED / isTlsVerificationDisabled() for the connect.rejectUnauthorized option — patch does this too.
• The Agent should be scoped per-server or module-level singleton (the patch uses a module-level singleton, which is fine — one shared pool is correct here).
• Add a regression test that holds a GET SSE stream open and asserts a concurrent POST completes before timeout.

Confidence: high — the root cause is well-documented Node fetch behavior, the reproduction is clear, and the fix direction is straightforward.

中文说明

• 类型: bug
• 标签: type/bug, category/tools, scope/mcp, priority/P2
• 下一步: 调查 Node fetch dispatcher 在长连接 GET SSE 流上的阻塞问题；报告者提供的补丁方向（专用 undici Agent）正确。

根因分析

MCP Streamable HTTP 传输层在 notifications/initialized 之后会打开一个长连接 GET SSE 流（符合规范）。Node 的全局 fetch 对同一 origin 共享一个 dispatcher——当这个 GET 流保持打开时，后续对同一 origin 的 POST 请求（tools/list、resources/list、prompts/list）会排队等待，直到 SDK 的 60 秒超时触发。这解释了：

• OAuth 认证成功（不同 origin / 短连接请求）
• 工具/资源发现恰好在 60 秒时超时
• 同一服务器在 Claude Code 和 LMStudio 中正常工作（不同的 fetch 实现/连接池）
• 用 curl 直接请求相同端点没有问题（无共享 dispatcher）

受影响代码路径：packages/core/src/tools/mcp-client.ts 中的 createMcpStreamableHttpFetch，目前传入的是 globalThis.fetch.bind(globalThis)，没有传输层级别的 dispatcher 隔离。

修复方向

报告者的补丁方向正确：使用专用的 undici.Agent（已是 packages/core 的依赖，版本 ^7.28.0），设置 headersTimeout: 0 / bodyTimeout: 0 可避免阻塞。实际修复需注意：

• 使用 undici.fetch（而非给 globalThis.fetch 注入 undici dispatcher），以避免 Node 内置 undici 与安装包版本不一致导致的错误——补丁已处理此问题。
• 遵守 NODE_TLS_REJECT_UNAUTHORIZED / isTlsVerificationDisabled() 设置 connect.rejectUnauthorized——补丁也已处理。
• Agent 可以是模块级单例（补丁的做法，此处正确——共享一个连接池即可）。
• 需增加回归测试：保持 GET SSE 流打开，验证并发 POST 在超时前完成。

置信度：高 — 根因是有据可查的 Node fetch 行为，复现清晰，修复方向直接。

— Qwen Code · qwen3.7-max

[zjunothing]

Started on a PR for this (polishing the attached patch + fixing its test failures), but hit a wall trying to reproduce the stall deterministically first — sharing the matrix since it narrows the mechanism down considerably.

Setup: the real @modelcontextprotocol/sdk StreamableHTTPClientTransport + Client (the exact code path mcp-client.ts uses) against a local streamable-HTTP MCP server that completes initialize, then holds the standalone GET SSE stream open, then answers tools/list. Also a bare-fetch probe (open GET SSE, then concurrent POST to the same origin).

Node	fetch impl	GET SSE behavior	tools/list result
v22.23.1	globalThis.fetch (default)	headers + first bytes flushed, held open	completed in 11 ms
v22.23.1	globalThis.fetch	headers never sent (hang in waiting-for-headers)	completed in 14 ms
v26.5.0	globalThis.fetch	flushed + held	completed in 4 ms
v26.5.0	globalThis.fetch	headers hang	completed in 10 ms
v22.23.1	globalThis.fetch	server maxConnections = 1	immediate fetch failed (not a 60 s stall)

So on plain HTTP/1.1 against localhost, Node's shared dispatcher happily opens a second connection past the held GET stream on both Node majors — the general "same-origin GET SSE queues subsequent POSTs" mechanism does not reproduce. The stall in this environment must depend on something the local matrix doesn't capture: TLS/ALPN behavior toward the real Fastmail endpoint, a proxy layer, or server-side connection handling that differs from a plain Node http server.

A few data points that would pin this down (happy to take the PR over the line once the mechanism is clear):

1. QWEN_CODE_DEBUG=1 output for the fastmail server — especially whether the standalone GET stream reports opened before the discovery requests time out.
2. Are HTTP_PROXY / HTTPS_PROXY / ALL_PROXY set in that shell?
3. curl -sv https://<fastmail-mcp-endpoint> -o /dev/null 2>&1 | grep -i alpn — does the endpoint negotiate h2 or http/1.1?
4. The decisive bisect: does the patch still fix it if the dedicated Agent is dropped and only undici.fetch (default dispatcher) is used — and conversely, globalThis.fetch kept but with the GET stream disabled? That separates "dispatcher isolation" from "undici-version/timeout parameters" as the active ingredient, which determines what the correct upstream fix is.

The patch direction itself looks reasonable either way; I'd just rather land it with a regression test that actually fails on main, and right now no local scenario I can construct does.

中文

为提 PR 做前置复现时遇到了瓶颈，分享复现矩阵：用真实 SDK StreamableHTTPClientTransport + Client（与 mcp-client.ts 完全相同的代码路径）连本地 streamable-HTTP MCP 服务器（完成 initialize、保持 GET SSE 打开、应答 tools/list）。Node 22/26 × GET 正常 flush / headers 挂起 / 服务器连接数=1 共五种组合，tools/list 均在毫秒级完成或立即报错——「同 origin 的 GET SSE 让后续 POST 排队」这一一般机制在本地 plain HTTP/1.1 下不成立。stall 必然依赖本地矩阵未覆盖的条件（真实 Fastmail 端点的 TLS/ALPN、代理层、或与普通 Node http 服务器不同的服务端连接管理）。

希望补充四个数据点（机制定位后我愿意接手把 PR 做完）：1) fastmail 的 QWEN_CODE_DEBUG=1 日志（尤其 GET 流是否在发现请求超时前打开）；2) shell 里是否设置了 HTTP(S)_PROXY；3) curl -sv 到 fastmail MCP 端点的 ALPN 协商结果（h2 还是 http/1.1）；4) 决定性二分：去掉专用 Agent 只用 undici.fetch（默认 dispatcher）是否仍能修复；反之保留 globalThis.fetch 但禁用 GET 流是否也能修复——这能区分「dispatcher 隔离」与「undici 版本/超时参数」哪个才是起效成分，决定正确的上游修法。

patch 方向本身看起来合理；只是希望带着一个真正能在 main 上失败的回归测试合入，而目前本地构造不出这样的场景。

[imrehg]

1. I've started the qwen with QWEN_CODE_DEBUG=1 QWEN_DEBUG_LOG_FILE=1 on the pre-fix version:

Log recorded why doing "reconnect"

2026-07-18T09:13:18.685Z [DEBUG] [MCP_OAUTH] Getting valid token for server: fastmail
2026-07-18T09:13:18.685Z [DEBUG] [MCP_OAUTH] Found token for server: fastmail, expired: false
2026-07-18T09:13:18.685Z [DEBUG] [MCP_OAUTH] Returning valid token for server: fastmail
2026-07-18T09:13:18.685Z [DEBUG] [MCP] Found stored OAuth token for server 'fastmail'
2026-07-18T09:13:19.479Z [DEBUG] [SKILL_MANAGER] Listing skills at level: bundled
2026-07-18T09:13:19.479Z [DEBUG] [SKILL_MANAGER] Processing 9 bundled level skills
2026-07-18T09:13:19.479Z [INFO] [SKILL_MANAGER] Listed 9 unique skills
2026-07-18T09:13:19.479Z [DEBUG] [SKILL_MANAGER] Using cached skills
2026-07-18T09:13:19.479Z [DEBUG] [SKILL_MANAGER] Listing skills at level: user
2026-07-18T09:13:19.479Z [DEBUG] [SKILL_MANAGER] Using cached skills
2026-07-18T09:13:19.479Z [DEBUG] [SKILL_MANAGER] Processing 2 user level skills
2026-07-18T09:13:19.479Z [INFO] [SKILL_MANAGER] Listed 2 unique skills
2026-07-18T09:13:19.479Z [DEBUG] [SKILL_MANAGER] Listing skills at level: project
2026-07-18T09:13:19.479Z [DEBUG] [SKILL_MANAGER] Processing 20 project level skills
2026-07-18T09:13:19.479Z [DEBUG] [SKILL_MANAGER] Using cached skills
2026-07-18T09:13:19.479Z [INFO] [SKILL_MANAGER] Listed 20 unique skills
2026-07-18T09:13:19.479Z [DEBUG] [SKILL_MANAGER] Listing skills at level: extension
2026-07-18T09:13:19.479Z [DEBUG] [SKILL_MANAGER] Processing 0 extension level skills
2026-07-18T09:13:19.479Z [DEBUG] [SKILL_MANAGER] Using cached skills
2026-07-18T09:13:19.479Z [INFO] [SKILL_MANAGER] Listed 0 unique skills
2026-07-18T09:13:19.480Z [DEBUG] [BUNDLED_SKILL_LOADER] Loaded 9 bundled skill(s) as slash commands; 0 hidden by skills.disabled
2026-07-18T09:13:19.481Z [DEBUG] [SKILL_COMMAND_LOADER] Loaded 2 user + 20 project + 0 extension skill(s) as slash commands; 0 hidden by skills.disabled; 0 marked non-user-invocable
2026-07-18T09:13:47.710Z [DEBUG] [MEMORY_MONITOR] [MEMORY_USAGE] heapUsed=91.2MB, heapTotal=106.8MB, rss=271.8MB, external=19.0MB, arrayBuffers=0.7MB, heapUtilization=85.4%
2026-07-18T09:14:17.711Z [DEBUG] [MEMORY_MONITOR] [MEMORY_USAGE] heapUsed=91.3MB, heapTotal=106.8MB, rss=271.8MB, external=19.0MB, arrayBuffers=0.7MB, heapUtilization=85.5%
2026-07-18T09:14:19.224Z [ERROR] [MCP] Error discovering prompts from fastmail: MCP error -32001: Request timed out
2026-07-18T09:14:19.225Z [ERROR] [MCP] Error discovering resources from fastmail: MCP error -32001: Request timed out
2026-07-18T09:14:19.225Z [ERROR] [MCP] Error discovering tools from fastmail: MCP error -32001: Request timed out
2026-07-18T09:14:19.225Z [ERROR] [MCP] Error during discovery for server 'fastmail': No prompts, tools, or resources found on the server.
2026-07-18T09:14:47.712Z [DEBUG] [MEMORY_MONITOR] [MEMORY_USAGE] heapUsed=82.1MB, heapTotal=100.0MB, rss=265.2MB, external=19.0MB, arrayBuffers=0.7MB, heapUtilization=82.1%
2026-07-18T09:14:49.227Z [WARN] [MCP] Health check failed for server 'fastmail' (2/3)

It doesn't seem to have what you are appear to ask for, though, this is what the current logging setup gives.

2. no proxies are set

3. here ya go:

$ curl -sv https://api.fastmail.com/mcp -o /dev/null 2>&1 | grep -i alpn
* ALPN: curl offers h2,http/1.1
* ALPN: server accepted h2

4. I've tried those to the best of my abilities. Seems like both of them works ("undici's own fetch, no dedicated Agent, no dispatcher override at all" as well as "globalThis.fetch completely untouched, only the GET SSE stream suppressed")

[zjunothing]

@imrehg thanks — the bisection was exactly the missing evidence. PR is up: #7195.

It lands the undici-fetch direction from the original patch, polished: dedicated module-level Agent (headersTimeout/bodyTimeout disabled — a standalone SSE stream idles longer than undici's 300 s defaults), TLS verification following the existing isTlsVerificationDisabled() helper, and the fetch bound to the same undici build as the dispatcher. The two test failures the patch mentioned are fixed via a _setMcpFetchForTest seam (they stubbed globalThis.fetch, which the dedicated fetch deliberately bypasses), plus a new contract test doing real requests through the transport fetch.

For the record, the local reproduction matrix (real SDK transport; Node 22.23 / 26.4 / 26.5 × plain HTTP / TLS × GET flushed / headers-hung / maxConnections=1) never triggered the stall — so the PR's evidence for the fix is the bisection in this thread, stated as such. If you can run #7195 against the Fastmail setup, that confirmation on the PR would be the strongest possible signal for the maintainers.

中文

感谢二分实验——这正是缺失的证据。PR 已提交：#7195。落地原 patch 的 undici-fetch 方向并做了打磨：模块级专用 Agent（禁用 headers/body 超时——独立 SSE 流的空闲会超过 undici 默认 300 秒）、TLS 校验沿用既有 isTlsVerificationDisabled()、fetch 与 dispatcher 绑定同一 undici 构建。原 patch 提到的两个测试失败通过 _setMcpFetchForTest 测试缝修复（它们 stub 的是被专用 fetch 有意绕过的 globalThis.fetch），另加一个经 transport fetch 对真实本地服务器的契约测试。如实说明：本地复现矩阵（真实 SDK transport；Node 22.23/26.4/26.5 × plain/TLS × 三种 GET 行为）从未触发 stall，因此 PR 的修复证据是本 thread 中的二分实验。如果能用 Fastmail 环境跑一下 #7195 并在 PR 上确认，将是给 maintainer 的最强信号。