MCP servers fail to connect after mcp SDK 2.0.0: Tool.inputSchema renamed to input_schema

[Joi]

Summary

mcp 2.0.0 was published to PyPI on 2026-07-28. amplifier-module-tool-mcp declares an unbounded mcp>=1.0.0, so any install that resolves dependencies after that date picks up 2.0.0 and every configured MCP server stops connecting.

Filing here because issues are disabled on microsoft/amplifier-module-tool-mcp. Fix PR: microsoft/amplifier-module-tool-mcp#10

Symptom

Failed to connect to MCP server 'qmd': unhandled errors in a TaskGroup (1 sub-exception)
Failed to start MCP server 'qmd': MCP server connection failed: unhandled errors in a TaskGroup (1 sub-exception)
Failed to connect to MCP server 'qmd-pim': unhandled errors in a TaskGroup (1 sub-exception)
Failed to connect to Streamable HTTP MCP server 'senzing': 'Tool' object has no attribute 'inputSchema'
Failed to connect to MCP server 'msgvault': unhandled errors in a TaskGroup (1 sub-exception)

The two different error strings are one root cause. _discover_capabilities() runs inside the SDK's anyio TaskGroup on stdio, so the AttributeError is swallowed and resurfaces as the opaque unhandled errors in a TaskGroup (1 sub-exception). Only the streamable-HTTP transport reports it plainly.

This is worth calling out for anyone else debugging it: the server-side logs are clean. ~/.amplifier/logs/mcp-servers/msgvault.log showed a normal startup and exit outcome=ok at the exact failure timestamp — the server launched fine and exited cleanly; the client crashed while listing tools. That makes it look like a transport or timeout problem when it is a Python attribute rename.

Root cause

mcp 2.0.0 renames the mcp.types model fields from camelCase to snake_case. The JSON wire names are preserved as pydantic aliases, so the protocol is unchanged — only Python attribute access changed:

Wire field	mcp 1.x attribute	mcp >= 2.0 attribute
inputSchema	.inputSchema	.input_schema
mimeType	.mimeType	.mime_type

Two affected call sites in amplifier-module-tool-mcp v0.2.2, with different failure modes:

• Tool.inputSchema (client.py:321, streamable_http_client.py:278) — hard AttributeError. Kills capability discovery, so connection fails for every server, on both transports.
• Resource.mimeType (client.py:334, streamable_http_client.py:291) — silent, not a crash. Both sites were already hasattr(resource, "mimeType")-guarded, so on 2.x the guard falls through and every discovered resource reports mime_type: None.

All other mcp API surface this module depends on is unaffected — I verified ClientSession, StdioServerParameters, mcp.client.stdio.stdio_client, mcp.client.streamable_http.streamable_http_client, and mcp.shared._httpx_utils.create_mcp_http_client all still import on 2.0.0, and that CallToolResult.content / ReadResourceResult.contents / GetPromptResult.messages / PromptArgument.{name,description,required} keep their names.

Reproduction

uv venv /tmp/repro -p 3.12
uv pip install --python /tmp/repro/bin/python "amplifier-core==1.6.0" "mcp==2.0.0"
uv pip install --python /tmp/repro/bin/python -e /path/to/amplifier-module-tool-mcp --no-deps
# then connect MCPClient to any stdio MCP server and call connect()

Downgrading to mcp==1.29.0 restores service, which is a usable interim workaround for anyone blocked right now:

uv pip install --python ~/.local/share/uv/tools/amplifier/bin/python "mcp==1.29.0"

That pin is fragile, though — the next amplifier update / uv tool upgrade amplifier can re-resolve and pull 2.0.0 again.

Fix

PR against amplifier-module-tool-mcp adds a small sdk_compat.py with get_input_schema() / get_mime_type() accessors that read whichever attribute the installed SDK exposes, so the module works unchanged on both majors. Verified: full suite passes on mcp==1.29.0 and mcp==2.0.0 (64 each), and end-to-end capability discovery against a real stdio MCP server succeeds on both.

Impact

Anyone who installs or updates Amplifier with MCP servers configured after 2026-07-28. It is not machine-specific and not config-specific — the whole fleet is one dependency resolve away from it.