Problem
When an MCP server exceeds startup_timeout_sec (default 10s), OpenCode marks it as FAILED and its tools become unavailable for the entire session:
⚠ MCP client for `relace_id_VI4FGW` timed out after 10 seconds.
⚠ MCP startup incomplete (failed: relace_id_VI4FGW)
A server that takes 12 seconds isn't broken — it's just slow. Treating a timeout as a hard failure is a false negative that blocks users from tools that would work fine moments later.
Common causes of slow MCP startup
uvx-based servers have variable cold-start times (3–15s) depending on package cache state
- Remote MCP servers depend on network latency
- Wrapper scripts that parse config or set up environments add overhead
- Multiple servers starting concurrently compete for CPU/network during the first 10 seconds
Proposed behavior
When an MCP server exceeds the startup timeout:
- Promote to lazy-loaded state instead of marking as failed
- Continue initialization in the background — don't kill the process
- Log an info-level notice (not a warning/error):
ℹ relace is still starting, tools will be available when ready
- Make tools available as soon as the server finishes its MCP handshake
- Only mark as FAILED if the server process actually exits or crashes
Current flow
Server slow → 10s timeout → ⚠ ERROR → server marked FAILED → tools unavailable
Proposed flow
Server slow → timeout threshold → ℹ "still starting..." → background init continues → tools available when ready
Prior art
Claude Code handles this well with its deferred tool loading mechanism — MCP servers register their tool manifests lazily, and tools are loaded on demand. There's no startup race condition.
Environment
- OpenCode v1.2.1
- macOS (Darwin 24.6.0, ARM64)
- Server that triggered this:
relace-mcp via uvx (startup time ~7s warm, 12s+ cold)
Problem
When an MCP server exceeds
startup_timeout_sec(default 10s), OpenCode marks it as FAILED and its tools become unavailable for the entire session:A server that takes 12 seconds isn't broken — it's just slow. Treating a timeout as a hard failure is a false negative that blocks users from tools that would work fine moments later.
Common causes of slow MCP startup
uvx-based servers have variable cold-start times (3–15s) depending on package cache stateProposed behavior
When an MCP server exceeds the startup timeout:
ℹ relace is still starting, tools will be available when readyCurrent flow
Proposed flow
Prior art
Claude Code handles this well with its deferred tool loading mechanism — MCP servers register their tool manifests lazily, and tools are loaded on demand. There's no startup race condition.
Environment
relace-mcpviauvx(startup time ~7s warm, 12s+ cold)