Waiting Is Not a Tool Call: Making an MCP Server's Shell Event-Driven

The MCP client's idle timeout is set to sixty seconds, making it susceptible to a scenario where a call is cancelled and the process continues running indefinitely. This was observed during testing, where two test suites were running simultaneously, leading to a locking error. In response, a workaround was developed to run the build first, then wait for four minutes, and finally check the results.

This led to the development of octofs, an open-source MCP filesystem server, which aimed to address this issue. The first fix involved adding liveness heartbeats to the call, which proved to be a shallow solution as the call was inherently silent. The deep issue was that the call still blocked, causing the model to wait for four minutes without being able to perform any other tasks.

To solve this, the second fix introduced background jobs. A command could now be run as a job, with output collected later. This was achieved by introducing a background flag on the shell tool. However, this flag was later recognized as a mistake and was deleted in 0.13.0, replaced with a measurement that automatically promoted the command to a background job if it remained running for ten seconds.

The third fix involved allowing jobs to run concurrently. This was done by narrowing the guard to prevent the same command from running twice in the same directory. If a command was already running, the model was instructed to wait for its completion instead. This resolved the issue of tests racing against each other, ensuring that the model could efficiently manage its tasks without unnecessary blocking.