René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Startup getSnapshot() on the critical path delays the first tools/list ~10s (health-probe clients show 'tools fetch failed')","articleBody":"## Summary\n\nOn a cold start, the stdio transport comes up fast (`initialize` responds in well under a second), but the **first `tools/list` response is delayed ~10–17s**. During that window the server is up and healthy, but any MCP client that uses a short-timeout health probe for `tools/list` (e.g. Claude Code's `claude mcp list`) reports the server as `Connected · tools fetch failed`, even though in-session tool calls work fine once the client's longer startup timeout has elapsed.\n\nThe delay appears to come from the startup lifecycle snapshot being `await`ed on the critical path *after* the transport is running but *before* the server settles into steady state.\n\n## Environment\n\n- **XcodeBuildMCP**: 2.6.2 (latest published; behaviour re-checked against `main` HEAD — the relevant code is unchanged there)\n- **Transport**: stdio (`xcodebuildmcp mcp`)\n- **Host**: macOS (Apple Silicon), Xcode 27\n- **Client**: Claude Code (short `tools/list` health probe); also reproducible by timing a raw `tools/list` over stdio\n\n## Observed behaviour / timings\n\n- `Server running on stdio` logged at ~385ms\n- `initialize` round-trips in ~0.8s\n- First `tools/list` returns after ~10–17s\n- In-session tool calls (`list_sims`, builds, etc.) all work — this is purely a first-response latency issue, so it presents as **cosmetic** but it makes the server look broken to any health-probe client.\n\n## Where it comes from (from source, `main` HEAD)\n\n`src/server/start-mcp-server.ts` starts the stdio transport, marks the lifecycle `running`, and then **awaits the startup snapshot on the critical path**:\n\n```ts\n// src/server/start-mcp-server.ts  (main)\nlifecycle.markPhase('starting-stdio-transport');\nawait startServer(server, { /* ... */ });        // transport is now up\n// ...\nlifecycle.markPhase('running');\nconst startupSnapshot = await lifecycle.getSnapshot();   // \u003c-- awaited before the server settles\nlog('info', `[mcp-lifecycle] start ${JSON.stringify(startupSnapshot)}`);\n// ...\nlifecycle.markPhase('deferred-initialization');\nvoid bootstrap.runDeferredInitialization({ /* ... */ }); // \u003c-- already fire-and-forget\n```\n\n`lifecycle.getSnapshot()` (in `src/server/mcp-lifecycle.ts`) gathers, among other things, the active simulator os_log sessions (`listActiveSimulatorLaunchOsLogSessions()`) and a peer-process sample (`matchingMcpProcessCount`). That snapshot is `await`ed synchronously in the startup sequence, so the server does not become responsive to the first `tools/list` until it resolves.\n\nNotably, a `runDeferredInitialization(...)` fire-and-forget hook already exists immediately below the `getSnapshot()` call — the startup snapshot looks like a natural fit for the same deferred path.\n\n## What I ruled out\n\n- **Peer-count (`matchingMcpProcessCount`) sampling is not the cause.** The `[mcp-lifecycle] startup anomalies: peer-count-high` warning is a red herring: reaping the leaked peer processes down to a normal count did **not** change the ~10s. So the cost is in the snapshot's other work (the simulator os_log session enumeration path), not the peer sample.\n- **Not a client-side timeout knob.** The delay is server-side; raising the client MCP timeout does not make `tools/list` return faster — it only lets the (successful) slow response through.\n\n## Suggested fix\n\nMove the startup `getSnapshot()` (and specifically the simulator os_log session enumeration it performs) **off the startup critical path** so the first `tools/list` is answered immediately — e.g. make the start-time snapshot fire-and-forget (`void lifecycle.getSnapshot().then(...)`) or fold it into the existing `runDeferredInitialization(...)` block just below it. The telemetry/anomaly logging it feeds is not something the first `tools/list` needs to block on.\n\n## Repro sketch\n\n1. `xcodebuildmcp mcp` over stdio.\n2. Send `initialize`, then immediately `tools/list`; time the `tools/list` response.\n3. Observe `initialize` fast, `tools/list` ~10s+ on a cold start.\n\nHappy to test a patch or provide more startup profiling if useful. Thanks for the great tool.\n","author":{"url":"https://github.com/diskude","@type":"Person","name":"diskude"},"datePublished":"2026-07-06T11:29:44.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/461/XcodeBuildMCP/issues/461"}