Problem
The development proxy completes MCP initialization before its backend finishes starting. An immediate tools/list can therefore advertise only the three dev_* tools, even when backend startup succeeds a moment later.
This is a usability problem for hosts that build their callable tool inventory during initial discovery. In the Codex session used for this investigation, the registered inventory contained only the three development tools. I have not isolated whether that host missed the later notification or intentionally kept its initial inventory; the proxy-side startup race is independently reproducible with the MCP SDK.
Reproduction
From a built checkout, connect an SDK Client to tools/dev-proxy/dev-proxy.mjs over stdio. Set DEV_PROXY_ROOT to the checkout and use DEV_PROXY_BACKEND_TRANSPORT=stdio to avoid port conflicts. Call client.listTools() immediately after client.connect(), then call it again after backend startup.
Observed on Windows with Node v24.14.1:
- First SDK probe: 3 tools at 679 ms; 31 tools at 3,147 ms.
- A second probe through the HTTP backend transport: 3 tools at 292 ms; 31 tools at 813 ms.
- The initial inventory is
dev_restart_debugger, dev_rebuild_and_restart, and dev_server_status; the later inventory also includes the 28 debugging tools.
The backend becomes healthy in both probes. This is not a backend-start failure.
Cause
In dev-proxy.mjs, server.connect() runs before the awaited backend.start(). The ListToolsRequestSchema handler returns the dev-only fallback unless the backend is already running. After startup, the proxy sends notifications/tools/list_changed.
That notification is appropriate protocol behavior, but relying on dynamic tool rediscovery makes the initial usable inventory timing-dependent.
Expected / proposed direction
Let the initial tools/list wait for the first backend startup attempt, with a bounded wait and the existing dev-only fallback if startup fails. Continue to expose recovery tools when the backend is down and preserve list-changed notifications for subsequent restarts.
Coverage should exercise an immediate first tools/list during delayed successful startup, failed startup with usable recovery tools, and rediscovery after a restart.
Problem
The development proxy completes MCP initialization before its backend finishes starting. An immediate
tools/listcan therefore advertise only the threedev_*tools, even when backend startup succeeds a moment later.This is a usability problem for hosts that build their callable tool inventory during initial discovery. In the Codex session used for this investigation, the registered inventory contained only the three development tools. I have not isolated whether that host missed the later notification or intentionally kept its initial inventory; the proxy-side startup race is independently reproducible with the MCP SDK.
Reproduction
From a built checkout, connect an SDK
Clienttotools/dev-proxy/dev-proxy.mjsover stdio. SetDEV_PROXY_ROOTto the checkout and useDEV_PROXY_BACKEND_TRANSPORT=stdioto avoid port conflicts. Callclient.listTools()immediately afterclient.connect(), then call it again after backend startup.Observed on Windows with Node v24.14.1:
dev_restart_debugger,dev_rebuild_and_restart, anddev_server_status; the later inventory also includes the 28 debugging tools.The backend becomes healthy in both probes. This is not a backend-start failure.
Cause
In dev-proxy.mjs,
server.connect()runs before the awaitedbackend.start(). TheListToolsRequestSchemahandler returns the dev-only fallback unless the backend is already running. After startup, the proxy sendsnotifications/tools/list_changed.That notification is appropriate protocol behavior, but relying on dynamic tool rediscovery makes the initial usable inventory timing-dependent.
Expected / proposed direction
Let the initial tools/list wait for the first backend startup attempt, with a bounded wait and the existing dev-only fallback if startup fails. Continue to expose recovery tools when the backend is down and preserve list-changed notifications for subsequent restarts.
Coverage should exercise an immediate first tools/list during delayed successful startup, failed startup with usable recovery tools, and rediscovery after a restart.