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. Check here before researching a model: prefixes, version suffixes, and
vague platform names normalize 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. |
| validate_research_artifactA | Validate one scope's research artifacts directly from the run workspace. Reads |
| 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. Both models match registry-first; if either needs confirmation, nothing
is written and |
| get_research_promptsA | Ready-to-run researcher and reviewer prompts for a run's research request. One bounded prompt pair per remaining scope. Run each with a separate agent (never one agent for two scopes or reviewing its own research), write the YAML artifacts to the stated paths, validate each with validate_research_artifact, then call build_session_registry. |
| list_adaptation_tasksA | Per-file adaptation worklist for a started migration run. Call it ONCE.
|
| get_blocker_resolutionsA | Questions plus evidence-backed options for every unresolved blocker. Each blocker carries the question to ask the user and registry-backed options with consequences, evidence URLs, and the exact record_blocker_decision call. Present them VERBATIM, one blocker at a time; never choose on the user's behalf. |
| record_blocker_decisionA | Record the user's decision for one blocker; decisions are durable. Ids must come from get_blocker_resolutions. Accept options REQUIRE the user's own free-text rationale and are never a default. Retarget/correction decisions update the run identity immediately; redesign decisions inject a required task on every regeneration; accept decisions downgrade the blocker to a reported accepted risk. The result lists the remaining blockers and the exact next step. |
| submit_adapted_promptA | Validate and store one adapted prompt for the target model. Adapt minimally: change only what a listed model difference or guidance
item requires. Dispose EVERY guidance item of the task (its |
| submit_adapted_fileA | Store one complete adapted application file (never a diff) for review. Same rules as submit_adapted_prompt: dispose every required change in
|
| submit_adaptationsA | Submit several adaptations in one call, with per-item accept/reject. Each item: {"kind": "prompt"|"file", "source_path", "content", "rationale", "changes"?, "new_file"?, "unchanged"?, "allow_restructure"?, "guidance_dispositions"?, "annotated_changes"?, "default_disposition"?, "default_disposition_note"?} — the same rules as the single-submission tools. Items validate independently (never all-or-nothing) and the accepted subset is applied in one locked, atomic write to changes.yaml. |
| record_change_decisionsA | Record several review decisions in one call, with per-decision results. Each item: {"source_path", "change_id", "decision": "accepted"|"rejected", "note"?}. Decisions apply in order (each regeneration reflects every earlier rejection); a refused decision is reported and the rest continue. |
| get_run_statusA | The run's state machine position with the single next action. States: research_pending -> discovery_incomplete -> blockers_pending -> tasks_pending -> review_pending -> ready_to_finalize -> validation_pending, with pending counts. discovery_incomplete (prompt coverage unresolved with candidate files, or any unresolved consumer in strict mode) names the exact add_prompt_sources / confirm_prompt_consumer calls. Served from the worklist snapshot (re-derived only when the application, run identity, decisions, or registry changed), so it is cheap to call between steps. |
| confirm_unaffectedA | Close every listed Each path is validated independently (per-file accept/reject in
|
| add_prompt_sourcesA | Add prompt source files to a LIVE run, or dismiss discovery candidates.
|
| confirm_prompt_consumerA | Record that one dynamic prompt consumer reads one prompt file.
|
| scaffold_evaluationB | Draft a BYOK evaluation suite from the application's own sample inputs. Cases come from files under sample/fixture/example/evaluation folders, are marked DRAFT, and the suite (output/evaluation/) is bound to the current plan. Show the drafts to the user before anything runs; the toolkit never executes the evaluation. |
| record_observationA | Record the target's observed behavior for one plan unknown (run-scoped).
|
| finalize_migrationA | Write the run's manifest, report, and adaptation change log under output/. The report records per-file changes and rationale, states reviewed no-change deliverables explicitly, lists remaining coverage gaps, and runs the cross-surface consistency gate over the whole deliverable set. Re-run it any time; it always reflects the current submissions. |
| record_validation_dispositionA | Record how this run's migration was validated; durable per run. Record AFTER the first finalize produced the validation deliverables: byok_evaluation needs evaluation_run_path (the eval run for the current output/migration-manifest.yaml); generated_tests needs outcome "run_passed" plus the test summary line from the USER's run; an explicit accept REQUIRES the user's own rationale and is never a default. Then finalize again. |
| get_change_reviewA | Per-deliverable annotated changes paired with their decision state. Returns each deliverable's decoded diff and every annotated change (why, evidence, spans, pending/accepted/rejected). Present each pending change VERBATIM, one at a time; the user decides, never you. Drift and stale decisions are reported, never silently applied. |
| record_change_decisionA | Record the user's accept/reject for one annotated change; durable.
|
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 47 tools
Most tools map to distinct workflow stages and the detailed descriptions make boundaries clear. A few near-twins remain, notably validate_research_artifact vs. validate_research_result and generate_migration_plan vs. generate_session_migration_plan, where an agent could plausibly pick the wrong one.
All tools use imperative lower_snake_case verb_noun names with strong prefixes like get_, record_, validate_, analyze_, generate_, and submit_. Even batch/single pairs like record_change_decision(s) and submit_adaptations follow the same pattern; the minor eval/evaluation abbreviation is not enough to break consistency.
47 tools is far beyond the typical well-scoped 3-15 tool surface and above the 25+ threshold. The count burdens tool selection; several near-duplicate batch/single and workspace/direct validators could be consolidated without losing capability.
The domain is covered end-to-end: scan, research, plan, prompt/file adaptation, change review, blockers, finalization, evaluation, regression analysis, and registry/cost helpers all exist. There are no obvious dead ends; even rare needs such as no-change files, validation disposition, and batch decisions are handled.