[Feature]: STDIO MCP Usage is not currently scalable.

[cbagwell]

Is there an existing feature request for this?

• I have searched existing issues and feature requests, and this is not a duplicate.

Problem or Use Case

I am currently unable to use more than 2 STDIO MCP Servers. Adding a 3rd causes the conversation to never start up and provides no error messages to indicate the failure cause. Even with 2, the UI appears to freeze for 30 seconds when I send my first prompt.

I have traced the main issue to fact that OpenHand's relies on FastMCP and its MCPConfigTransport.connect_session() to initialize all MCP Servers and current version initializes them serially.

If you use the common practice of using uvx or npx to load the MCP Server (which is expected in this container usecase) then I'd say the average expected startup per MCP will be ~10 second range caused mostly by the downloading phase. Since there is a hard coded 30 second timeout on overall MCP startup, you can except 3+ MCP Server startup to be unreliable.

Proposed Solution

Possible solutions within OpenHands:

• Modify OpenHands to open MCP Servers separately so that it can be responsible for loading in parallel and then max init time is based on single worst case MCP load time.
• Submit a patch to FastAPI to support it loading them in parallel.

Nice to have:

• Have OpenHands display an error message pointing to MCP startup issues when 30 timeout is hit.
• Start initializing MCP's in the background and before user sends first prompt to avoid this long 30 second freeze.

Alternatives Considered

One can create custom agent-server image which prepopulates the STDIO MCP Servers they use but the fact that initialization times are accumulated serially, it still has an undesired UI freeze up to 30 seconds long if the user has very many MCP Servers.

Priority / Severity

Medium - Would improve experience

Estimated Scope

Medium - New feature with moderate complexity

Feature Area

Performance / Optimization

Technical Implementation Ideas (Optional)

No response

Additional Context

No response

[cbagwell]

#13321 address one of my nice to haves by surfacing MCP errors and continuing.

OpenHands/software-agent-sdk#2371 appears to be heading the right direction (performance wise) by starting individually and dealing with individual errors. Hopefully its incremental changes to start async and even maybe in background while waiting for user prompt. Async startup shifts from O(n*T) to O(T) startup time for MCP's.