Skip to content

Chore: migrate the MCP server to mcp 2.x (FastMCP renamed to MCPServer) #435

Description

@Alberto-Codes

What Needs Maintaining

  • Target: the mcp SDK behind the [mcp] extra and the dev group, and src/docvet/mcp/__init__.py
  • Current version: mcp>=1.6,<2 (lockfile at 1.29.1)
  • Target version: mcp>=2.1,<3

Why Now

The grouped Dependabot schedule added in #432 immediately opened #434, which widens the constraint to <3 and bumps to 2.1.1. Its CI is red on every job that imports the server: mcp 2.x renamed FastMCP to MCPServer and moved it to mcp.server.mcpserver, and the SDK's own error message points at the migration guide (https://py.sdk.modelcontextprotocol.io/v2/migration/). Until this lands, every weekly Dependabot rollup for the uv group will carry the same red bump, and #434 cannot merge as-is.

Expected Fallout

The server's SDK surface is small, which is the good news:

  • from mcp.server.fastmcp import FastMCP (one lazy import inside a guarded block) becomes from mcp.server.mcpserver import MCPServer
  • mcp_server = FastMCP("docvet") at module scope, two @mcp_server.tool() decorators, and mcp_server.run(transport="stdio")
  • The ImportError message and the mcp_server attribute docstring name FastMCP
  • Tests use the client side only: ClientSession, StdioServerParameters, stdio_client in tests/unit/test_mcp.py and tests/integration/test_mcp.py. Confirm those paths survive in 2.x; the migration guide lists other renamed APIs beyond the server class.
  • The integration test reads result.content[0].text from call_tool; check the 2.x content-block types still carry .text
  • uv.lock gains mcp-types as a new transitive dependency

Do #428 first or alongside: it moves the rule catalog out of docvet.mcp so docvet check stops importing the SDK at all. That shrinks the blast radius of this bump to the docvet mcp command and unblocks the pydantic-settings bump #425 held back for the same reason.

Decide whether the published extra keeps a 1.x floor (>=1.6,<3 with a runtime shim for both names) or moves to >=2.1,<3 outright. The second is simpler and the extra is opt-in, so a major bump of the extra's floor is acceptable in a minor docvet release; note it in the changelog either way.

Verification

  • uv run pytest (both mcp test modules import cleanly)
  • uv run ruff check . / uv run ruff format --check .
  • uv run ty check (the unresolved-import on mcp.server.fastmcp is the first symptom)
  • uv audit
  • uv run docvet check --all
  • docvet mcp starts and answers docvet_check and docvet_rules from a real client
  • chore(deps): bump mcp from 1.29.1 to 2.1.1 in the python-dependencies group #434 closes as superseded, or is rebased onto the migration

BMAD Workflow

Maintenance work usually skips the story pipeline:

  • /bmad-bmm-quick-spec -> /bmad-bmm-quick-dev for anything non-trivial
  • Straight to a PR for routine bumps

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    choreMaintenance and housekeepingdependenciesPull requests that update a dependency file

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions