Summary
examples/getting_started/mcp_tools.py fails at import time on a clean install
from PyPI. The MCP example resource imports mcp.server.fastmcp, which no
longer exists in mcp 2.x — it was renamed to mcp.server.mcpserver
(FastMCP → MCPServer).
Because pyproject.toml declares mcp>=1.0 with no upper bound, a fresh
pip install google-antigravity resolves to mcp==2.0.0, so the shipped MCP
examples cannot run on any platform with a clean environment.
Environment
google-antigravity 0.1.12 (installed from PyPI)mcp 2.0.0 (resolved automatically as a transitive dependency)- Python 3.12.10
- Windows 11 — but the failure is platform-independent, it happens at import
Reproduction
python -m venv .venv
.venv/bin/pip install google-antigravity # pulls mcp==2.0.0
export GEMINI_API_KEY="..."
python ./examples/getting_started/mcp_tools.py
Actual result
Traceback (most recent call last):
File "examples/getting_started/mcp_tools.py", line 40, in <module>
from resources import mcp_server
File "examples/resources/mcp_server.py", line 25, in <module>
from mcp.server.fastmcp import server
ModuleNotFoundError: No module named 'mcp.server.fastmcp'
Expected result
The example runs and demonstrates the stdio / SSE / streamable-HTTP transports.
Root cause
pyproject.toml:40 declares "mcp>=1.0" — unbounded, so 2.x is selected.examples/resources/mcp_server.py:25 imports mcp.server.fastmcp, and
:31/:35 reference server.FastMCP. Both were removed in mcp 2.0.
This affects all three transports in mcp_tools.py, since they all import
the same helper module.
Suggested fix
Either cap the dependency (mcp>=1.0,<2) or, preferably, update the example to
the 2.x API:
from mcp.server.mcpserver import MCPServer
mcp = MCPServer(name="Pirate Math")
@mcp.tool()
def pirate_multiply(a: int, b: int) -> str:
...I verified the 2.x API works with the SDK: an in-process MCPServer served over
streamable HTTP connects fine via types.McpStreamableHttpServer, tool calls
execute, and policy.allow(server, [...]) / policy.deny(server, [...]) behave
as documented. So only the example needs porting — the SDK's MCP support itself
is fine.
Secondary issue in the same file
examples/getting_started/mcp_tools.py hardcodes command="python3" (lines 52,
92, 123) to spawn the stdio server. On Windows python3 is typically absent, and
when present as a Store alias it points at the system interpreter rather than the
virtualenv running the example — which will not have mcp installed. Using
sys.executable would make the stdio transport portable.
Minor observation
MCPServer calls logging.basicConfig(level=INFO)
(mcp/server/mcpserver/utilities/logging.py:39), which raises the root log
level for the whole process. That makes the SDK's
logging.info("RAW WS MSG: %s", raw_msg) (local_connection.py:521) flood
stdout for anyone using MCP. Not an SDK bug, but demoting that line to DEBUG
would spare users a lot of noise.
Summary
examples/getting_started/mcp_tools.pyfails at import time on a clean installfrom PyPI. The MCP example resource imports
mcp.server.fastmcp, which nolonger exists in
mcp2.x — it was renamed tomcp.server.mcpserver(
FastMCP→MCPServer).Because
pyproject.tomldeclaresmcp>=1.0with no upper bound, a freshpip install google-antigravityresolves tomcp==2.0.0, so the shipped MCPexamples cannot run on any platform with a clean environment.
Environment
google-antigravity0.1.12 (installed from PyPI)mcp2.0.0 (resolved automatically as a transitive dependency)Reproduction
Actual result
Expected result
The example runs and demonstrates the stdio / SSE / streamable-HTTP transports.
Root cause
pyproject.toml:40declares"mcp>=1.0"— unbounded, so 2.x is selected.examples/resources/mcp_server.py:25importsmcp.server.fastmcp, and:31/:35referenceserver.FastMCP. Both were removed in mcp 2.0.This affects all three transports in
mcp_tools.py, since they all importthe same helper module.
Suggested fix
Either cap the dependency (
mcp>=1.0,<2) or, preferably, update the example tothe 2.x API:
I verified the 2.x API works with the SDK: an in-process
MCPServerserved overstreamable HTTP connects fine via
types.McpStreamableHttpServer, tool callsexecute, and
policy.allow(server, [...])/policy.deny(server, [...])behaveas documented. So only the example needs porting — the SDK's MCP support itself
is fine.
Secondary issue in the same file
examples/getting_started/mcp_tools.pyhardcodescommand="python3"(lines 52,92, 123) to spawn the stdio server. On Windows
python3is typically absent, andwhen present as a Store alias it points at the system interpreter rather than the
virtualenv running the example — which will not have
mcpinstalled. Usingsys.executablewould make the stdio transport portable.Minor observation
MCPServercallslogging.basicConfig(level=INFO)(
mcp/server/mcpserver/utilities/logging.py:39), which raises the root loglevel for the whole process. That makes the SDK's
logging.info("RAW WS MSG: %s", raw_msg)(local_connection.py:521) floodstdout for anyone using MCP. Not an SDK bug, but demoting that line to
DEBUGwould spare users a lot of noise.