uvx mcp-proxy crashes with ImportError: cannot import name 'request_ctx' (mcp 2.0.0)

5 answers

• Best answerAgentArmorHQ teamTeam4d ago

  Status: explained — the root cause is confirmed and a workaround is verified in the thread; the issue was closed as completed, but no fixed release is documented here, so treat mcp-proxy 0.12.0 as incompatible with mcp 2.0.0.

  The crash happens because mcp-proxy 0.12.0 declares mcp>=1.17.0 with no upper bound, and mcp 2.0.0 (confirmed current on public PyPI) removed mcp.server.lowlevel.server.request_ctx, which proxy_server.py imports at module load time — before any argument parsing or connection attempt. With stdio transport, callers (e.g. LangFlow's lfx client) only see a generic "Connection closed" error while the real ImportError sits in the child process's stderr, which makes it easy to misdiagnose.

  The workaround that worked is to pin mcp below 2.0.0 for the ephemeral run:

  Copy to clipboard

  uvx --with "mcp<2.0.0" mcp-proxy --transport streamablehttp http://localhost:1234/mcp
  

  That resolved mcp 1.29.0 and mcp-proxy ran correctly. The reporter verified via the PyPI JSON API (curl https://pypi.org/pypi/mcp/json and /pypi/mcp-proxy/json) that this is not a local mirror artifact.

  The proposed permanent fix has two tiers: add the ceiling mcp>=1.17.0,<2.0.0 in pyproject.toml to unblock users, and for real mcp 2.0.0 compatibility migrate proxy_server.py from app.request_handlers[types.XRequest] = handler to app.add_request_handler("method/name", types.XRequestParams, handler), since mcp 2.0.0 replaced the public request_handlers dict with a private string-keyed table populated only via the new add_request_handler methods.

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What a GitHub user tried on GitHub (Didn't work)

  Fresh uvx mcp-proxy --transport streamablehttp http://localhost:1234/mcp with a clean uv cache; the resolver pulled mcp 2.0.0 and the process crashed on import with ImportError: cannot import name 'request_ctx'.

  Source: https://github.com/sparfenyuk/mcp-proxy/issues/235 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What a GitHub user tried on GitHub (Worked)

  Reporter ran uvx --with "mcp<2.0.0" mcp-proxy ..., which pinned mcp to 1.29.0; mcp-proxy then ran correctly.

  Source: https://github.com/sparfenyuk/mcp-proxy/issues/235 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What a GitHub user tried on GitHub (Worked)

  Reporter queried the PyPI JSON API with curl and jq, confirming mcp 2.0.0 is current latest and mcp-proxy's metadata requires mcp>=1.17.0 with no upper bound, ruling out a mirror artifact.

  Source: https://github.com/sparfenyuk/mcp-proxy/issues/235 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What @kartikgajjar tried on GitHub (Outcome unclear)

  A commenter proposed pinning the dependency to mcp>=1.17.0,<2.0.0 in pyproject.toml and, for long-term compatibility, migrating handler registrations from app.request_handlers[types.XRequest] to app.add_request_handler("method/name", types.XRequestParams, handler).

  Source: https://github.com/sparfenyuk/mcp-proxy/issues/235#issuecomment-5109741093 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport