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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the bar is lower, yet the description still adds non-obvious behavior: the server is created asleep and costs nothing until woken, region is immutable after creation, and third-party content only downloads on first start. The account-level server cap is a constraint no annotation or schema field conveys.

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?

Roughly five dense sentences, each carrying distinct information, with the most important facts (creation, sleep state, immutable region) front-loaded. It is information-dense to the point of being slightly crowded, but there is no filler sentence to cut.

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 create tool with one deeply nested body parameter, no output schema, and several downstream prerequisites (pricing catalog, loader versions, upload tools, server cap), the description covers the lifecycle, the cost model, the immutability constraint, and every sibling hand-off. Return values are named inline, compensating for the absent output schema.

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?

The single top-level 'body' parameter has no schema description (reported coverage 0%), but the nested schema is unusually well documented, so the description's marginal job is smaller than the coverage number implies. It still adds real guidance beyond the schema — ask for region rather than infer it, region is unchangeable, default to m.medium (4 GB) and ask before upsizing — though it does not walk through the config sub-object or the Modrinth/CurseForge coord forms the schema itself covers.

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?

Opens with a specific verb+resource ('Creates a server') and immediately qualifies the resulting state ('asleep and free until startServer or a joining player wakes it'), which is exactly the distinction an agent needs against the startServer sibling. It also states the return payload (id and join address), so the tool's outcome is unambiguous.

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 explicit routing rules: regions and prices come from getPricingCatalog, deletion at the account limit goes through deleteServer, and uploaded files go through the asset/modpack upload tools. It even encodes an interaction policy ('ask where players are if unknown') rather than leaving the agent to guess.

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