Skip to main content
Glama

Migrate Container Instances

migrate_instances
Destructive

Migrate a container's or virtual machine's instances between servers on Cycle, or revert a recent migration. Pass exactly one of container or virtual_machine. Cycle backs every VM with a container, so a VM migrates through that container's single instance (select it with all_instances:true or name it in targets); the response reports both the VM and its backing container.

Cycle migrates instances across any infrastructure it manages — between servers, data centers, cloud providers, and on-prem hardware. Not every server is a valid target: containers carry tag restrictions and other constraints, so this tool only accepts destinations Cycle reports as compatible for the container. A migration is reversible: the original instance is retained until Cycle's purge window elapses (roughly 3 hours for stateful instances), during which action:"revert" restores it on its source server. Only retained source instances are revertable; running destination copies are skipped. Load balancer instances cannot be migrated.

Workflow:

  1. Call with preview:true and your selection. It makes NO changes and returns the selected instances — each with its current server (id and name) and whether it is stateful — plus, for migrate, the compatible destination servers. The plan comes from read-only lookups; Cycle does not validate it.

  2. If the destination is unclear, present the compatible servers and let the user choose. With NO compatible servers migration is impossible — tell the user why (tag or infrastructure constraints).

  3. Confirm the specific move with the user, then call again without preview. Never migrate or revert without explicit confirmation.

Select instances with exactly one of: targets (specific instances, each optionally with its own destination so they can spread across servers), source_server ("move this container off nuc-bear"), or all_instances. A top-level destination_server is the default for selected instances without their own and is required with source_server or all_instances.

copy_volumes applies to stateful instances and defaults to true so data is never silently dropped. A VM's local volumes — including its boot disk — are what it moves, so copy_volumes:false lands the VM on empty local storage and is almost never wanted. External (SAN) volumes are attached, not copied, and are unaffected either way.

Asynchronous: submits one job per instance and returns without waiting (wait_seconds gives a short bounded wait for quick moves). Track the job_ids with get_jobs, then call again with preview:true to confirm each instance reports its destination server.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNomigrate moves instances to a destination server; revert restores recently migrated instances on their source server, within Cycle's purge window.migrate
contextNoWhy are you calling this tool? Briefly describe the user's goal.
previewNoResolve and return the plan without making changes. Always run this first.
targetsNoSpecific instances to act on.
containerNoContainer whose instances to migrate. Exactly one of container or virtual_machine.
environmentYesEnvironment the container or VM lives in. Required; it scopes the lookup.
copy_volumesNoWhether stateful instances copy their volume contents to the destination (default true). Ignored for non-stateful instances and for revert.
wait_secondsNoBounded wait for the submitted jobs (default 0: return immediately and track with get_jobs). Stateful migrations often run far longer than any wait.
all_instancesNoSelect every instance of the container.
source_serverNoSelect every instance of the container currently on this server (hostname, nickname, or ID). Mutually exclusive with targets.
conversation_idNoConversation tracking id. Omit on your first tool call; every result then includes a conversation_id line — pass that exact value on all later calls in this conversation.
virtual_machineNoVM to migrate. Exactly one of container or virtual_machine.
destination_serverNoDefault destination for selected instances without their own; required with source_server or all_instances. Hostname, nickname, or 24-char ID of one of the container's compatible servers. Ignored for revert.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag destructive/openWorld/non-idempotent, and the description adds substantial extra context beyond them: a ~3-hour purge window making migrations revertable, that only retained source instances are revertable, that load balancer instances cannot be migrated, that preview makes NO changes, that copy_volumes:false lands a VM on empty local storage, and that jobs are submitted asynchronously.

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?

It is long (~350 words) but front-loaded with the core action and organized into labeled sections and a numbered workflow, so structure carries the length. A few clauses (e.g. the VM-backing-container aside) could be trimmed, but nearly every sentence earns its place for a 13-parameter destructive tool.

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?

Despite having no output schema, the description explains the response shape (reports both the VM and its backing container, returns job_ids) and how to verify completion via preview:true plus get_jobs. Together with the workflow and edge-case coverage, an agent has everything needed to call this correctly.

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

Parameters5/5

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

Schema coverage is already 100%, but the description adds real semantics the schema lacks: the exactly-one-of container/virtual_machine rule, the interaction between targets/source_server/all_instances, the defaulting behavior of a top-level destination_server, and the stateful-vs-external volume distinction for copy_volumes. It meaningfully extends rather than restates the schema.

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

Purpose5/5

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

The opening sentence states a specific verb (migrate/revert) and resource (container or VM instances between servers on Cycle), plus the exactly-one-of constraint for container vs virtual_machine. This clearly distinguishes it from siblings like reconfigure_container, deploy_virtual_machine, and cycle_control_* without needing to open the schema.

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

Usage Guidelines5/5

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

It gives an explicit 3-step workflow (preview first, present compatible servers, confirm before mutating), a rule to never migrate or revert without explicit confirmation, and the conditions under which migration is impossible (tag or infrastructure constraints). It also routes async tracking to the sibling tool get_jobs by name.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources