Environment
Extension: apify-mcp-server (Claude Desktop extension ant.dir.gh.apify.apify-mcp-server)
Version: 0.14.3
OS: Windows 11
Node: bundled/"built-in Node.js" runtime used by the Claude Desktop extension host
Server args: dist/stdio.js --tools actors,docs,apify/rag-web-browser
Client: Claude Desktop, specifically the separate server copy it spawns for Cowork/Code sessions ("shared-pool")
Summary
The MCP initialize request handler performs a live network call to the Apify platform API (fetching Actor metadata for apify/rag-web-browser, via getActors() in src/utils/tools_loader.ts → getActorsAsTools()) before it can return the InitializeResult. This call has no visible timeout, retry limit, or AbortController. When it's slow — which in our testing correlates with cold app/network startup (right after opening the laptop or Claude Desktop) — the client never gets an initialize response and eventually times out on its own (~60s), logging:
[error] Couldn't start this server for Cowork and Code sessions (they run their own copy of it), so they can't use its tools: Request timed out { metadata: { context: 'shared-pool', stack: undefined } }
The underlying api.apify.com endpoint itself is not reliably slow — manual curl tests immediately after a failure complete in well under 1s. The problem appears to be specifically about network-stack readiness at the moment the extension process cold-starts (DNS/route/VPN not yet warm), and the absence of any bound on how long the initialize handler will wait for that one HTTP call.
Steps to reproduce
Configure the extension with --tools actors,docs,apify/rag-web-browser (or any config that requires fetching Actor metadata during init).
Close the machine/put it to sleep, or otherwise let the network stack go cold.
Open Claude Desktop shortly after and start a Cowork or Code session (which spawns its own copy of the MCP server).
Intermittently (observed twice in ~10 launches over several days), the initialize response never arrives and the session times out after ~55-60s.
Evidence from logs (timestamps show the gap)
2026-08-19T00:15:59.475Z [info] Message from client: method="initialize" id=0 params
2026-08-19T00:16:57.376Z [error] Couldn't start this server for Cowork and Code sessions (they run their own copy of it), so they can't use its tools: Request timed out { metadata: { context: 'shared-pool', stack: undefined } }
Same pattern reproduced again on 2026-08-21 (~52s gap between initialize and the timeout), unrelated to any local antivirus/filesystem interference (ruled out by testing with the extension folder excluded from real-time AV scanning — identical failure recurred).
Suggested fix
Wrap the Actor-metadata fetch invoked from the initialize handler in an explicit timeout (e.g. AbortController with a short budget, a few seconds) and degrade gracefully — return the InitializeResult on schedule and either (a) resolve tool sources lazily on first tools/list / tools/call, or (b) return a reduced tool set with a note that some Actor metadata is still loading.
This would make initialize itself fast and non-blocking regardless of transient network conditions, which matters a lot for clients like Claude Desktop that enforce their own hard timeout around the handshake for isolated/shared-pool sessions.
Where to file
GitHub issue on apify/apify-mcp-server (public repo, likely reaches the right engineers directly): https://github.com/apify/apify-mcp-server/issues
Or via https://help.apify.com/ if you'd rather go through support first.
Environment
Extension: apify-mcp-server (Claude Desktop extension ant.dir.gh.apify.apify-mcp-server)
Version: 0.14.3
OS: Windows 11
Node: bundled/"built-in Node.js" runtime used by the Claude Desktop extension host
Server args: dist/stdio.js --tools actors,docs,apify/rag-web-browser
Client: Claude Desktop, specifically the separate server copy it spawns for Cowork/Code sessions ("shared-pool")
Summary
The MCP initialize request handler performs a live network call to the Apify platform API (fetching Actor metadata for apify/rag-web-browser, via getActors() in src/utils/tools_loader.ts → getActorsAsTools()) before it can return the InitializeResult. This call has no visible timeout, retry limit, or AbortController. When it's slow — which in our testing correlates with cold app/network startup (right after opening the laptop or Claude Desktop) — the client never gets an initialize response and eventually times out on its own (~60s), logging:
[error] Couldn't start this server for Cowork and Code sessions (they run their own copy of it), so they can't use its tools: Request timed out { metadata: { context: 'shared-pool', stack: undefined } }
The underlying api.apify.com endpoint itself is not reliably slow — manual curl tests immediately after a failure complete in well under 1s. The problem appears to be specifically about network-stack readiness at the moment the extension process cold-starts (DNS/route/VPN not yet warm), and the absence of any bound on how long the initialize handler will wait for that one HTTP call.
Steps to reproduce
Configure the extension with --tools actors,docs,apify/rag-web-browser (or any config that requires fetching Actor metadata during init).
Close the machine/put it to sleep, or otherwise let the network stack go cold.
Open Claude Desktop shortly after and start a Cowork or Code session (which spawns its own copy of the MCP server).
Intermittently (observed twice in ~10 launches over several days), the initialize response never arrives and the session times out after ~55-60s.
Evidence from logs (timestamps show the gap)
2026-08-19T00:15:59.475Z [info] Message from client: method="initialize" id=0 params
2026-08-19T00:16:57.376Z [error] Couldn't start this server for Cowork and Code sessions (they run their own copy of it), so they can't use its tools: Request timed out { metadata: { context: 'shared-pool', stack: undefined } }
Same pattern reproduced again on 2026-08-21 (~52s gap between initialize and the timeout), unrelated to any local antivirus/filesystem interference (ruled out by testing with the extension folder excluded from real-time AV scanning — identical failure recurred).
Suggested fix
Wrap the Actor-metadata fetch invoked from the initialize handler in an explicit timeout (e.g. AbortController with a short budget, a few seconds) and degrade gracefully — return the InitializeResult on schedule and either (a) resolve tool sources lazily on first tools/list / tools/call, or (b) return a reduced tool set with a note that some Actor metadata is still loading.
This would make initialize itself fast and non-blocking regardless of transient network conditions, which matters a lot for clients like Claude Desktop that enforce their own hard timeout around the handshake for isolated/shared-pool sessions.
Where to file
GitHub issue on apify/apify-mcp-server (public repo, likely reaches the right engineers directly): https://github.com/apify/apify-mcp-server/issues
Or via https://help.apify.com/ if you'd rather go through support first.