fix: cap mcp below 2.0 so the MCP server can start

[oncerune]

Problem

As of mcp 2.0.0 (released 2026-07-28), a fresh ./setup.sh produces an MCP server that cannot start. MCP clients report only:

-32000: Connection closed

Running the server directly shows the real cause:

ImportError: cannot import name 'McpError' from 'mcp.shared.exceptions'

mcp 2.0.0 renamed McpError to MCPError. fastmcp still imports the old name in fastmcp/server/server.py, and declares only mcp>=1.24.0 with no upper bound. setup.sh installs "mcp[cli]" unpinned, so pip resolves to 2.x and the import fails.

Two things make this harder to diagnose than usual:

• server.py wraps the FliMCP import in try/except ImportError, so the fallback from fastmcp import FastMCP fails for the same underlying reason and the original error is easy to misread as a missing optional dependency.
• pip check reports no broken requirements, because the incompatibility is a renamed symbol rather than a version conflict.

This is not specific to one fastmcp release. fastmcp 3.4.5 also fails against mcp 2.0.0, on a different symbol:

ImportError: cannot import name 'request_ctx' from 'mcp.server.lowlevel.server'

so the constraint belongs on mcp rather than on a particular fastmcp version.

Fix

Cap mcp below 2.0 in setup.sh, and list pydantic-settings explicitly:

-pip install "flights==0.9.0" "mcp[cli]" fastmcp
+pip install "flights==0.9.0" "mcp[cli]>=1.24,<2" fastmcp pydantic-settings

The pydantic-settings entry is for existing fastmcp 2.14.x environments. That version imports pydantic_settings in fastmcp/settings.py without declaring it as a requirement, and relied on it arriving transitively through mcp[cli], which no longer pulls it in. On a fresh install this is a no-op, since fastmcp 3.x declares it properly via fastmcp-slim.

README.md is updated to match. Its setup section previously drifted from setup.sh and also left flights unpinned.

Verification

Clean virtualenv with the updated install line resolves to flights 0.9.0, mcp 1.29.0, fastmcp 3.4.5, and the server reaches:

INFO  Starting MCP server 'flightclaw' with transport 'stdio'

Confirmed against an existing fastmcp 2.14.1 environment as well, where claude mcp get flightclaw goes from Failed to connect to Connected.

Notes

An alternative is to pin fastmcp and let mcp float. That was not chosen because both current fastmcp majors are incompatible with mcp 2.x, so the cap on mcp is the constraint that actually holds. It can be lifted once fastmcp supports mcp 2.x.