[Feature] Full support for MCP Python SDK v2 (mcp 2.0.0 / 2026-07-28 spec)

Summary

Request for full support of the MCP Python SDK v2 (mcp==2.0.0, stable since 2026-07-28, implementing the 2026-07-28 protocol revision).

This is distinct from #321 and #322 — those report the Server.__init__() positional-arg crash and suggest a one-line keyword-arg fix. That fix only prevents the crash; it does not make fastapi-mcp actually work against the v2 SDK. This issue tracks the broader ask: a version of fastapi-mcp that is built for and tested against mcp>=2.0.

Why this matters

mcp==2.0.0 is a major rework. From the official release notes:

This is v2 of the MCP Python SDK, the current stable release line. It is a major rework of the SDK, both to support the 2026-07-28 MCP specification and to fix long-standing architectural issues.

Key breaking changes that affect fastapi-mcp:

1. HTTP stack migration: httpx -> httpx2. v2 depends on httpx2>=2.5.0 and rebuilds the Streamable HTTP transport on top of it. Any code in fastapi-mcp that touches the transport layer, client construction, or ASGI plumbing needs to be re-evaluated against the new stack.
2. New top-level API surface. v2 introduces mcp.server.MCPServer / mcp.Client with a much simpler API (e.g. @mcp.tool() decorator, type hints as schema). The lowlevel Server class signature changed (keyword-only args after name), which is the crash already tracked in #321.
3. 2026-07-28 protocol revision. Stateless single-exchange POST (no initialize handshake, no session ID), removal of WebSocket transport. fastapi-mcp currently assumes the 2025-era session lifecycle.

A keyword-arg patch keeps fastapi-mcp compiling but it still runs on the legacy transport and API — it is not real v2 support.

Ecosystem impact (we are blocked on both sides)

We maintain a project (ARL — Asset Reconnaissance Lighthouse) that uses MCP in both directions and shares a single mcp package install:

Component	Package	Current constraint
MCP server (expose our API)	fastapi-mcp==0.4.0	mcp>=1.12.0 (no upper bound; breaks at >=1.28 with "Task group is not initialized")
MCP client (AI agent connects out)	openai-agents	pins mcp>=1.19,<2.0, uses httpx-based transport

Because openai-agents also pins mcp<2.0, both upstream packages must release v2-compatible versions before we can migrate. We are filing this issue so fastapi-mcp has a tracked v2 milestone alongside whatever openai-agents plans.

What we are asking for

• A fastapi-mcp release (0.5.x or 1.0) that officially targets mcp>=2.0 and is tested against the v2 SDK + httpx2.
• A temporary mcp>=1.12,<2 upper bound on the current 0.4.x line so downstream lockfiles do not accidentally resolve mcp==2.0.0 and crash at startup (the crash in #321).
• Any roadmap / timeline you can share for v2 support, so we can plan our migration.

Environment

• fastapi-mcp==0.4.0
• mcp==2.0.0 (stable, 2026-07-28)
• Python 3.13

Thank you for the project — happy to help test a v2 branch if one exists.