Upgrading a server

Identify the installed release

Read the project's resolved SDK package or use the docs server's resolve_version. For a monorepo with several installations, supply the npm/pnpm workspace path or an exact installedVersion. Ambiguous lockfiles return an error rather than choosing the first package record. A manifest range describes allowed versions, not what is installed.

{ "workspace": "packages/api", "packageJson": "<file text>", "lockfile": "<file text>" }

Keep lockfiles local unless you deliberately choose to share their relevant content. The resolver does not need credentials or your whole repository.

Read the changes and establish a baseline

Pin a docs endpoint to the installed version. Call whats_changed with the old and target releases, then follow affected API references. Check companion plugin/adapters too. Run existing contract, access and deployment checks before editing dependencies; save sanitized output with its versions and date.

Release frequency does not tell you whether an API changed. For each change affecting your server, record the previous behavior, the new behavior, whether application or client code must change, and the migration check that covers it. Keep additions, fixes and intentional breaking changes distinct. The production evaluation explains the limits of release and adoption signals; a fixture result is not a support guarantee.

Reproduce a bounded upgrade

The repository's upgrade check uses the reporting download as a fixture. It installs FrontMCP 1.9.2, runs its tests and captures tool contracts, then installs the documented release and repeats the same checks. It retains before/after output and reports differences; it does not assert every application is safe to upgrade.

node scripts/check-upgrade.mjs

This operation installs dependencies in a temporary project. Its README and script are included in the evaluation download. Network access to npm and Node.js 24+ are required. It does not deploy or modify your application.

Inspect the recorded contract

The before/after record names both releases, lists the actual schemas, successful result and expected refusal, and records whether the selected contract changed. It is a local fixture observation. The same code is installed independently with each dependency set; it does not test a production database migration.

Upgrade and roll back deliberately

Update SDK, CLI, testing and companion packages to compatible releases. Regenerate the lockfile, run contract/auth checks and build for your target. Exercise real client connections and widget behavior in preview. Keep previous artifact, configuration and lockfile available; database migrations need their own rollback or forward-recovery plan.

If a contract changes intentionally, record the before/after result and update the affected clients explicitly. A green documentation test is not a replacement for your application's checks. See Versions and release notes.