simple_task filesystem MCP server fails to start: wrong interpreter + HTTP/stdio transport mismatch

[davidlibland]

Running examples/simple_task locally, the environment becomes healthy but configuring MCP servers fails with 503 on POST /apps because the filesystem MCP server never reaches readiness. There are two distinct defects in examples/simple_task/mcp_config.json:

1. Wrong Python interpreter. The launch spec uses "command": "python". With ENV PATH=/app/.venv/bin:$PATH (set in environment/Dockerfile), bare python resolves to the runner venv /app/.venv, whose pyproject.toml explicitly excludes mcp_servers. The server crashes at import:

File ".../filesystem_server/main.py", line 9, in <module>
    from mcp_schema import flatten_schema
ModuleNotFoundError: No module named 'mcp_schema'

Each server is installed into its own venv (/app/mcp_servers/<name>/.venv) by a per-server uv sync, so it must be launched with that interpreter (or via uv run from the server dir, as mcp_config_all_oss_servers.json already does).

2. Transport mismatch (HTTP vs stdio). The config declares "transport": "stdio" (which only tells the gateway how to connect), but filesystem_server/main.py reads MCP_TRANSPORT and defaults to HTTP. With MCP_TRANSPORT unset the server binds an HTTP listener on port 5000 and never speaks stdio, so the gateway times out:

Server 'filesystem_server' FAILED ... No tools found after ~300s (last error: Timeout)

Repro: bash examples/simple_task/run.sh → hangs at "Configuring MCP servers" → 503 Service Unavailable for /apps.

These example-config bugs only surface once the image can build past the private mercor-mcp-shared blocker (#82) fixed by @jason136 in #84 — they were previously masked by the earlier build failure.

A fix PR follows.