llm-migrate
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LLM_MIGRATE_REGISTRY | No | Path to a registry root containing models/. By default the repository registry is discovered automatically. |
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": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| resolve_modelA | Match an identifier against the local registry, tolerating vague input. Always check here before researching a model: regional Bedrock
inference-profile prefixes, version suffixes, spacing, and vague platform
names are normalized deterministically. |
| get_model_profileC | Return a validated local registry model profile. |
| check_model_lifecycleB | Interpret reviewed lifecycle facts at a fixed date without live research. |
| compare_modelsC | Return explicit same/different/unsupported/unknown comparison states. |
| recommend_modelsC | Hard-filter and deterministically rank compatible registry models. |
| scan_applicationA | Scan a local Python application into a normalized coupling inventory.
|
| query_live_pricingB | Opt in to an OpenRouter pricing inquiry; canonical registry facts are unchanged. |
| estimate_migration_costA | Estimate recurring token cost from checked-in canonical pricing. |
| analyze_promptC | Conservatively analyze prompt characteristics without inference. |
| prepare_prompt_migrationB | Prepare a prompt migration specification without rewriting the prompt. |
| validate_promptC | Statically validate prompt assumptions against target registry facts. |
| analyze_invocationD | Analyze provider invocation and adjacent tool/output couplings. |
| prepare_invocation_migrationC | Prepare a target invocation contract without editing application files. |
| generate_migration_planB | Generate an actionable application-level migration manifest without writing files. |
| generate_migration_reportC | Generate a human-readable report from the integrated migration workflow. |
| generate_eval_suiteC | Bind a deterministic evaluation corpus to a migration manifest. |
| run_migration_evalC | Run source and target with user-owned local provider credentials. |
| compare_outputsC | Compare one paired source/target evaluation result deterministically. |
| analyze_regressionsB | Return a structured categorized regression report for an evaluation run. |
| optimize_migrationB | Return bounded, review-only recommendations from observed regression evidence. |
| propose_registry_updateB | Plan a registry update from supplied evidence without editing canonical files. |
| create_migration_research_requestC | Scan locally and bound explicit user-scoped research to missing/stale facts. |
| validate_research_resultC | Run the deterministic scope/policy gate over one research artifact. |
| validate_evidence_reviewC | Check that an independent evidence review actually covers the research artifact. |
| build_research_consensusC | Deterministically combine research and review; agent agreement is not evidence. |
| build_session_registryA | Finalize a run workspace into an immutable, expiring session overlay. Research and review artifacts must already exist in the workspace; any stage still needing an agent fails closed instead of doing hidden work. |
| generate_session_migration_planC | Plan a migration over the canonical registry plus one run's session overlay. |
| start_migrationA | Start a guided migration run; the preferred entry point for a full migration. Matches both models against the local registry first (tolerating vague or
platform-decorated identifiers). If either identifier needs confirmation,
nothing is written and the result carries candidates to show the user.
Otherwise the run workspace is created (default
|
| get_research_promptsA | Ready-to-run researcher and reviewer prompts for a run's research request. Renders one bounded, scope-isolated prompt pair per remaining scope from
|
| list_adaptation_tasksB | Per-file adaptation worklist for a started migration run. Call it once. Derived from the run's migration plan (using its session overlay when one
was built). |
| get_blocker_resolutionsA | Questions plus evidence-backed options for every unresolved blocker. For each blocker of a started run, returns the question to ask the user and 2-5 registry-backed options (retarget / redesign / correction / accept-with-rationale), each with consequences, evidence URLs, and the exact record_blocker_decision call to make once the user chooses. Present questions, options, and evidence VERBATIM, one blocker at a time; never choose on the user's behalf. Also reports how previously recorded decisions applied, including stale ones. |
| record_blocker_decisionA | Record the user's decision for one blocker; decisions are durable.
|
| submit_adapted_promptA | Validate and store one refined prompt for the target model. Adapt minimally: keep the original wording and structure except where a
listed model difference or evidence-linked guidance item requires a
change, and cite that evidence in |
| submit_adapted_fileA | Store one finalized post-adaptation application file for review.
|
| finalize_migrationA | Write the run's manifest, report, and adaptation change log under output/. The report includes, per adapted file, what changed and why, plus the affected files that still lack an adaptation deliverable. Re-run it any time; it always reflects the current submissions. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 35 tools
Most tools are separated by clear object nouns (model, prompt, invocation, file, blocker, evaluation), but the generate/plan/report/finalize/start cluster is easy to confuse and requires careful reading of descriptions. The analyze/prepare/validate pairs also rely on subtle wording rather than instantly obvious boundaries.
All 35 tools follow the same verb_noun snake_case convention with no camelCase or mixed naming styles. Compound targets are consistent and readable, such as prepare_prompt_migration vs prepare_invocation_migration and get_blocker_resolutions vs get_research_prompts.
35 tools is well above the 25+ threshold and makes the flat tool surface heavy for agents to navigate. The breadth is defensible for a migration platform, but as a single MCP server it would benefit from consolidation, grouping, or namespacing.
The lifecycle is unusually complete: scan application, resolve models, analyze prompts/invocations, generate plans, start runs, handle blockers, submit adaptations, evaluate, review evidence, build consensus, and finalize. There are no obvious dead ends, and finalize_migration plus the blocker tools explicitly handle remaining gaps and next steps.