llm-migrate

by Athenaxlee

Overview Schema Source Related Servers Discussions Admin

Python

Local

Start Migration

start_migration

Initiates a guided migration run, verifying registry matches and preparing a workspace with next steps.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Default
`as_of`	No
`run_id`	No
`source`	Yes
`strict`	No
`target`	Yes
`research`	No	auto
`output_dir`	No
`prompt_sources`	No
`source_endpoint`	No
`source_platform`	No
`target_endpoint`	No
`target_platform`	No
`application_path`	Yes
`defer_prompt_candidates`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.6.0Sep 24, 2026
- addedInput schema / properties / defer_prompt_candidates
```
Added value: +{
+  "default": false,
+  "type": "boolean"
+}
```
- addedInput schema / properties / strict
```
Added value: +{
+  "default": false,
+  "type": "boolean"
+}
```

Changed1 schema field changedv1.3.0Sep 19, 2026

addedInput schema / properties / prompt_sources

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

Addedv1.2.0Sep 16, 2026

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: conditional early exits (nothing written and candidates shown), handling of prompt candidates, creation of a run workspace, bounded research request only when needed, and the effect of strict=true on error handling. It also implies write behavior by creating a workspace and writing research requests, which is useful. The description is detailed about side effects and conditional outcomes, going beyond a simple 'starts a migration' statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately long but information-dense. It front-loads the core purpose and then explains conditional behaviors. Each sentence adds value. It could be slightly more concise, but the complexity of the tool justifies the length. No fluff or redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 14 parameters, no annotations, and an output schema present, the description covers the essential flow, conditional paths, and strict mode implications. It mentions 'next_steps' which aligns with the output schema's likely field. Given the tool's complexity, the description provides enough context for an agent to invoke it correctly, including what to do in edge cases. The presence of an output schema reduces the need to describe return values, and the description covers the main decision points.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does explain several parameters: strict=true behavior, defer_prompt_candidates=true, prompt_sources (indirectly via retry with prompt_sources), and research (bounded research request). It does not explain all 14 parameters, but it covers the most important ones. Given the low coverage, this is a strong effort, but it could be more comprehensive for parameters like source_platform and target_endpoint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it starts a guided migration run and is the preferred entry point for a full migration, distinguishing it from many sibling tools that cover specific sub-steps. It does not explicitly name a single sibling alternative, but the phrase 'preferred entry point' sets it apart. It could be more explicit about what it is not for, but the purpose is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides some guidance on when to use this tool (as the preferred entry point) and covers conditional flows (e.g., when models need confirmation, when prompt consumers exist). However, it does not explicitly state when NOT to use it or name alternative tools for specific scenarios. It mentions retrying with prompt_sources but not which sibling to use instead. The guidance is embedded but not direct.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server