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
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
What Needs Maintaining
mcpSDK behind the[mcp]extra and the dev group, andsrc/docvet/mcp/__init__.pymcp>=1.6,<2(lockfile at 1.29.1)mcp>=2.1,<3Why Now
The grouped Dependabot schedule added in #432 immediately opened #434, which widens the constraint to
<3and bumps to 2.1.1. Its CI is red on every job that imports the server: mcp 2.x renamedFastMCPtoMCPServerand moved it tomcp.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) becomesfrom mcp.server.mcpserver import MCPServermcp_server = FastMCP("docvet")at module scope, two@mcp_server.tool()decorators, andmcp_server.run(transport="stdio")ImportErrormessage and themcp_serverattribute docstring nameFastMCPClientSession,StdioServerParameters,stdio_clientintests/unit/test_mcp.pyandtests/integration/test_mcp.py. Confirm those paths survive in 2.x; the migration guide lists other renamed APIs beyond the server class.result.content[0].textfromcall_tool; check the 2.x content-block types still carry.textuv.lockgainsmcp-typesas a new transitive dependencyDo #428 first or alongside: it moves the rule catalog out of
docvet.mcpsodocvet checkstops importing the SDK at all. That shrinks the blast radius of this bump to thedocvet mcpcommand 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,<3with a runtime shim for both names) or moves to>=2.1,<3outright. 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(theunresolved-importonmcp.server.fastmcpis the first symptom)uv audituv run docvet check --alldocvet mcpstarts and answersdocvet_checkanddocvet_rulesfrom a real clientBMAD Workflow
Maintenance work usually skips the story pipeline:
/bmad-bmm-quick-spec->/bmad-bmm-quick-devfor anything non-trivial