Observe that the client returns a timeout error at exactly the 60s mark, even though the backend process is still running. The request is terminated by OpenClaw after approximately 60 seconds, even if the MCP server (OpenSpace) is still processing the task. This leads to a timeout error on the client side. Debugging confirmed that this is due to the hardcoded DEFAULT_REQUEST_TIMEOUT_MSEC in the @modelcontextprotocol/sdk used by OpenClaw, which is not being overridden during the callTool execution.

TL;DR

• Increase the DEFAULT_REQUEST_TIMEOUT_MSEC value in the @modelcontextprotocol/sdk used by OpenClaw to a higher value, such as 5-10 minutes, to allow long-running tasks to complete without premature timeouts.

Guidance

• Identify the location of the DEFAULT_REQUEST_TIMEOUT_MSEC constant in the @modelcontextprotocol/sdk code and consider overriding its value for the callTool execution.
• Verify that increasing the timeout value does not introduce other issues, such as resource leaks or performance degradation.
• Test the updated configuration with a long-running task to ensure it completes successfully without timing out.
• Consider implementing a dynamic timeout mechanism that adjusts based on task complexity or estimated execution time.

Example

• No explicit code example is provided, but the fix would involve modifying the DEFAULT_REQUEST_TIMEOUT_MSEC value, potentially through a configuration override or code patch.

Notes

• The exact method for overriding the DEFAULT_REQUEST_TIMEOUT_MSEC value is not specified and may require further investigation into the OpenClaw and @modelcontextprotocol/sdk documentation.
• Increasing the timeout value may have implications for system resource utilization and should be carefully evaluated.

Recommendation

• Apply workaround: Increase the DEFAULT_REQUEST_TIMEOUT_MSEC value to a higher value, such as 5-10 minutes, to allow long-running tasks to complete without premature timeouts, as this is a more immediate solution to the problem at hand.