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 | ||
| service_id | No | 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 / 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?
No annotations exist, so the description carries the full burden. It does add genuinely useful behavior: the 'Requires: token' auth prerequisite and the concrete 409-during-first-boot failure mode with a wait-and-retry remedy. However, it omits the disruptive nature of stop/reboot and any reversibility or confirmation guidance for a mutation tool.
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 sentences, front-loaded with the action set followed by the auth requirement and the single most likely failure mode. No filler or restated boilerplate.
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 no-output-schema mutation tool the description covers the action vocabulary, auth requirement, and a known error path, but it leaves open whether service_id is needed despite being non-required in the schema and what state changes stop/reboot cause. Adequate but with gaps an agent would notice at call time.
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 coverage is 50%, so the schema documents service_id (including its format and the numeric-id fallback) but not the action enum. The description restates the three action values, which matches the schema enum rather than extending it, and adds no semantics for service_id or for why it appears optional in the schema when it is practically required.
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 and resource ('Power-control a VPS') and enumerates the exact operations (start/stop/reboot), which is more than the title's generic 'Power control'. An agent can immediately tell this apart from read-only siblings like get_vps_status or get_vps_metrics.
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, but there is no explicit when-to-use vs. when-not guidance and no sibling named as an alternative (e.g. reinstall_vps for a full rebuild). The 409-retry hint is operationally useful but is error handling, not usage routing.
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.