Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
LLM_MIGRATE_REGISTRYNoPath 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

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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. status is resolved, needs_confirmation (show candidates to the user and ask), or not_found.

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.

prompt_sources optionally names prompt files (relative to the application root) that automatic discovery missed; they become explicit high-confidence prompt sources.

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 <application>/.llm-migrate/runs/<run-id>/, or output_dir when given), a bounded research request is written only when knowledge is missing or stale, and next_steps says exactly which tools to call next.

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 <run_dir>/request.yaml. Run each prompt with a separate agent (never let one agent research two scopes or review its own research), write the YAML artifacts to the stated paths, validate them, then call build_session_registry.

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). shared_prompt_guidance applies to every prompt task; each task carries only its own guidance. Adapt each prompt minimally per that guidance and call submit_adapted_prompt; write each complete adapted file and call submit_adapted_file (or pass unchanged=true when no change is needed). Submission results confirm acceptance, so re-listing between submissions is unnecessary; finalize_migration reports remaining gaps.

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.

blocker_id and option_id must come from get_blocker_resolutions. Accept options REQUIRE the user's own free-text rationale (they are refused without one and are never a default). Retarget and correction decisions update the run's migration.yaml identity immediately; redesign decisions inject a required, evidence-linked adaptation task on every plan regeneration; accept decisions downgrade the blocker to a prominently reported accepted decision. The result lists the remaining unresolved blockers and the exact next step.

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 changes. Validation runs on the DECODED runtime prompt values, and a submission whose decoded values equal the original's — or differ only by whitespace or letter case — is rejected: serialization tricks, escapes, quoting and cosmetic edits are never an adaptation. If the prompt needs no change, pass unchanged=true with an EMPTY adapted_prompt (combining it with content is an error) to record a reviewed no-change deliverable; the claim is refused when the prompt's decoded values still reference the source model. Blockers are rejected, and a submission that drops the original's structural sections (XML-like tags or prompt components) is rejected unless allow_restructure is true and the justification is recorded in changes. Accepted prompts are written beneath <run>/output/prompts/ mirroring the application layout, and the rationale/changes appear verbatim in the final migration report.

submit_adapted_fileA

Store one finalized post-adaptation application file for review.

adapted_content must be the complete file, not a diff. Submissions are checked deterministically (path containment, Python syntax, model-id consistency) and written beneath <run>/output/files/; the application tree itself is never modified. If the file genuinely needs no change for the target model, pass unchanged=true with an empty adapted_content: the original is copied as the deliverable and the coverage gap closes without resending the file. Prompt source files are rejected here; submit them with submit_adapted_prompt instead.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

C2.8/5.0

Scored across 35 tools

Disambiguation3/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues