Pixly

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

Annotations already supply destructiveHint=true, idempotentHint=true and readOnlyHint=false, so safety is declared. The description adds genuine value beyond them: it discloses that the response distinguishes 'aborted' from 'leftover' items (partial success is possible) and that installed files are outside this tool's scope and require deleteAsset. It does not explain what 'leftover' means or whether retries are safe.

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 tight sentences: the destructive action and its scope come first, the return shape second, and the boundary condition third. No filler or restated title.

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 destructive, nested-parameter tool this is only partly sufficient. The description covers scope and the sibling boundary but leaves the two-level body/path argument shape and the meaning of 'aborted' vs 'leftover' in the response unexplained, and there is no output schema to fall back on.

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 reported as 0% and the description mentions no parameters except the 50-item cap, which merely restates the schema's maxItems. Inline schema text does describe key/uploadId/serverId, but the tool's prose does not compensate for the coverage gap or clarify the nested body/path structure an agent must build.

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 ('discards') and resource ('unfinished or inspected uploads') with a hard cap of 50, so the agent knows exactly what the call affects. It differentiates from deleteAsset by noting installed files are removed there instead, but never distinguishes itself from the sibling upload-abort tools (abortModpackUpload, abortWorldUpload).

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 'unfinished or inspected uploads' implies the tool belongs after startAssetUpload/inspectAssetUpload, and the deleteAsset pointer gives one routing rule. However, there is no explicit when-to-use statement, no mention of what happens if uploads are already complete, and no disambiguation against the modpack/world abort siblings.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true and idempotentHint=true; the description adds real context on top by stating the file is discarded and that installed modpacks are out of scope, which defines the blast radius. It stops short of saying whether a partially installed state or a retry after timeout is safe, but the idempotentHint covers the repeat-call case.

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 sentences, zero waste. The scope and the exclusion plus the pointer to deleteModpack are all front-loaded and none of it repeats the annotations verbatim.

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?

With no output schema, the description could say what a successful cancel returns (or whether the upload record disappears entirely), and it doesn't state that the key/uploadId pair must be the ones from startModpackUpload. Neither gap is likely to cause a wrong call for a cancel operation with annotations already declaring destructiveness and idempotency.

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 description says nothing about key, uploadId, or serverId — it relies entirely on the schema. The visible schema does carry per-property descriptions ('key returned by the start call', 'id field from listServers'), which mitigates the reported 0% coverage, but the description itself contributes no parameter meaning, so this stays at the baseline.

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?

Specific verb, resource, and lifecycle state, with explicit sibling contrast.

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 both the positive condition (unfinished / checked-but-not-installed upload) and the negative condition (an installed modpack is not affected), then routes to the correct alternative (remove it with deleteModpack). No inference required about when to pick this tool.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description doesn't need to re-state safety. It adds real context the annotations cannot convey: that partial parts are discarded and that the server's current world is untouched, which reassures the agent the action is scoped.

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 tight sentences: effect first, then the non-effect clarification, then the precondition. Nothing is redundant or padded.

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 destructive, idempotent cancel operation with no output schema, the description covers the effect, the non-effect on the live world, and the timing constraint. It could say what happens if called after completion (error vs no-op), but nothing essential 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?

Top-level parameters (body, path) carry no description, matching the 0% coverage signal, and the description adds no parameter detail. However, the nested schema thoroughly documents key, uploadId, jobId and serverId with provenance ('from startWorldUpload', 'from listServers'), so the practical gap is modest.

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 ('Cancels an unfinished world upload') with explicit effect ('discards the parts uploaded so far'). The scoping clause distinguishes it from completeWorldUpload and the similarly named abortAssetUploads/abortModpackUpload without needing the schemas.

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 an explicit precondition ('Only before completeWorldUpload'), which routes the agent away from the complete path and implies the valid window of use. It lacks an explicit 'use abortAssetUploads for assets' style disambiguation, but the world-upload scope plus the precondition cover the main selection decision.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, so the safety profile is covered; the description adds real value by disclosing the two error conditions and the fact that only unapplied queued restores are affected. It stops short of saying what happens to the queued record or what the response contains.

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, front-loaded with the action and scope, followed by the required argument and the failure conditions. No filler and no repetition of the title.

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-argument, non-destructive cancel with annotations covering safety and no output schema, the description supplies scope, required input, and error behavior. The only gap is the post-cancel state (whether the queue entry is removed and what is returned).

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 reported at 0% for the top-level 'path' parameter, but the nested backupId and serverId do carry descriptions pointing at listBackups and listServers. The description adds only the qualifier 'queued' for backupId and says nothing about serverId, so it neither compensates for the coverage gap nor adds much 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 ('Cancels a restore from restoreBackup') and constrains it to restores an online server has not applied yet. It names the sibling tool that creates the queue entry, so an agent can distinguish cancel from restoreBackup without opening either schema.

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?

Explicitly scopes usage to a queued-but-unapplied restore and states the failure conditions ('Fails if nothing is queued for it or it is already being applied'). It routes implicitly to restoreBackup as the counterpart but does not name an alternative for cancelling an in-progress restore, which is the one missing piece.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description's job is to add what annotations cannot. It does: partial-success semantics (failing files come back in `rejected` with key and error) and deferred application ('the rest apply at the next restart'), which is critical behavior an agent cannot infer. It stops short of saying whether a partially-rejected batch leaves orphaned uploads or whether rejected entries need re-uploading.

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?

A single dense sentence ordered by importance: what it does, the cap, the alternative route, then the result contract. No filler, nothing repeated from annotations.

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 mutating, multi-file completion step with no output schema, the description covers the failure channel and apply timing, which are the two things an agent most needs. Minor gaps remain around atomicity and whether a restart is required versus automatic, but the essential call contract is present.

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?

Coverage is reported at 0% for the two top-level parameters (`body`, `path`), so the description should compensate but largely does not — it never explains serverId or the uploads array. It adds two useful facts beyond the schema (the 50-file cap and that rejected results echo the `key`), but the nested shape of parts/uploadId is left entirely to the schema's own field 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?

States a specific verb and resource — installs uploaded files, up to 50 — and names both its prerequisite (startAssetUpload) and the sibling that handles a special case (setResourcePack for resource packs). An agent can tell it apart from completeWorldUpload/completeModpackUpload and from its abort counterpart without opening a schema.

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?

Explicitly encodes the calling sequence ('files from startAssetUpload calls') and routes resource packs to a different sibling. This is exactly the when-to-use / when-to-use-something-else information an agent needs, delivered in one clause.

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

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

Goes well beyond the annotations by naming exactly what is overwritten (loader, version and mods), the timing (applied at the next restart, not immediately), and the mitigating behavior (a backup is taken first). It also notes 'Returns the server,' giving an expected response shape despite there being no output schema. This is the rich destruction/timing context annotations alone cannot convey.

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 three short clauses: what it does and its blast radius front-loaded, then the required inputs, then the return. No filler, no restatement of the title.

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 destructive, nested-object mutation with no output schema, the description covers effect, timing, safety net and return value, which is most of what an agent needs. It stops short of stating the failure/abort path and never mentions the required serverId, leaving a small but real gap.

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 reported as 0% at the top level, so the description does useful work by naming uploadId, key and each ETag as the values to supply. However, it says nothing about the required path.serverId parameter, the partNumber ordering requirement, or the ETag quoting format that the nested schema documents — so it only partially compensates for the coverage gap.

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 — installs the uploaded .mrpack as the server's modpack — and specifies the scope of that install (loader, version and mods). This clearly separates it from the sibling upload tools (startModpackUpload, inspectModpackUpload, abortModpackUpload) without the agent needing to open any schema.

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 implies this is the terminal step of a multipart upload ('Pass uploadId, key and each ETag') and discloses that it triggers at the next restart, but it never explicitly says when to call it versus inspectModpackUpload or abortModpackUpload, nor what precondition must hold (all parts uploaded). Usage is inferable rather than stated.

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

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

Adds a lot beyond annotations: the current world is untouched, the archive imports asynchronously over 'minutes' into a new backup with reason 'upload' visible in listBackups, and it fails over 4 GiB or on low balance. This is exactly the post-state and failure-mode detail an agent can't infer from destructiveHint/idempotentHint.

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 tight sentences, front-loaded with the call condition, then consequences, then the next action and failure limits. No filler.

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 mutation tool with no output schema, it covers post-state and follow-up well. The one gap is whether the completion response returns a backupId or only listBackups reveals it, which the agent must check to chain restoreBackup.

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 description names jobId, uploadId, key and ETags as the payload, matching the required nested body fields and reinforcing that ETags must be carried from each PUT. It omits the required serverId, which only the schema documents.

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?

Specific verb+resource: finalizes a multipart world upload and triggers an import, clearly distinct from startWorldUpload/abortWorldUpload by the 'after every piece is uploaded' framing. It doesn't name the sibling it supersedes explicitly, keeping it just below the top score.

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?

States the trigger condition (after every piece is uploaded) and the downstream step (run restoreBackup with that backupId to play it). No explicit statement of when NOT to call (e.g. use abortWorldUpload on failure), which the sibling list makes relevant.

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

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

Annotations only declare the generic write profile (readOnly=false, destructive=false, idempotent=false); the description adds substantive behavior beyond that: the state-based failure modes, the balance prerequisite, and the asynchronous 'pending' result that resolves in listBackups. It also discloses a display convention (identify backups by time and reason, never expose backupId), which is genuinely non-obvious operational context.

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?

Four short sentences, front-loaded with the action, then failure conditions, then return semantics, then the display convention. Every sentence supplies information an agent cannot get from structured fields; nothing is redundant with the annotations or schema.

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?

With no output schema and only a thin annotation set, the description carries the burden and does so: it explains the asynchronous return value, how to confirm completion, and the failure envelope. Nothing an agent needs to call this correctly and report results 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 reported as 0% and the description says nothing about the sole 'path/serverId' parameter, so it adds no meaning beyond the schema. However, this is a single nested parameter whose serverId field carries its own inline description ('the id field from listServers'), so the gap is small and the baseline 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?

The description opens with a specific verb and resource ('Takes a manual backup of the server's current world') and immediately notes the downstream purpose (restore or export). An agent can distinguish this from siblings like listBackups, restoreBackup, or startBackupExport without opening a schema.

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?

It gives concrete preconditions for failure (server starting/stopping/restoring, pre-first-boot, low balance) and points to listBackups as the way to follow progress, which is clear invocation context. It stops short of an explicit 'use this instead of X when Y' routing statement against alternatives such as automatic backups, but the manual framing plus the failure conditions make usage unambiguous.

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

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.

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds real value beyond that: the change is deferred to the next restart and the file is recoverable only from a backup, which tells the agent how to warn the user.

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 sentences with zero filler: purpose first, then the two behavioral facts that matter (restart timing, backup-only recovery). Every sentence earns its place.

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 destructive, nested-parameter mutation with no output schema, the description covers consequences well but omits the parameter shape entirely and says nothing about preconditions. An agent can call it, but only after reading the schema closely.

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 reported at 0% and the description mentions no parameter at all. The required argument is a nested object (fileName + serverId) and the description never explains that shape or how to obtain serverId, so it fails to compensate for the coverage gap.

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 ('Uninstalls ... and deletes the file') and a specific resource ('custom mod, plugin or datapack file that was uploaded to the server'), which separates it from deleteServer, deleteBackup and deleteModpack. It never names a sibling explicitly, so differentiation is inferred rather than stated.

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 only implied: the agent infers this is the tool for removing a single uploaded content file. There is no statement of when not to use it (e.g. versus deleteModpack) and no prerequisites such as server state or required permissions.

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

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

Goes well beyond the annotations: it discloses that deletion is permanent and irreversible, enumerates the two blocking states that cause refusal, and explains the requiresConfirmation refusal path with the exact retry semantics (ask the user, then repeat with confirm true). This is exactly the mutation context annotations alone cannot convey.

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 tight sentences with no filler; the destructive consequence is front-loaded, followed by preconditions and the failure/retry path in the order an agent needs them.

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 destructive two-parameter tool with no output schema, the description covers consequence, blocking preconditions, and the refusal/confirmation loop — everything needed to call it correctly and safely.

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 0%, so the description must compensate. It does explain the confirm parameter's conditional purpose well, but the nested path/backupId/serverId parameters are never mentioned, leaving the identifier source and structure to the schema alone.

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 plus scope ('one backup') and immediately flags irreversibility. It is clearly distinguishable from siblings like deleteBackupExport, cancelBackupRestore, and deleteServer.

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 concrete when-not conditions (backup queued for restore or being exported) and prescribes the escalation flow when the call is refused with requiresConfirmation. It stops short of naming the sibling tools an agent could use instead (e.g., cancelBackupRestore, deleteBackupExport) to clear a blocking state.

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

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

Annotations already declare destructive=true, idempotent=true and non-read-only, so the safety profile is covered. The description adds genuinely useful blast-radius context beyond that: only the export archive is destroyed while the backup is retained and re-exportable — the key fact an agent needs before invoking a destructive 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 and immediately followed by the retention caveat. Every sentence carries non-redundant 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?

For a single-parameter destructive tool with full annotation coverage and no output schema, the description supplies the essential missing piece — what is destroyed versus preserved. It omits any parameter-shape guidance, which is the only meaningful remaining gap.

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?

Top-level schema description coverage is 0% and the nested 'path' object is undocumented as a whole; the description says nothing about backupId/serverId or their sourcing (listBackups/listServers). Only the nested property descriptions partially compensate, so the description fails to fill the stated coverage gap.

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 ('Deletes the downloadable archive') and names its counterpart startBackupExport, which disambiguates it from that tool. It does not explicitly distinguish itself from the sibling deleteBackup, leaving the archive-vs-backup distinction to be inferred from context.

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: call this to remove an export when you want to keep the backup ('The backup itself is kept and can be exported again'). There is no explicit when-to-use/when-not statement nor a named alternative such as deleteBackup for removing the backup itself.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true, and the description goes further: it discloses that the pack file is deleted, the change is deferred to the next restart, and the world survives (with a possible reset suggestion). That is meaningful consequence information beyond the structured hints.

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 sentences, no waste, with the action and its effect front-loaded before the caveat about the world reset. Everything present earns its place.

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 destructive one-parameter tool with no output schema, the description covers the essentials: what is removed, when it applies, and what is preserved. Only the parameter itself and any permission/state requirements are left unaddressed.

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 reported at 0% and the description never mentions the single `path.serverId` parameter. It only implies server scoping via 'the server's uploaded custom modpack,' so it does not compensate for the coverage gap.

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?

The description states a specific verb and resource: 'Uninstalls the server's uploaded custom modpack and deletes the file.' That is unambiguous and distinguishable from siblings like deleteAsset or deleteBackup, though it never names an alternative to route the agent away from.

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 context is only implied through 'taking effect at the next restart,' which hints at timing but says nothing about preconditions or when to choose this over resetServer or updateServer. No exclusions or prerequisites are stated.

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

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

Annotations declare destructiveHint=true and idempotentHint=true, but the description goes well beyond them by enumerating exactly what is destroyed (world, settings, backups, exports), noting the running server is shut down first, and specifying the return value (deleted: true). The user-confirmation policy (only named servers) adds safety context the annotations cannot express.

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-loaded with the destructive scope, then usage constraints, then alternatives — a sensible order with no filler. It runs six sentences, and the web-UI "Danger tab" sentence is the least essential for tool selection, though still informative.

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 destructive one-argument tool with no output schema, it covers destruction scope, safety policy, alternatives, and the return value. The remaining gap is the undocumented nested `path.serverId` structure, which an agent must infer from the schema alone.

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 0% on the single nested parameter, whose non-obvious shape is path.serverId. The description never mentions the `path` wrapper or the id source, only implying via "one server per call" that a single server identifier is passed, so it does not compensate for the coverage gap on the one parameter that matters.

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 ("Permanently deletes the server") plus the exact scope of destruction: world, settings, backups, exports, and shutdown if running. It is unmistakable against siblings like resetServer or deleteBackup, both of which are named as different operations.

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?

Explicit gating: call only for a server the user named in this request, one server per call, and route ambiguous or multi-server requests to listServers plus a clarifying question. It also names the correct alternatives for adjacent intents (resetServer for a fresh world, startBackupExport + getBackupDownloadUrl to preserve the world), leaving nothing to inference.

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

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

Annotations already declare non-readOnly, idempotent and destructive, so the safety profile is partly covered; the description adds real value by bounding the mutation ('does not whitelist, kick or ban') and disclosing the return ('Returns the server'). It leaves implicit why destructiveHint is set for a notice clear (the cleared notice presumably can't be restored).

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, then the boundary, then the alternative and the return value. No wasted words.

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 nested-object parameter tool with no output schema, the description covers action, non-effects, the alternative path, and the return value. An agent has everything needed to call it correctly.

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 0% at the top level, so the description should compensate, and it doesn't explain 'path' or how serverId/playerName are sourced. The nested schema properties do carry their own descriptions (id from listServers, name from joinAttempts), which keeps this at an adequate 3 rather than lower.

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 object ('Clears the notice') and immediately scopes it with negatives ('does not whitelist, kick or ban'), so the agent cannot confuse it with updateServer or moderation actions. The distinction from the closest sibling is made explicit.

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?

Names the alternative and the condition that selects it: 'To let them in, add them to whitelist with updateServer.' Clear routing guidance, though it doesn't state the trigger for using this tool itself (e.g., a stale notice after the player was already handled).

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

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

Goes well beyond the readOnly/idempotent/non-destructive annotations by disclosing link lifetime (6 hours), the dependency on a prior export, the failure mode when the export is not ready, and the paid-account requirement. These are exactly the constraints an agent would otherwise discover only by failing.

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 tight sentences, front-loaded with the return value and lifetime, followed by failure/eligibility conditions and the response shape. No sentence is filler.

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?

With no output schema, the description carries the return contract itself ('url' as .tar.gz and 'expiresAt'), plus latency-relevant failure conditions and account eligibility. Nothing material an agent needs before calling it 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?

The description says nothing about the single nested path object (backupId, serverId); it relies entirely on the schema, whose nested properties do carry their own descriptions pointing to listBackups and listServers. Coverage is nominally low at the top level, so this is adequate but not compensating.

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 ('Returns a signed link ... to download a backup') and explicitly scopes it to backups produced by the sibling tool startBackupExport, which distinguishes it from listBackups, deleteBackupExport, and restoreBackup. An agent can route to it without opening the schema.

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?

Clear preconditions are given: must be used after startBackupExport, fails if the export is not ready, and requires a paid account. It does not, however, point at an alternative (e.g., how to check readiness or what to call for a non-exported backup).

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

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

The annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds context above that floor, notably the negative capability ('cannot add funds') and the precise constraints on the add-funds flow (only dashboardUrl, no button, amount, total-after, or steps). It doesn't cover freshness of the balance figure or whether the projection is calendar- or cycle-based, which keeps it off a 5.

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 core purpose is front-loaded in the first sentence, and the add-funds routing follows as a distinct clause that earns its place. The final sentence is a dense run-on list of prohibitions that takes a second pass to parse, costing it a perfect score.

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?

With no parameters and no output schema, the description carries the return-value burden and does so by enumerating the four figures returned. Combined with the negative capability and handoff instructions, an agent has enough to invoke it correctly; only staleness/units of the numbers are left implicit.

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 tool takes zero parameters, so the baseline is 4. The description correctly implies no inputs are needed by framing it purely around the signed-in user, and it does not waste space inventing parameter guidance.

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?

The description names the specific data returned: signed-in user's balance, this month's spend so far, projected total, and per-hour cost of awake servers. That is a concrete verb+resource statement an agent can act on. It does not, however, distinguish itself from the sibling getMonthSpending, which plausibly covers the same 'this month's spend' data, so the sibling differentiation bar for a 5 isn't met.

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?

It states the trigger explicitly ('when the user asks about their balance or spending'), the exclusion ('it cannot add funds'), and the exact routing for the adjacent intent (show balance plus addFunds with a link to dashboardUrl). This is an unusually complete when/when-not/alternative specification.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new behavioral info beyond them: an empty string signals unknown, which an agent cannot infer from the schema or 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?

A single sentence covers return value, scope, edge case, and usage trigger with no waste. Everything the agent needs is front-loaded.

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?

With no output schema, the description must carry the return-value burden, and it does by explaining the empty-string sentinel. It stops short of showing the range format (e.g. which version string shape to expect) or what happens for an unsupported loader, so a small gap remains.

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?

There are zero parameters, so the baseline of 4 applies. The description correctly requires no input and instead spends its words on return semantics.

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 ('Returns') and resource ('Java version range Bedrock players can join'), plus the exact loader targets (fabric, neoforge, spigot/Paper forks). This clearly separates it from getLoaderVersions, which deals with general loader versions rather than Bedrock compatibility.

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?

'Check it before enabling config.bedrockEnabled' gives an explicit usage trigger, which is more than most definitions offer. No when-not-to-use or alternatives are named, but the trigger is concrete enough to route the agent.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new operational detail: page size cap, oldest-first ordering, omitted platform notices causing short or empty pages, and the 'degraded: true means the read timed out, retry' signal. That retry contract is not present in any structured field.

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 return shape and ordering, then pagination caveats, then the degraded retry rule, then a formatting instruction. Every sentence carries a distinct, actionable fact with no filler.

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?

With no output schema, the description still enumerates the returned fields (events, nextCursor, prevCursor) and the degraded flag, plus how to present results. Nothing an agent needs to call or interpret this tool correctly appears to be 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 coverage is low, and the description compensates by explaining the two cursor parameters' direction ('nextCursor (newer) and prevCursor (older)') and how pages relate to them. The path/serverId parameter is left entirely to the schema's own description, so the compensation is not complete.

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 ('Returns up to 200 recent console lines ... oldest first') and explicitly delimits it from command-execution siblings ('it cannot run commands'). An agent can distinguish this from getServerMetrics or restartServer without opening the schema.

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 concrete triggering situations ('see why a server failed to start or what happened in game') and a negative boundary (cannot run commands). It stops short of naming explicit alternative tools to use instead, which keeps it from a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the description adds value by disclosing output semantics: VANILLA is intentionally omitted and a missing type signals an unavailable list. It doesn't say what shape the values take (array of version strings?), which is the one gap against the absence of an output schema.

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: purpose first, then usage, then edge cases. Every sentence earns its place and nothing is padded.

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?

A read-only, no-parameter lookup with no output schema, and the description covers purpose, timing, keying, and two important absences (VANILLA, missing type). Only the concrete value format of each version list is left unspecified.

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?

Zero parameters, so there is nothing to disambiguate; the description still clarifies that results are keyed by config.type, giving the caller the only semantic needed to consume the response.

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 ('Lists the Minecraft versions each config.type can run, keyed by type') and the title reinforces it. It's clearly distinguishable from siblings like getBedrockRange or getPricingCatalog.

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?

Explicitly says 'Use it before createServer or updateServer to choose config.version', naming the downstream tools and the reason for calling it. No inference required.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real context: the window is month-to-date, not a caller-specified range, and the payload is keyed by serverId requiring a join against listServers. It does not state units (currency, hours) or whether idle servers with zero spend are included, which keeps it short of a 5.

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, front-loaded with the core behavior, then the join instruction, then the alternative. Nothing is redundant and nothing is missing from the sequence an agent would need.

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?

There is no output schema, so the description carries the burden of describing the return shape — and it does, naming the three per-server metrics. It falls slightly short on units and on whether the list covers all servers or only active ones, but nothing blocks a correct call.

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 tool takes zero parameters, so the baseline is 4 and there is no parameter semantics to elaborate. The description correctly avoids inventing inputs and instead tells the agent how to interpret the serverId values in the response.

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 — breaks down this calendar month's spend per server — and enumerates the three returned metrics (cost, compute cost, time awake). It also explicitly distinguishes itself from getBalance, so an agent can tell the aggregation scopes apart without opening either schema.

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 follow-up guidance (resolve each serverId via listServers and name servers by that name) and an explicit routing rule: for totals and balance use getBalance instead. There is no ambiguity about when to pick this tool over its closest alternative.

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

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

Annotations already cover read-only, idempotent, and closed-world safety, but the description adds genuine context: it works without sign-in (auth requirement) and documents how the displayed hourly price is derived (lowest monthlyCents divided by hoursPerMonth, rounded, floored at 1 cent). That derivation rule is important for interpreting results and is not in any structured field.

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 payload description is front-loaded and every sentence carries content, but the middle sentence is dense and run-on, packing the naming rule and the rounding formula together. Slightly tighter structuring would improve scanability without losing 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?

With no output schema, the description carries the burden of explaining returns and mostly succeeds: it names the price fields, the three schedules, the hourly derivation, and the region/size identifier rules. The shape of 'always-on host references when available' remains somewhat vague, but nothing needed to call the tool (it takes no arguments) 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?

With zero input parameters the baseline is 4, and the description earns it by explaining how returned values map onto another tool's parameters: name sizes by memoryGb, add vcpu when two sizes share memory, and use the size value only for createServer. This is useful semantic bridging rather than restatement.

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?

The description states a specific return payload: estimated monthly prices in US cents for every region and size under three named play schedules, plus always-on host references. This is distinguishable from cost-related siblings like getBalance or getMonthSpending, which cover account spend rather than a region/size price catalog.

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?

It explicitly says to use it to quote prices or choose region and size, and links forward to createServer by telling the agent to pass a region's id (not awsRegion) and a size as size. It lacks explicit when-not-to-use guidance, which keeps it below a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: default window of 30 minutes, hard cap of 360, ~30-second sample cadence, oldest-first ordering, and the meaning of gaps (asleep or starting). It also discloses units (permille, divide by 20 for ms/tick, 1000 = lagging), which is exactly the kind of behavior an agent could not infer from structured fields.

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 sentences, front-loaded with what is returned and the default/cap, then per-point field semantics, then the intended use. No filler; even the units-conversion parenthetical earns its place because it prevents a misinterpretation of "load".

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?

There is no output schema, but the description fully specifies the shape of each returned point (time, memory, tick load, peak players), the ordering, and how to read gaps and lag values. An agent can call this correctly and interpret results without further documentation.

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 schema marks 0% description coverage per context signals, so the description carries the burden and does: it states the default (30 minutes) and cap (360) for the window parameter and explains the sample interval that makes that window digestible. It says nothing about the required serverId beyond what the schema itself documents, which is the only gap.

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 (returns load samples for a server over a recent window) with the time range and sampling cadence spelled out, so the agent knows exactly what it fetches. It stops short of differentiating itself from the ambiguous sibling getServerUsage, which sounds like it might return overlapping CPU/memory data.

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?

Explicitly frames the use case: "Use it to explain when and why a server lagged." That is strong positive guidance for when to call it. There are no exclusions or named alternatives (e.g., getConsoleLogs for error text, getServerUsage for plan/quota data), so the agent has no routing help when the question isn't about lag.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral facts: the run-detection window, the 8-hour minimum threshold, and the null semantics of suggestion ('or null when the current size is needed or that run holds less than 8 hours'). It does not describe the histogram bucket format, units, or response size, which is the main remaining gap.

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?

Purpose and return content are front-loaded, then the actionable guidance follows, and roughly 110 words is proportionate for a tool with seven distinct returned series. The first sentence is a long run-on enumerating metrics that is harder to parse than it needs to be, but nothing is padding.

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?

With no output schema, the description carries the return-value burden and does so thoroughly: elapsed play time, the six histogram series, and the suggestion field including its null conditions. Safety is covered by annotations and the mutation path is spelled out, leaving nothing an agent needs in order to call and interpret it.

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 reported as 0% at the top level, and the description says nothing about the path/serverId parameter or where to obtain it. The nested schema does carry a usable hint ('the id field from listServers'), so the agent is not stranded, but the description itself contributes no parameter meaning — a baseline 3 for a single obvious parameter.

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?

The description states a specific verb and resource ('Returns the time the server spent with at least one player online...') plus the exact aggregation window ('latest unbroken run... last 7 days with players, or more days back until they hold 8 hours'). It implicitly separates itself from getServerMetrics by framing the result as a sizing analysis with a suggestion field, but it never names that sibling, so an agent must infer the distinction.

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?

It gives an explicit consumption instruction ('Use suggestion to answer whether the server can run on a smaller size') and routes the follow-up mutation to the correct sibling ('changing size is updateServer with the target size and applies on the next start'). There is no explicit when-not-to-use statement relative to getServerMetrics or getPricingCatalog, which keeps it below a 5.

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

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

Annotations already declare non-read-only, idempotent, non-destructive; the description adds the genuinely non-obvious behavioral fact that this call finalizes/consumes the upload yet stops short of installing it, which the name "inspect" alone would mislead on. It stops short of 5 because it says nothing about what happens when parts are wrong or the upload is already completed, nor about required permissions.

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 dense sentences, front-loaded with the action and the key constraint ("without installing it"), followed by a routing sentence. No filler and no restatement of the title.

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 mutating finalize step with no output schema, the description does sketch the returned payload (kind, size, metadata) and the lifecycle position. It could still say more about failure modes (mismatched parts, repeated calls) and whether the upload survives a failed inspection, but nothing needed to call it correctly 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?

The description never mentions the `body`/`path` parameters, and the reported top-level coverage is 0%, so it does not compensate for the wrappers being undocumented. However, the nested properties (key, parts, etag, partNumber, uploadId, serverId) are thoroughly described in the schema with sourcing hints, and "completes a startAssetUpload" implies those values come from the start call, so an agent is not stranded.

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 chain (completes startAssetUpload) plus the exact output (kind, size, metadata) and the crucial negative scope ("without installing it"). It names the predecessor startAssetUpload and the three follow-up siblings, so the agent can place the tool in the lifecycle without opening any schema.

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 branch conditions: install via completeAssetUploads, resource pack via setResourcePack with its key, discard via abortAssetUploads. Every plausible next action is routed, leaving nothing to inference.

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

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

Annotations already declare non-destructive, idempotent behavior, and the description adds important context: it finalizes a started upload and returns metadata without installing. It does not fully explain whether inspection consumes the upload session or what happens on failure, but it covers the key behavioral distinction from install and abort.

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 sentences, front-loaded with the primary action and immediately followed by the install and abort alternatives. 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?

The description covers the main outcome (returns version, loader, contents), the non-install behavior, and the sibling alternatives. It could say more about whether the upload remains available after inspection or what errors mean, but it is sufficient for selecting and invoking the tool in normal use.

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 reported as 0%, so the description needs to explain parameters, but it only says to call completeModpackUpload with the same arguments. It never explains path.serverId or the nested body fields key, parts, and uploadId, leaving the agent dependent on the schema alone for a nested two-parameter input.

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?

The description gives a specific verb and resource: it completes a modpack upload started by startModpackUpload and returns version, loader, and contents. It explicitly distinguishes the tool from completeModpackUpload (install) and abortModpackUpload (discard), so an agent can select it correctly.

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?

It states the exact usage path: use this to finish and inspect without installing, call completeModpackUpload with the same arguments to install, or call abortModpackUpload to discard. The alternatives and selecting conditions are explicit.

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

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

Adds real information beyond annotations: the billing consequence ("it keeps being charged meanwhile") and the 409 precondition, plus the returned field sleepAt in lieu of an output schema. A small gap remains on whether repeated calls stack or reset the 5-minute window, which matters given idempotentHint=true.

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: effect and cost first, then usage/alternative, then failure condition and return value. Zero filler; the most decision-relevant facts are front-loaded.

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 billed, side-effecting operation it covers the economic impact, the precondition, the sibling alternative, and the key return value. Only the repeat-call/max-extension semantics are unstated, which is minor given annotations and the single-parameter surface.

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 description never mentions the path/serverId argument, and reported schema coverage is 0% at the top level. The nested serverId property does carry a usable description ("the id field from listServers"), and with only one required parameter the navigation cost is low, so this lands at minimum-viable rather than failing.

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 effect ("Delays a running server's idle sleep by 5 minutes from now") with an exact mechanism and magnitude, and explicitly contrasts itself with startServer (wake) versus this tool (extend). An agent can tell it apart from every sibling without opening the schema.

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 the positive condition ("while working on a server with no players online"), the exclusion (servers that are asleep — use startServer instead), and the precondition failure mode (409 if not running). When/when-not/alternative are all present.

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

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

Annotations already declare this as a safe read-only, idempotent operation. The description adds substantial value beyond that by documenting return ordering, returned fields, the reason and exportState enumerations, and the user-facing convention to identify backups by time and reason rather than backupId.

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 dense sentences, front-loaded with the primary behavior and returned data, followed by concrete next-tool routing and a naming rule. 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?

No output schema exists, so the description supplies the essential return fields, ordering, and enum states. Together with the schema-provided serverId description, an agent has enough information to list and interpret backups correctly.

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 only required parameter is serverId inside a path object, and the schema already describes it as the id from listServers. The description does not mention the parameter at all, so it adds no semantic guidance, though the parameter is simple enough that this is a minor gap.

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 ("Lists backups"), adds ordering ("newest first"), and names the returned fields, which clearly distinguishes it from sibling mutation and restore tools.

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?

Explicitly routes the agent: pass backupId to restoreBackup, cancelBackupRestore, startBackupExport, getBackupDownloadUrl, or deleteBackup, and calls out that getBackupDownloadUrl requires exportState ready.

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

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

Annotations already cover read-only, idempotent and non-destructive semantics, and the description adds genuinely new behavioral detail: result ordering, the meaning of the 'pending' status, and the fact that deleted servers vanish. Minor omissions only (no mention of pagination or result-size limits).

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, front-loaded with what the tool returns, then the status meaning, then the join instruction. Every sentence carries distinct information with no repetition.

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?

There is no output schema, so the description carries the burden of explaining return values, and it does cover ordering, per-server cost, status meaning, and missing servers. It leaves some field-level detail unspecified, but an agent can call this zero-param tool confidently.

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 tool takes zero parameters, so the baseline is 4. The description instead documents output field semantics (status, serverId), which is useful but not required for parameter semantics.

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 ('Lists past calendar months' bills') plus ordering ('newest first') and shape ('cost per server'), so the agent knows exactly what comes back. It does not explicitly distinguish itself from the similar-looking sibling getMonthSpending, which is the main remaining gap.

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 usage context – past months, historical view – and a concrete follow-up workflow ('Match each serverId to a name with listServers'). It stops short of naming an alternative such as getMonthSpending or stating when not to use this tool.

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

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

Annotations already declare this is read-only, idempotent and non-destructive, but the description adds substantial behavioral context: it explains runtime.loadCause categories, statusDetail server-online semantics, desiredState stopped meaning asleep, and what joinAttempts represents. No annotation contradiction is present.

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 front-loaded with the resource and returned fields, then adds only high-value semantics for lag causes, server state, and join attempts. Every sentence contributes useful context without repetition or fluff.

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?

With no output schema, the description still explains the meaningful return fields and state indicators an agent needs in order to interpret listServers results. It also covers key behavioral caveats and cross-tool routing, making it complete for this zero-parameter read tool.

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?

This tool takes zero parameters, so there are no parameter semantics to explain. The baseline score of 4 is appropriate because the description is not required to compensate for missing parameter documentation.

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?

The description opens with a specific verb and resource: it lists the account's Minecraft servers and enumerates the fields returned. It also distinguishes itself from sibling tools such as getServerMetrics and dismissJoinAttempt, so an agent can identify its role without checking the schema.

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?

It explicitly tells the agent to use this tool to find the serverId other tools take, by the user-known server name. It also redirects metric-detail queries to getServerMetrics and join-attempt handling to dismissJoinAttempt, providing clear alternatives and context.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by stating that it returns new one-hour links after expiry, though it does not discuss auth/rate-limit behavior or error cases.

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 two concise sentences with zero waste. The core purpose and return behavior are front-loaded, followed by the necessary parameter guidance.

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?

It covers the purpose, usage condition, return link lifetime, and most parameters, which is substantial for a nested-schema tool with no output schema. It is still incomplete because it does not mention the required serverId parameter or explain how the nested path and body fit together.

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 description names jobId, uploadId, key, and the pieces still to upload, which maps meaning onto most inputs and clarifies that partNumbers are expired pieces still needing upload. However, it omits the required serverId path parameter and does not clarify the nested path/body structure, which matters given the nested 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?

The description states a specific verb and resource: it returns new one-hour links for pieces of a startWorldUpload whose links expired. It clearly distinguishes this operation from startWorldUpload and completeWorldUpload by focusing narrowly on renewing expired part links.

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?

It clearly says when to use the tool: for pieces still to upload whose links have expired. It does not name explicit alternatives or when-not conditions, but the lifecycle context is strong enough for an agent to infer correct use.

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

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

Annotations already mark this as destructive and non-idempotent, but the description adds important operational detail: settings/content/address are kept, running players are disconnected and the server comes back online, a reset backup is taken first, earlier backups are kept, and the archived world of a long-asleep server is discarded. It also states that the server is returned.

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 front-loaded with purpose and the restoreBackup alternative, then covers side effects, UI route, and return value. It is information-dense with little waste, though the Danger-tab note is slightly peripheral.

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 destructive reset operation, the description covers side effects, backup handling, player disconnection, return value, and the main alternative. Annotations and the schema's serverId documentation fill the remaining gaps, making it complete enough for selection and invocation.

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 description never explains the sole nested path/serverId parameter. The schema's serverId field does mention the id from listServers, but the description does not compensate for the low schema description coverage or explain the path wrapper.

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: replaces the world with a fresh one while keeping settings, content, and address. It also explicitly names restoreBackup for an earlier world, so the agent can distinguish it from that sibling without opening either schema.

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 a direct alternative and when-not condition: 'for an earlier world use restoreBackup instead.' The intended use case is clear, but it does not compare against other nearby siblings such as deleteServer, createServer, or restartServer.

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

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

Annotations already mark this as destructive, non-idempotent, and non-read-only. The description adds important behavioral context beyond annotations: player downtime, content fetching during boot, world replacement if a restore is queued, account balance requirements, and failure unless the server is running.

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 dense but front-loaded: it states the action and downtime first, then usage guidance, then prerequisites and side effects. Every sentence carries useful 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?

For a destructive restart operation, the description covers downtime, prerequisites, balance requirements, interaction with backup restore, failure conditions, and what the tool returns. No output schema exists, but the return value is mentioned.

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 reported as 0%, and the description does not mention the required path/serverId parameter or how to obtain it. The nested schema does describe serverId as coming from listServers, but the description itself adds no parameter guidance.

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?

The description uses a specific verb and resource: rebooting a running server's machine. It also explicitly distinguishes this tool from restartToApplySettings, so an agent can select the right restart tool without inspecting schemas.

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?

It explicitly says when to use this tool (pending size change or stuck server), when to use the alternative restartToApplySettings (changed game settings), and what to do if the server is not running (use startServer). It also notes the interaction with restoreBackup.

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

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

Annotations already declare destructive, non-idempotent, open-world behavior, but the description adds important blast-radius detail: only the Minecraft process restarts, players drop for a few seconds, content reloads from Modrinth/CurseForge/download links, and the machine may reboot instead if certain pending changes exist. It also states the online prerequisite and failure condition.

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 front-loaded with the action and player impact, then routing guidance, then fallback and prerequisite conditions. Every sentence adds useful behavioral or selection information with no fluff.

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 destructive restart tool with no output schema, the description covers the important operational context: side effects, when to use it, alternatives, fallback reboot behavior, and the online prerequisite. The only omission is parameter naming, which the schema carries.

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 required path.serverId argument is never mentioned in the description. The schema does include a serverId description pointing to listServers, but with reported schema coverage at 0%, the description does not compensate by explaining the identifier or nested path object.

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: restarting only the Minecraft program on an online server so changed settings apply. It clearly distinguishes this from restartServer, startServer, and restoreBackup by naming the relevant alternatives directly.

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 when-to-use guidance: when the server reports a restart is required. It also names when-not/alternatives: use restartServer for a size change, startServer if offline, and full reboot may occur for size changes or queued restoreBackup restores.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds the non-obvious facts: no implicit snapshot is taken, all progress since the backup is unrecoverable, an online server defers the change to next restart rather than applying it live, and a new backupId supersedes a queued restore. These are exactly the consequences an agent cannot infer from the hints.

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 sentences, all front-loaded with the destructive consequence first, then the timing model, then the overwrite rule. Every clause carries information an agent needs; nothing is restated from the title or annotations.

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?

With no output schema and only one argument, the description covers the destructive semantics, the deferral model, and the escape hatch, which is the bulk of what matters. The remaining gap is that the shape of the nested parameter object and the meaning of serverId are not addressed at all.

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 for the single top-level parameter (`path`) is 0%, and the description never explains that the argument is a nested object carrying backupId plus serverId, nor that serverId identifies the target server. It does add meaningful semantics for backupId (a different value replaces a queued restore) and points at createBackup/listBackups contextually, but the structural surprise is left to 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?

Opening sentence states a specific verb and resource ("Replaces the whole world with the chosen backup") and immediately scopes what that means. It is clearly distinguishable from createBackup, cancelBackupRestore, and restartServer, which are named by role rather than left to inference.

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?

Explicit conditional routing: run createBackup first if you want to preserve the current world, cancelBackupRestore undoes a queued restore, and restartServer/restartToApplySettings is what makes an online server actually apply it. It also states the branch condition (asleep vs online server) that determines which path applies.

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

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

Annotations already declare destructive=true, idempotent=false and openWorld=false/true profile, so the safety bar is lower. The description still adds value beyond them by disclosing the deferred-application trait ('applies at the next restart') and the removal path ('from: none removes it'), plus that the server object is returned. It omits whether an existing pack is replaced/validated, which is relevant for a destructive op.

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?

Four short clauses, front-loaded with the action and the source enumeration, then the apply-timing caveat, then the return value. No filler and nothing repeated from the annotations.

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 two-parameter destructive mutation with no output schema, the description supplies the missing behavioral essentials: deferred application, removal semantics, the mandatory-pack follow-up and the return value. Only the interaction between the upload lifecycle siblings (startAssetUpload/inspectAssetUpload before using 'upload') is left implicit.

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?

Reported schema description coverage is 0%, so the description carries more burden than usual. It does map the mutually exclusive 'from' modes conceptually, but never names the actual discriminators (projectId, key, url) or explains that serverId comes from listServers, leaving the three payload shapes to be inferred from structure alone.

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?

Names a specific verb+resource ('the resource pack players are offered on join') and immediately enumerates the four mutually exclusive sources (Modrinth, uploaded .zip, link, none = removal). The distinction from sibling tools like updateServer and startAssetUpload is clear because this is the only tool that assigns the pack.

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 the agent concrete next-step routing: apply with restartToApplySettings, make mandatory via resourcePackRequired in updateServer. This tells the agent what to do after and around this call. It stops short of stating prerequisites or when-not-to-use (e.g. that an upload must be completed first), which is why it is not a 5.

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

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

Annotations already cover safety hints, but the description adds valuable operational behavior beyond them: returned fields (uploadId, key, fileName, parts), the requirement to PUT each piece within an hour and retain each ETag, and per-server/per-account storage caps. These details are essential for correctly completing a multipart upload workflow.

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 front-loaded with the key prerequisite, then describes the operation and return values, and finally lists the workflow alternatives. Despite being dense, every sentence carries relevant information for selecting and invoking the tool.

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?

Given the lack of an output schema, the description still explains what the call returns and how to proceed with the returned parts. It covers file-type constraints, size limits, part upload behavior, and sibling tools for completion, inspection, and aborting, which is complete enough for an agent to call this complex multipart upload tool correctly.

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 schema itself contains descriptions for fileName, fileSize, partCount, and serverId, but the tool description adds only partial semantic context: file type restrictions, the 512 MiB cap, and the need to PUT each part. It does not clarify the relationship between fileSize and partCount or explain the required serverId path parameter, so it does not fully compensate for the reported low schema coverage.

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?

The description opens with a specific verb and resource: it 'Begins uploading one .jar or .zip mod, plugin, datapack or resource pack'. It also distinguishes the tool from its sibling workflow tools by naming completeAssetUploads, inspectAssetUpload, and abortAssetUploads.

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?

It states a clear precondition ('Only for an assistant that can send the user's file with HTTP PUT, such as a coding agent with a shell') and then maps the follow-up path: completeAssetUploads installs, inspectAssetUpload checks, abortAssetUploads discards. This gives an agent explicit when-to-use and next-step guidance.

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

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

Beyond the annotations, the description discloses important behavioral traits: paid-account requirements, refusal while another upload/export/restore is pending, a per-account cap, asynchronous polling behavior, and a specific failure mode. These are material operational details not captured by the readOnly/destructive/idempotent hints.

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 compact and front-loaded: it states the action first, then constraints, then the follow-up workflow. Every sentence carries operational information without repetition.

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 an asynchronous export-start tool with no output schema, the description supplies the essential lifecycle context: prerequisites, blocking conditions, polling target, next call, and failure signal. It gives the agent enough to invoke and follow up correctly.

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 description never mentions the required path object or its backupId/serverId fields, so it adds no meaning beyond the schema. Although the nested schema descriptions identify backupId and serverId sources, the top-level path parameter is undocumented and schema description coverage is reported as 0%, leaving the description to compensate and it does not.

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?

The description uses a specific verb and resource: it packages a backup into a downloadable archive. It clearly distinguishes this from sibling tools like getBackupDownloadUrl and listBackups by describing startBackupExport as the step that initiates the export process.

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?

It gives explicit when-to-use and workflow guidance: poll listBackups until exportState is ready, then call getBackupDownloadUrl, and treat a return to idle as failure. It also states prerequisites (paid account and balance) and concurrency restrictions.

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

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

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=false), and the description adds genuinely new behavioral facts: the 1 GiB cap, that presigned part URLs expire after one hour, that each ETag must be retained, and that the call is refused when a modpack already exists. No contradiction with destructiveHint=false, since the tool only stages an upload.

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 prerequisite, then the action, return values, and the refusal/alternatives. Dense with parentheticals and colon-chained clauses, but each sentence carries a distinct obligation that an agent needs.

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 multi-step, non-idempotent upload flow with no output schema, the description supplies the return shape (uploadId, key, fileName, parts), the URL lifetime, the ETag retention rule, and the completion handoff. An agent can execute the whole flow from this text plus the 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?

Top-level parameter coverage is 0% and the nested properties only carry schema-level descriptions. The description restates the file-size ceiling and the per-piece PUT flow, but never explains the serverId path parameter or the partCount = ceil(fileSize / 8388608) relationship, leaving that to 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 ('Begins uploading a Modrinth .mrpack') with a hard size bound (1 GiB). It is clearly separable from startWorldUpload/startAssetUpload and from completeModpackUpload, which the description names as the follow-on step.

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 an explicit capability prerequisite ('Only for an assistant that can send the user's file with HTTP PUT, such as a coding agent with a shell'), the next tool to call, and an exclusion case ('Refused when a modpack is set') with the two alternative paths (deleteModpack, updateServer).

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

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

Annotations already flag destructiveHint=true, idempotentHint=true and openWorldHint=true; the description goes beyond them by naming the destructive consequence (a queued restoreBackup replaces the current world) and the cost gate (account balance must cover the server's size). It adds real context, though it does not say what happens if balance runs out mid-boot or what the returned server object contains.

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 critical scoping clause (asleep vs online) is front-loaded and every clause carries information the agent needs. It is dense and slightly run-on with semicolons, but there is almost no waste.

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, output-schema-less mutation tool, the description covers cost prerequisites, side effects (mod fetching, world replacement), the contrast tool, and how to confirm success. Nothing an agent needs before or after calling it 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?

Only one parameter, and the schema itself documents serverId as 'the id field from listServers'. The description adds no syntax or sourcing detail beyond that, so it neither compensates for the 0% coverage metric nor is needed to – the schema carries it.

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 (wakes/starts) and resource (an asleep server) plus the outcome (players can join at its address). It explicitly contrasts with restartServer for already-online servers, so the agent can distinguish it from siblings like keepServerAwake and resetServer.

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 the when (server is asleep and should be reachable from the internet), the when-not (an online server — use restartServer instead), and even the follow-up loop (poll listServers until statusDetail is server-online). That is explicit routing plus a post-call procedure.

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

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

Goes well beyond the annotations by disclosing the return payload (jobId, uploadId, key, parts), the one-hour URL expiry, the ETag retention requirement, the size ceiling, and the concurrency refusal condition. Nothing here contradicts readOnlyHint=false, idempotentHint=false or destructiveHint=false.

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?

Four dense sentences, front-loaded with the caller restriction and followed by the mechanics; no filler and no restatement of the title. Each clause carries either a constraint, a step, or a destination tool.

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 multi-step upload with no output schema, the description explains the whole flow (initiate → PUT parts → keep ETags → complete) and its preconditions. The one gap is what to do when a part URL expires, given that refreshWorldUploadParts exists as a sibling but is never referenced.

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 description supplies the file-size ceiling and format list that map onto fileName/fileSize, and explains what the returned parts mean. However, the required serverId parameter (path.serverId) is never mentioned in the description, and the 8 MiB partCount rule is left entirely to the schema, so compensation for the low coverage is only partial.

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 ('Begins uploading') and resource ('a world archive') with accepted formats and a size cap, so it is immediately distinguishable from startAssetUpload and startModpackUpload. It also names the follow-up tool completeWorldUpload, anchoring the tool in its workflow.

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?

Opens with an explicit when-not constraint ('Only for an assistant that can send the user's file with HTTP PUT, such as a coding agent with a shell'), which rules out the wrong caller. It also names the preconditions ('Refused while another upload, export or restore is pending') and routes to completeWorldUpload after the parts are sent.

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

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

Annotations declare idempotentHint=true and destructiveHint=false, and the description supplies the context that makes that credible: players are disconnected and running charges end, but world and settings persist. The autoStart wake-on-join behavior is a non-obvious side effect disclosed nowhere else in the structured data.

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 sentences, front-loaded with the primary effect, then alternatives and caveats in decreasing priority. Every clause carries distinct information; nothing is repeated from the title or annotations.

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 side effects, persistence, alternatives, and even notes the return value ('Returns the server'), which matters since there is no output schema. The only gap is the absence of any parameter guidance for a tool that mutates a specific server.

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 reported at 0% for the single nested path.serverId parameter, and the description says nothing about it — no id format, no provenance beyond what the nested schema already states ('the id field from listServers'). For a tool whose only input identifies the target resource, the description leaves parameter meaning entirely to 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 (shuts a running server down) plus the resulting state (sleeps). It explicitly separates itself from restartServer and from deleteServer's implied semantics by noting the world and settings are kept.

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 an explicit alternative and the condition that selects it ('For a reboot use restartServer'), plus a caveat about autoStartEnabled waking the server and the sibling that disables it (updateServer). An agent has everything needed to route between startServer, restartServer, stopServer and updateServer.

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

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

Annotations already declare destructive/non-idempotent/openWorld, and the description adds genuinely new semantics: omitted fields are preserved (PATCH-like merge), a sent list replaces the stored list, uploaded files are exempt from replacement, and a larger size raises hourly cost. It does not mention the destructive resetWorld path or permission requirements, which a mutating tool of this weight could use.

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 sentences, each earning its place: scope first, then merge/replace semantics, then exclusions and the restart/cost consequence. Zero boilerplate and the operative constraint is front-loaded.

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 destructive bulk-update tool with a large nested body and no output schema, the description covers merge semantics, side effects (restart requirement), cost, and sibling exclusions. It leaves the safety-critical resetWorld and domain verification steps to the schema rather than surfacing them, which is the remaining gap.

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?

Reported schema coverage is 0% at the top level and the body is a deeply nested object, so the description carries some burden; it clarifies merge/replace behavior and the cost implication of `size`, which the schema does not. However it does not explain the individual config fields, resetWorld, or customDomain beyond what the schema already says, so it does not compensate for the structural complexity.

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 (changes) and enumerates the resource facets it touches: name, size, settings, player lists, content, auto-start, custom domain. It also names the two siblings it is *not* (setResourcePack, resetServer), so an agent can discriminate without opening schemas.

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?

Explicit exclusions with the correct alternative tools are given ('Not for the resource pack (setResourcePack) or a fresh world (resetServer)'), and the post-condition routes to restartToApplySettings. It stops short of stating the obvious trigger (user asks to modify an existing server) or any auth/permission prerequisites, so not quite a 5.

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

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

The description adds substantial behavior beyond the annotations: a matching record verifies the domain and starts routing players, a failing record is reported with a reason and does not remove an already verified domain, and persistently wrong records are revoked later by an hourly check. These details clarify the mutation's side effects, failure semantics, and deferred cleanup.

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 front-loaded with the action and usage context, then efficiently covers verification outcomes, failure behavior, revocation timing, and return fields. Every sentence adds useful operational detail.

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 verification tool with no output schema, the description explains the return shape and key side effects well. The remaining gap is that it does not describe the path.serverId argument, though the nested schema does provide a short description for serverId.

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 description does not mention the required serverId parameter or explain the nested path object. Although the input schema contains a description for serverId, the stated schema description coverage is 0%, so the description should compensate and does not.

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?

The description states a specific verb and resource: it looks up the public DNS record for a custom domain configured via updateServer, then updates its status. It also names the related sibling updateServer, so an agent can distinguish this verification action from the configuration action.

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?

It explicitly says to use this after the user changes DNS, which gives clear timing guidance. It does not describe exclusions or alternative verification tools, but none are present among the siblings.

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