Heavy sync init work (e.g. local ML models) starves stdio initialize/tool calls even with threadpool offload -- Windows GIL contention

Environment

• mcp 1.28.1 (Python SDK, mcp.server.fastmcp.FastMCP)
• stdio transport, Windows 11
• Blocking work: sentence-transformers / torch (local embedding model), but this
  generalizes to any CPU/GIL-bound library load (onnxruntime, local LLM inference, etc.)

Summary

Related to #1839 / #1909, but a distinct failure mode that threadpool offload does not
fix: GIL-bound CPU work (loading a torch model) contends with the anyio stdio
transport's Windows pipe-reader thread for the GIL, regardless of where it runs in-process.
This makes several reasonable-looking designs fail in ways that are easy to ship and hard
to reproduce in a quick manual test.

Measurements

Same model load (sentence-transformers/all-MiniLM-L6-v2), only the location changes:

Only the subprocess isolation keeps both connection time and first-call time bounded.
The variance (8s → 70s) is driven by contention between the model-loading thread and
anyio's Windows stdio reader thread — both fighting for the GIL.

Why this matters beyond my case

It's tempting to "fix" a slow first tool call by warming eagerly before mcp.run().
That instead moves the stall onto the initialize handshake — which is worse, because a
client that doesn't get the handshake in time just drops the server with no visible
error. That's a silent failure (tools missing, no exception) that's intermittent
(fine when warm/cached, broken on a cold start), so it's easy to ship and hard to catch
in CI or a quick manual check.

Suggested fix / ask

Not asking for an SDK-level fix necessarily — run_in_threadpool from #1909 is the right
answer for I/O-bound blocking calls. But it'd help other implementers to:

1. Note in the docs/guidance for FastMCP that CPU/GIL-bound initialization (local model
   loads, etc.) should NOT be threadpool-offloaded in-process — it should run in a
   separate subprocess — since threadpool offload does not release the GIL contention
   the way it does for I/O-bound blocking calls.
2. Consider whether initialize should have an explicit, documented deadline/backpressure
   behavior so implementers know exactly how much startup latency is safe.

Disclaimer: I'm not a Python/asyncio expert — this diagnosis, the measurements, and
this write-up were produced by Claude Code (Anthropic's coding agent) while it was
building a local memory/retrieval MCP server for me and debugging why it intermittently
failed to connect. I'm filing it because the finding looked substantive and reproducible,
but I likely can't answer deep follow-up questions about the internals myself.

FastMCP のドキュメントと、レポートに記載された stdio の初期化パスから始め、anyio.to_thread に関する既存のガイダンスを、観測された Windows の動作と比較してください。Done には、CPU/GIL に制約される初期化とサブプロセス分離に関するガイダンスを文書化し、initialize の期限や out-of-scope とする判断があれば明確に記載してください。