start_serviceStart a stopped VPS in VPSnet and get an event ID to track via wait_for_event; requires services:manage permission and a full-access API key.
Start a stopped VPS. Returns a numeric event id; follow it with wait_for_event. Requires services:manage and a full-access API key.
| Name | Required | Description | Default |
|---|---|---|---|
| orderNo | Yes | Tenant-owned service order number: 1-64 ASCII letters, digits or hyphens, e.g. VP12345 or VP12345-1 |
Changes observed during successful MCP inspections.
v2.3.16Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: it discloses that the operation is asynchronous by returning a numeric event id, tells the agent to follow up with wait_for_event, and specifies required authorization scopes and API key type. These are exactly the details an agent needs to call and track the action correctly.
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?
Three short sentences, each front-loaded and purposeful: purpose, return/follow-up behavior, and prerequisites. There is no wasted text.
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 single-parameter, non-destructive mutation operation, the definition covers purpose, async return behavior, follow-up tool, and authorization requirements. With annotations and a fully described input schema, nothing essential for correct invocation 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 100%, and the orderNo parameter is fully documented in the schema with format and examples. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
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: 'Start a stopped VPS.' This clearly distinguishes it from sibling mutations like stop_service and restart_service, and it names the state transition from stopped to running.
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?
The phrase 'stopped VPS' gives a clear condition for when to use the tool, and the follow-up instruction to use wait_for_event is actionable. However, it does not explicitly name alternatives such as restart_service for a running VPS or stop_service for the opposite action, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.