[v2.0.x] Point imports of mcp.server.fastmcp at the migration guide
Backport of #3388 onto v2.0.0 so it can ship as 2.0.1. v2.0.x was cut at the v2.0.0 tag; this PR is the only thing on top of it.
Three cherry-picks (-x, all applied cleanly):
- #3380 — needed here because
publish-pypi.ymlruns from the tagged commit, and the 2.0.0-era workflow would rebuild with floating hatchling and hit the same Metadata 2.5 upload rejection v2.1.0 did. - The two commits from #3388:
src/mcp/server/fastmcp.pyraisingModuleNotFoundErrorwith the pointer, the API-reference exclusion, tests, and the twodocs/migration.mdclarity edits.
Motivation and Context
See #3388. A 2.0.1 reaches installs pinned to mcp==2.0.* / <2.1; everyone unpinned gets it from the next release off main.
How Has This Been Tested?
On this branch: ./scripts/test (5585 passed, 100% coverage, strict-no-cover clean), pyright, ruff, scripts/docs/build_config.py (no fastmcp page), and the import by hand. uv-dynamic-versioning resolves the branch as 2.0.1.devN, so a v2.0.1 tag here yields 2.0.1.
Breaking Changes
None.
Types of changes
- Bug fix (non-breaking change which fixes an issue)
- New feature (non-breaking change which adds functionality)
- Breaking change (fix or feature that would cause existing functionality to change)
- Documentation update
Checklist
- I am assigned to the linked issue (or it is labeled
help wanted, or I'm a maintainer) - I have disclosed any AI assistance and can explain the change in my own words
- I have read the MCP Documentation
- My code follows the repository's style guidelines
- New and existing tests pass locally
- I have added appropriate error handling
- I have added or updated documentation as needed
Additional context
Release: gh release create v2.0.1 --target <merge sha on v2.0.x> --latest=false so 2.1.0 stays "Latest". deploy-docs.yml only fires from main, so the docs site is unaffected by this branch. If you'd rather keep #3380 as its own commit on v2.0.x, rebase-merge instead of squash.