chore: enter beta prerelease mode

[felixweinberger]

Switches the changesets prerelease tag from alpha to beta, resets the prerelease version floor, and updates the published instructions to match.

• .changeset/pre.json: tagalpha -> beta (the consumed-changeset history is preserved, so the 141 alpha changesets do not re-apply)
• One new changeset so the beta Version Packages PR has content
• Every workspace package at 2.0.0-alpha.* reset to 2.0.0-beta.0, so the next version run produces a uniform 2.0.0-beta.1 across all published packages (the natural continuation would have been a mixed beta.5/beta.3)
• Published instructions swept: @alpha install/codemod commands -> @beta, alpha release banners -> beta wording, and the two forward-looking alpha passages in the migration guides updated. Historical "if you were on a v2 alpha" guidance is intentionally unchanged.

After this merges: merge the regenerated "Version Packages (beta)" PR and approve the release environment; the packages publish as 2.0.0-beta.1. The beta dist-tag is synced post-publish (prereleases of never-released packages go to latest by documented changesets behavior, which self-resolves at GA).

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist

• 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

[changeset-bot]

🦋 Changeset detected

Latest commit: d954357

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 9 packages

Name	Type
@modelcontextprotocol/server	Patch
@modelcontextprotocol/client	Patch
@modelcontextprotocol/core	Patch
@modelcontextprotocol/server-legacy	Patch
@modelcontextprotocol/codemod	Patch
@modelcontextprotocol/express	Patch
@modelcontextprotocol/hono	Patch
@modelcontextprotocol/fastify	Patch
@modelcontextprotocol/node	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/@modelcontextprotocol/client@2402

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/@modelcontextprotocol/codemod@2402

@modelcontextprotocol/core

npm i https://pkg.pr.new/@modelcontextprotocol/core@2402

@modelcontextprotocol/server

npm i https://pkg.pr.new/@modelcontextprotocol/server@2402

@modelcontextprotocol/server-legacy

npm i https://pkg.pr.new/@modelcontextprotocol/server-legacy@2402

@modelcontextprotocol/express

npm i https://pkg.pr.new/@modelcontextprotocol/express@2402

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/@modelcontextprotocol/fastify@2402

@modelcontextprotocol/hono

npm i https://pkg.pr.new/@modelcontextprotocol/hono@2402

@modelcontextprotocol/node

npm i https://pkg.pr.new/@modelcontextprotocol/node@2402

commit: d954357

[claude]

All feedback from my earlier review rounds has been addressed in bf0a68d and d954357 — versions reset to a uniform 2.0.0-beta.0, published READMEs/codemod instructions now point at @beta, and the remaining forward-looking alpha prose is corrected — so this looks good to me.

Extended reasoning...

Overview

This PR switches the changesets prerelease tag from alpha to beta (.changeset/pre.json), resets every workspace package.json from 2.0.0-alpha.* to 2.0.0-beta.0, adds one changeset so the regenerated Version Packages PR has content, and sweeps published instructions (package READMEs, codemod README, migration guides) from @alpha install/codemod commands and alpha-release banners to beta wording. No runtime or library code is touched — the diff is version strings, JSON release metadata, and documentation prose.

Security risks

None. There is no executable code change; the only operational effect is on the release pipeline (the next publish goes out under the npm beta dist-tag). Publishing itself still requires merging the separate Version Packages PR and approving the release environment, so there is a human gate downstream of this merge.

Level of scrutiny

Moderate. Release-mechanics changes can have non-obvious consequences in changesets internals (my earlier review rounds flagged exactly that: the prerelease counter is derived from package.json, and the published READMEs ship in the tarballs). Both rounds of feedback — the two blocking issues (stale @alpha install instructions in published READMEs/migration docs; the counter not resetting, which would have produced beta.5/beta.3 instead of a uniform first beta) and the three follow-up nits (remaining "until the next published alpha" passages in upgrade-to-v2.md, the over-broad alpha-typings claim in support-2026-07-28.md, and the missed examples/package.json) — are addressed by commits bf0a68d and d954357. With all package versions at 2.0.0-beta.0, the next changeset version run produces a uniform 2.0.0-beta.1, matching the PR description.

Other factors

The bug hunting system found no issues on the latest revision. The decision to enter beta is itself a maintainer-level release decision that the PR title embodies; the mechanics of executing it are now consistent and mechanical. The consumed-changeset history in pre.json is preserved, so the prior alpha changesets will not re-apply.