resize_vps

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

Beyond the sparse annotations, the description discloses important behaviors: the real API checks balance and quota before increases, failures are clean, decreases are unconditionally allowed, and confirm=true is required. It also reveals partial-update semantics by saying to omit unchanged values. This gives an agent a realistic model of how the operation behaves, with no contradiction against annotations.

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?

The description is three tight sentences with no filler. The core purpose is front-loaded, followed by behavior nuances and a final usage rule. Every sentence adds essential operational information.

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?

The description captures the critical behaviors: balance/quota checks, confirm requirement, partial updates, and allowed decreases. It does not mention units, minimum/maximum values, or any reboot/task implications, but for a 4-parameter mutation tool with no output schema it is largely sufficient.

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?

With schema description coverage at 0%, the description has to carry parameter meaning. It helpfully maps CPU/RAM to cores/ram nestly, explains confirm=true, and clarifies partial updates. However, it does not define units or constraints for ram/cores, leaves vps_id implicit, and does not state what values are valid. This is meaningful but incomplete compensation for the absent schema descriptions.

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?

Description states a specific verb and resource: 'Resize a VPS's CPU/RAM.' It unambiguously maps to the tool's role and is distinct from siblings like resize_volume or change_vps_hostname. The resource and action are immediately identifiable.

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 description provides clear practical guidance: increases are subject to balance/quota checks, decreases are always allowed, confirm=true is mandatory, and only changed values should be passed. It does not name alternatives, but no sibling tool offers VPS resizing, so explicit exclusion is less critical. The conditions given are sufficient for correct invocation.

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