upgrade-pilot-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| analyze_projectB | Read package metadata, lockfiles, and config files to fingerprint the upgrade surface. |
| detect_upgrade_pathsC | Compute constrained, package-aware upgrade steps for the supported route. |
| find_breaking_changesD | Attach official migration references and curated risk areas to selected packages. |
| scan_repo_for_deprecationsC | Find high-signal repo-level patterns that are known to complicate upgrades. |
| generate_upgrade_planC | Turn dependency intelligence and repo findings into an ordered upgrade plan. |
| apply_safe_codemodsC | Run deterministic, local codemods that are explicitly allowed by the v1 safety model. |
| validate_upgradeC | Execute type-check, lint, test, and build commands when they are available. |
| run_upgrade_pipelineB | Run analyze → paths → breaking changes → deprecations → plan in a single call. Returns a compact summary to save tokens while storing all artifacts for later resource access. |
| write_upgrade_pr_summaryC | Generate a reviewer-friendly markdown summary of the planned upgrade route. |
| install_upgradeC | Install specific package versions using the detected package manager (npm/yarn/pnpm). |
| check_compatibilityA | Verify peerDependency compatibility for a set of packages before installing. |
| create_checkpointB | Tag current HEAD so the upgrade can be rolled back if needed. |
| restore_checkpointC | Hard-reset to a previously created checkpoint tag. |
| list_checkpointsC | List all upgrade-pilot checkpoint tags in the repository. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| plan_upgrade_route | Guide an agent through the safest upgrade flow for a JS/TS repository. |
| draft_upgrade_pr | Turn upgrade artifacts into a concise PR summary for human reviewers. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| latest-analysis | Most recent output from analyze_project. |
| latest-paths | Most recent output from detect_upgrade_paths. |
| latest-breaking-changes | Most recent output from find_breaking_changes. |
| latest-findings | Most recent output from scan_repo_for_deprecations. |
| latest-plan | Most recent output from generate_upgrade_plan. |
| latest-validation | Most recent output from validate_upgrade. |
| latest-pipeline | Most recent output from run_upgrade_pipeline. |
| latest-codemods | Most recent output from apply_safe_codemods. |
| latest-summary | Most recent output from write_upgrade_pr_summary. |
TDQS
Scored across 14 tools
Each tool targets a distinct phase or operation in the upgrade workflow (e.g., analysis, planning, codemods, validation, rollback). There is no overlap in purpose, and the descriptions clearly differentiate them.
Tool names follow a consistent verb_noun pattern (e.g., generate_*, analyze_*, detect_*, apply_*) with one exception: run_upgrade_pipeline vs. the more descriptive 'run' verbs elsewhere. Overall the pattern is clear and predictable.
14 tools is a reasonable count for a specialized upgrade assistant. Each tool covers a needed step, and the set is not overly large or sparse for its domain.
The tool set provides end-to-end lifecycle coverage: project analysis, upgrade path detection, breaking changes, safe codemods, validation, installation, checkpoint/rollback, and PR summary. No obvious gaps in the upgrade workflow.