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

The description describes a billable, state-changing extension of a server ('each month is billed', 'Extend a small server'), while the annotations declare readOnlyHint=true. This directly contradicts the declared safety profile. The otherwise useful details (data and IP preserved, expiry consequence, x402/MPP payment) cannot offset the contradiction.

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 duration, then covers payment and consequences efficiently. Slightly redundant, since the per-month billing sentence duplicates the months parameter description, but no sentence is wasted.

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?

Covers the operation, payment mechanism, and post-expiry behavior, and no output schema exists to explain. However, with an idempotentHint of false and a payment flow, the description should clarify whether repeat calls double-bill and what the caller receives on success, neither of which is addressed.

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%, so both id and months are already documented with pattern, default, and min/max bounds. The description restates the same semantics ('server id from the order', 'number of months', billing per month) without adding format or validation detail beyond the schema.

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 with scope: 'Extend a small server by one to six months.' The 'small' qualifier and the closing instruction to use the plan-matching renew route clearly separate it from vps-medium-renew and the non-renewal siblings.

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?

Gives clear context: renew when the server is approaching expiry, with the consequence spelled out ('A server that is not renewed stops at its expiry date'), and routes to the plan-matching renew route. It stops short of naming the specific alternative tool (vps-medium-renew) for medium-plan servers, leaving that inference to the agent.

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