timeout errors from mcp-server

[baxen]

Describe the bug
Goose can get into a state where even tools that work instantly result in a "timeout error". Suspected but not sure that the server itself may have been dropped

https://discord.com/channels/1287729918100246654/1287729920797179957/1337930482947588107

Screenshots

Let me fix the handler code first. The issue seems to be in how we're handling the tools/list response for GET requests. Here's what I'm going to change:

─── text_editor | developer ──────────────────────────
path: ~/MCP/rust/brave_search/src/mcp/handler.rs
command: str_replace
new_str: ...
old_str: ...


Execution failed: Call to 'developer' failed for 'tools/call'. Error from mcp-server: request timed out

[sassycut]

+1 I too keep getting this error message every now and then.

[cliffhall]

I'm getting this issue as well. Slightly different message, seems to indicate my MCP server thinks there's a timeout error, in the @modelcontextprotocol/sdk/dist/esm/client/sse.js.

Error from MCP server: SseError: SSE error: TypeError: terminated: Body Timeout Error
    at _eventSource.onerror (file:///Users/cliffhall/Projects/GooseTeam/p1/node_modules/@modelcontextprotocol/sdk/dist/esm/client/sse.js:29:31)
    at EventSource.scheduleReconnect_fn (file:///Users/cliffhall/Projects/GooseTeam/p1/node_modules/eventsource/dist/index.js:248:53)
    at file:///Users/cliffhall/Projects/GooseTeam/p1/node_modules/eventsource/dist/index.js:98:174
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  code: undefined,
  event: {
    type: 'error',
    message: 'TypeError: terminated: Body Timeout Error',
    code: undefined,
    defaultPrevented: false,
    cancelable: false,
    timeStamp: 1016258.689625
  }
}

[PrinceSajjadHussain]

Execution failed: Call to 'ComputerControllerExtension' failed for 'tools/call'. Error from mcp-server:

[zakiali]

Dove into this a bit and I think this is whats going on: Goose agent starts and add's extensions, which have a specified (client side) timeout associated with them. When a command is issued, the client sends a request to the extension, which starts executing the command. If it's a long running command, the client will time out, and send an error message back to the LLM, which may follow up/try a different command. The command on the server is still running since there was no cancellation issued for the process from the client. The new command is queued up and waits on the original command to execute. If the original command is long running, the second command (even if it should be fast) will fail with a time out.

Solution:
The solution is to implement cancellation of in progress requests on the server. This requires an update to our implementation of the mcp protocol. We'll come back to this when we're ready to support the rust-sdk in the next few weeks.

In the meantime, if you are expecting to run commands that take a long time increase the timeout for your extensions through the configuration flow.