timeout errors from mcp-server
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
+1 I too keep getting this error message every now and then.
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
}
}
Execution failed: Call to 'ComputerControllerExtension' failed for 'tools/call'. Error from mcp-server:
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.
Error: MCP error -32001: Request timed out
2025-04-01T13:53:13.909Z [info] [filesystem] Message from client: {"jsonrpc":"2.0","method":"notifications/cancelled","params":{"requestId":0,"reason":"Error: MCP error -32001: Request timed out"}}
Experiencing pretty much similar issue
2025-04-04T20:42:42.920Z [info] [knowledge-base] Initializing server...
2025-04-04T20:42:42.949Z [info] [knowledge-base] Server started and connected successfully
2025-04-04T20:42:42.952Z [info] [knowledge-base] Message from client: {"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"claude-ai","version":"0.1.0"}},"jsonrpc":"2.0","id":0}
2025-04-04T20:43:42.955Z [info] [knowledge-base] Message from client: {"jsonrpc":"2.0","method":"notifications/cancelled","params":{"requestId":0,"reason":"Error: MCP error -32001: Request timed out"}}
2025-04-04T20:43:42.955Z [info] [knowledge-base] Client transport closed
2025-04-04T20:43:42.955Z [info] [knowledge-base] Server transport closed
2025-04-04T20:43:42.955Z [info] [knowledge-base] Client transport closed
2025-04-04T20:43:42.956Z [info] [knowledge-base] Server transport closed unexpectedly, this is likely due to the process exiting early. If you are developing this MCP server you can add output to stderr (i.e. console.error('...') in JavaScript, print('...', file=sys.stderr) in python) and it will appear in this log.
Closing this for now as we have not seen this recently