power_vpsPower-control a VPS: start, stop or reboot. Requires: token. Typical error: 409 during the first boot (setup still running) → wait and retry.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Required. Power action: "start", "stop" or "reboot". stop/reboot interrupt everything running on the server. | |
| service_id | No | Optional. Service code as returned by list_vps/order_vps, e.g. "68J67T5" (a plain numeric id is also accepted). |
Changes observed during successful MCP inspections.
Input schema / properties / action / descriptionAdded value: +"Required. Power action: \"start\", \"stop\" or \"reboot\". stop/reboot interrupt everything running on the server."Input schema / properties / service_id / descriptionPrevious value: -"Service code as returned by list_vps/order_vps, e.g. \"68J67T5\" (a plain numeric id is also accepted)."New value: +"Optional. Service code as returned by list_vps/order_vps, e.g. \"68J67T5\" (a plain numeric id is also accepted)."Input schema / properties / service_id / descriptionAdded value: +"Service code as returned by list_vps/order_vps, e.g. \"68J67T5\" (a plain numeric id is also accepted)."Input schema / properties / service_id / exclusiveMinimumRemoved value: -0Input schema / properties / service_id / minLengthAdded value: +1Input schema / properties / service_id / typePrevious value: -"integer"New value: +"string"Input schema / requiredPrevious value: -[
- "service_id",
- "action"
-]New value: +[
+ "action"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description goes beyond them by disclosing the auth requirement and a concrete failure mode—a 409 during first boot when setup is still running—plus the wait-and-retry remedy, which is genuinely useful operational context.
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?
Two short, front-loaded sentences: the operation and its actions come first, then prerequisites and the error case. No padding or redundant restatement.
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 2-parameter tool with no output schema and annotations that already cover the destructive profile, the description supplies the missing operational details (auth, first-boot 409 retry). It could still clarify whether stop/reboot are asynchronous or how the optional service_id behaves when omitted.
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 100% and the enum is fully documented in the schema itself, so the baseline of 3 applies. The description's enumeration of start/stop/reboot duplicates the schema's enum rather than adding format or constraint details the schema lacks.
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 specific verb ('Power-control') and resource ('a VPS') and enumerates the three concrete actions, so an agent instantly distinguishes it from read-oriented siblings like get_vps_status or reinstall_vps. It stops short of explicitly naming those siblings or stating the boundary between power cycling and reinstalling.
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?
Usage is implied by the enumerated actions (start/stop/reboot), and the 'Requires: token' note gives an auth prerequisite. However, there is no explicit when-to-use guidance or alternative routing (e.g. check get_vps_status first, or prefer reinstall_vps when the OS is broken).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.