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.

Check here before researching a model: prefixes, version suffixes, and vague platform names normalize deterministically. status is resolved, needs_confirmation (show candidates to the user), 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 names prompt files automatic discovery missed (relative to the application root).

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 request.yaml, research/<scope>.yaml, and (when present) review/<scope>.yaml and runs the deterministic scope/policy and review-integrity gates; nothing is resent through the payload. scope is source, target, or pair.

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 candidates must be shown to the user. Likewise, when prompt consumers exist but no prompt source resolved, prompt_candidates lists candidate files to confirm with the user: retry with prompt_sources, or defer_prompt_candidates=true to decide on the live run with add_prompt_sources. Otherwise the run workspace is created, a bounded research request is written only when knowledge is missing or stale, and next_steps says exactly what to call next. strict=true (production runs) turns unknown evidence URLs, missing invocation facts, incomplete prompt coverage, consistency findings, and a missing validation disposition into blockers/violations instead of warnings.

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.

shared_prompt_guidance applies to every prompt task; guidance items carry stable ids for guidance_dispositions. Each prompt task's verbatim_source is the ORIGINAL unmodified content, never a proposed adaptation. Do not re-list between submissions; finalize_migration reports remaining gaps.

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 guidance plus shared_prompt_guidance) exactly once in guidance_dispositions: {guidance_id, disposition: applied|not_applicable|declined, note (required when declined)}. Document every edit in annotated_changes against the DECODED runtime values: {operation: edit|insert|delete| restructure, original_anchor/adapted_anchor (exact spans), why, evidence: [{kind: model_guidance|model_difference|analysis_finding| research|mechanical, url|reference}]}; every diff hunk covered, no phantom annotations. Serialization-, whitespace-, or case-only edits are rejected; structural drops need allow_restructure=true plus a recorded justification. No change needed? Pass unchanged=true with an EMPTY adapted_prompt (refused while the prompt still references the source model). Shared guidance already disposed earlier in the run is no longer owed, and default_disposition covers unlisted items as visibly defaulted records. Deliverables land under /output/prompts/.

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 guidance_dispositions and document every edit in annotated_changes (anchors match the raw file content). Deterministic checks gate the write to <run>/output/files/; the application tree is never modified. Pass unchanged=true with empty adapted_content for a reviewed no-change file. Prompt sources are rejected here; use submit_adapted_prompt.

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 unaffected_files entry with one reviewed no-change call.

Each path is validated independently (per-file accept/reject in results): only files on the worklist's unaffected_files list qualify — a file with required changes needs a real submission. Each accepted path records a reviewed no-change entry that appears in the final report. acknowledge_source_references=true also closes files finalize flagged source_reference_uncovered whose source-model mention the USER says is intentional (docs, history); pass the user's own rationale.

add_prompt_sourcesA

Add prompt source files to a LIVE run, or dismiss discovery candidates.

paths are application-relative prompt files the user confirmed are live prompts; the worklist re-derives (submitted deliverables keep their entries) and new_prompt_tasks lists the added pending tasks. dismiss names unreferenced candidate files or dynamic consumer path:line:keyword addresses the USER says are not prompts / genuinely runtime-built, with the user's rationale (required). Nothing is written on any problem.

confirm_prompt_consumerA

Record that one dynamic prompt consumer reads one prompt file.

location is a path:line:keyword from the run's dynamic_prompt_consumers (get_run_status / list_adaptation_tasks); source_path is the file the USER confirmed it reads. The consumer becomes source-backed, the file a prompt source, and the worklist re-derives.

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).

subject is the unknown's id (e.g. from a probe script's docstring or the worklist unknowns); outcome is what the target actually did and evidence the printed result, request id, or URL — both from the USER's own run. It closes that unknown in this run's plan and renders in the report; it never changes the registry (promotion is a separate propose_registry_update).

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.

change_id comes from get_change_review. Every decision deterministically regenerates the deliverable from the original, the as-submitted content, and all live rejections; if that cannot be done deterministically the decision is refused (NOT recorded) with the reason. The result lists the change ids still pending for the file.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3/5.0

Scored across 47 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues