refactor(mcp): migrate from MCP SDK v1 to v2.0.0b1

[jonpspri]

Summary

Migrates all MCP client and server code from MCP Python SDK v1 → v2.0.0b1, applying every breaking API change.

Closes: #129

Breaking Changes Applied

v1	v2
streamablehttp_client	streamable_http_client
McpError	MCPError
mcp.types	mcp_types (separate package)
FastMCP	MCPServer
SSLCapableFastMCP	SSLCapableMCPServer
MCPServer(host=..., port=...)	host/port passed to run methods only
streamable_http_client returns (read, write, get_session_id)	returns (read, write)

Behavioral Changes

• Session termination: removed manual __terminate_http_session(); v2 SDK handles DELETE via terminate_on_close=True
• HTTP client: replaced _http_client_factory pattern with pre-built httpx.AsyncClient
• Transport security: transport_security now stored as instance attr and passed to streamable_http_app() instead of __init__
• Config access: self.settings.host/port → self.server_config.host/port

Removed

• _session_id, _get_session_id, _http_client_factory, __terminate_http_session
• Obsolete test classes (TestTerminateHTTPSession, TestTerminateHTTPSessionErrors, TestHTTPClientFactory)

Tests

All 190 MCP unit tests pass.

Dependencies

• mcp == 2.0.0b1
• mcp-types == 2.0.0b1

Migration guide reference

https://py.sdk.modelcontextprotocol.io/v2/migration/

[araujof]

Good migration overall! Reviewed the v2 migration and pushed fixes for everything actionable. Two real bugs found (both fixed), plus a batch of cleanups and test gaps.

Fixes pushed

Bugs

• runtime.py — HTTP 421 for non-localhost servers. streamable_http_app() was called without host=, so the v2 SDK defaulted to host="127.0.0.1" and auto-applied a localhost-only DNS rebinding allowlist whenever transport_security was None. Any server bound to 0.0.0.0 would have rejected every non-localhost request with HTTP 421. Now passes host=self.server_config.host. Verified against the real SDK: with host="0.0.0.0" no allowlist is applied; localhost binds stay protected.
• client.py — httpx client leak. The v2 SDK does not close a caller-provided http_client (streamable_http.py:567 skips it when client_provided=True), so the client created each connection attempt leaked. Now entered into the exit stack right after creation — before the transport — so LIFO teardown fires the terminate_on_close DELETE while the client is still open, then closes the client. No leak on success or failure.

Cleanups:

• Fixed spurious find-replace whitespace in 6 runtime.py f-strings/dict values.
• Corrected 8 broken doctests (server.settings.host/port → server.server_config.*; those fields don't exist on MCPServer v2).
• Simplified getattr(self, '_transport_security', None) to direct attribute access.
• Updated stale "Fast MCP" docstring text and class Examples: indentation.
• Updated the plugin scaffold template to mcp==2.0.0b1 + mcp-types==2.0.0b1 (was still on v1, which would have generated plugins incompatible with the v2 client).
• Removed unused ErrorData import and dead plugin._session_id = None test setup; renamed http_client_instance → http_client.

Test coverage for the gaps:

• Split test_invoke_hook_reconnects_on_session_terminated — the session-terminated success path was dead code shadowed by a second plugin setup, so the reconnect-then-retry path was never actually tested. Restored it and re-added the separate no-reconnect-on-other-errors test.
• Added a test asserting streamable_http_client is called with a pre-built http_client and terminate_on_close=True (the v2 API change + DELETE-on-close behavior that replaced the removed __terminate_http_session).
• Added tests that UDS servers populate _transport_security with DNS rebinding protection, non-UDS servers leave it unset, and run_streamable_http_async forwards both transport_security and the real bind host to streamable_http_app().

Questions

1. Dependency pins — pyproject.toml pins mcp==2.0.0b1 and mcp-types==2.0.0b1 exactly. In a library's install_requires, an exact pin to a pre-release becomes a hard constraint on every downstream consumer, and once mcp 2.0.0 stable ships, consumers are blocked from upgrading until we cut a new release. Do you want to relax these to a range (e.g. >=2.0.0b1,<3), or is the exact pin intentional for beta stability until GA? I updated the scaffold template to match whatever we land on here.

2. MIGRATION_MCP_V2.md — the 524-line strategy doc is committed at the repo root. It's useful as a record, but at the root next to README/CHANGELOG a future contributor might read its "planned" sections as outstanding work. Keep it at root, move it under docs/, or drop it now that the migration is done?

[jonpspri]

In replay to questions above:

Dependency pins — pyproject.toml pins mcp==2.0.0b1 and mcp-types==2.0.0b1 exactly. In a library's install_requires, an exact pin to a pre-release becomes a hard constraint on every downstream consumer, and once mcp 2.0.0 stable ships, consumers are blocked from upgrading until we cut a new release. Do you want to relax these to a range (e.g. >=2.0.0b1,<3), or is the exact pin intentional for beta stability until GA? I updated the scaffold template to match whatever we land on here.

Yes, the dependency pins are only in place until 2.0.0 is GA, at which point PyPI versioning will take over again and they can be relaxed to a range. We will not push this PR prior to GA.

MIGRATION_MCP_V2.md — the 524-line strategy doc is committed at the repo root. It's useful as a record, but at the root next to README/CHANGELOG a future contributor might read its "planned" sections as outstanding work. Keep it at root, move it under docs/, or drop it now that the migration is done?

Same response. We will remove this document from the PR prior to merge -- the squash will take it out of git history.

I'm switching the PR to draft for now... didn't realize it wasn't that way already.