Bug Report

Description

The streamable HTTP proxy (pkg/transport/proxy/streamable/streamable_proxy.go) has a hardcoded 30-second response timeout (defaultResponseTimeout). Any MCP tool call that takes longer than 30 seconds returns HTTP 504 Gateway Timeout, even though the backend MCP server is still processing the request.

This only affects MCP servers running with stdio transport — the default for most container-based servers (npx://, uvx://, and Docker images without a native HTTP server). Servers that natively use --transport sse or --transport streamable-http (like fetch) go through the transparent proxy (pkg/transport/proxy/transparent/), which has no such timeout.

Steps to Reproduce

1. Run a stdio transport MCP server with thv run (e.g., time, or any npx/uvx-based server)
2. Call an MCP tool that takes longer than 30 seconds to respond
3. The proxy returns HTTP 504 after exactly 30 seconds

Note: Servers with native HTTP transport (like fetch, which uses streamable-http) are not affected — they use a different proxy code path.

Expected Behavior

Long-running MCP tool calls should complete successfully. A 30-second timeout is too aggressive for many legitimate use cases (e.g., tools that query large datasets, perform complex searches, or interact with slow external APIs).

Actual Behavior

The proxy returns HTTP 504 Gateway Timeout after 30 seconds. The three affected code paths are:

• handleSingleRequest — JSON response path
• handleSingleRequestSSE — SSE streaming path
• processSingleMessage — batch processing path

All three use the same defaultResponseTimeout constant at line 33.

Proposed Fix

1. Bump the default from 30s to 5m (sufficient for most use cases without configuration)
2. Add TOOLHIVE_PROXY_RESPONSE_TIMEOUT environment variable for users who need a different value (follows the existing TOOLHIVE_REMOTE_HEALTHCHECKS pattern for env var overrides)

Environment

• ToolHive version: v0.11.1 (and current main)
• OS: macOS (the code path is platform-independent, so likely affects Linux too)