Switch an AutoDL instance between GPU and no-GPU modes by confirming shutdown, restarting in the target mode, and returning a background task ID.
切换 GPU/无卡模式，立即返回后台任务 ID：关机、确认关机、按目标模式重新开机。会中断运行任务，重新开机会计费；执行前必须确认。无卡目标仅支持按量计费。不是可回滚事务；失败或取消可能停在关机状态，不自动恢复。任务不跨服务重启恢复。
| Name | Required | Description | Default |
|---|---|---|---|
| target_mode | No | gpu | |
| instance_uuid | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give readOnly=false, destructive=true, idempotent=true. The description adds substantial context beyond that: interrupting running tasks, billing on restart, mandatory confirmation, the pay-as-you-go constraint for non_gpu, non-rollbackable semantics, possible stuck-shutdown state with no auto-recovery, and no cross-restart task persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the action and return value, then stacks consequences and caveats. Dense and largely waste-free, though the semicolon-chained warnings make it slightly hard to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, multi-step mode-switch with an output schema present (returns a background task ID, already mentioned), it covers the operational caveats, confirmation requirement, and failure modes an agent needs before invoking. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds the meaningful constraint that the non_gpu target only supports pay-as-you-go billing, but instance_uuid and the gpu/non_gpu syntax/behavior are otherwise left to the schema enum and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource (switch GPU/non-GPU mode) and spells out the composite steps it performs: shut down, confirm shutdown, reboot into target mode. An agent can distinguish it from power_on/power_off purely from the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context on when this applies (switching modes rather than a simple power toggle) plus a hard precondition ('执行前必须确认'). It implies it replaces the separate power_off/power_on siblings but never names an alternative or exclusion explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.