GPU Cloud

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

Annotations already cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true). The description goes further, disclosing the required permission (firewall:write), the account/MCP-key prerequisite, and — importantly — the risky default source of 0.0.0.0/0. It stops short of describing the effect of the change or failure modes.

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 clauses with zero filler: the action, the port syntax, and the permission/account requirements. The most decision-relevant information (protocol and default source exposure) 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 and a low schema coverage, the description still supplies the prerequisites, permission, and key parameter semantics. It omits the success/return behavior of a mutation, but the annotations cover the safety profile, so an agent has enough 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 coverage is only 29%, so the description must carry more weight. It usefully explains port syntax (single '8080' vs portRangeMin/portRangeMax) and the source-CIDR default (0.0.0.0/0), which the schema does not. But it is silent on direction and ethertype, leaving two of seven parameters undocumented in both places.

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 ('Opens') applied to a precise resource (a port range/icmp on a ready server as a firewall rule). The 'firewall rule' framing cleanly distinguishes it from gpucloud_delete_firewall_rule and gpucloud_list_firewall_rules without needing 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?

The 'on a ready server' phrasing implies the prerequisite that the server must be running, and the permission string signals the required scope. However, it never explicitly states when to use this versus the delete/list firewall siblings, leaving the routing 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 readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: the required permission scope (billing:read), the prerequisite of a free GPU Cloud account and MCP key, and the key behavioral fact that the agent itself never handles card data. It does not describe error or failure behavior.

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 behavior is front-loaded in the first clause and the permission/prerequisite metadata is bracketed compactly. The bracketed asides are slightly noisy but each carries actionable information (permission scope, account precondition), so little 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?

For a zero-parameter, read-only hand-off tool with no output schema, the description covers the deliverable (a console page), the precondition (free account + MCP key), the permission needed, and the division of labor between agent and human. Nothing an agent needs to call it correctly is absent.

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 there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter semantics are needed or missing.

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 exactly what the call produces — it returns the console page where the account owner adds a card — which is a specific, verifiable outcome rather than a restatement of the 'add_payment_method' name. It also implicitly distinguishes itself from gpucloud_get_payment_method (read an existing card) by framing the result as a hand-off page, not a mutation.

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 a clear selecting condition: an AI agent never enters card details, so this tool is the route when card entry is required. It does not explicitly name alternatives (get_payment_method, get_console_url) or state when not to call it, so it falls short of full explicit routing.

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 a non-read-only, non-idempotent, non-destructive write, so the safety profile is covered. The description adds genuinely new context: the key is validated and fingerprinted server-side, accepted formats are constrained, and an authorization scope plus account prerequisite are required. It stops short of saying whether re-adding the same key errors or what happens on validation failure.

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: the action and input format lead, the validation behavior follows, and metadata (permission, prerequisites) is bracketed at the end. Zero filler and nothing requires re-reading.

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 simple two-parameter write with no output schema, the description covers action, accepted formats, validation semantics, and auth prerequisites, which is most of what an agent needs. It omits the naming semantics of "name" and any indication of what is returned (e.g., the fingerprint).

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 carry parameter meaning. It partially compensates by specifying the publicKey format (ssh-ed25519 / ssh-rsa / ecdsa), which is the most error-prone input, but the required "name" parameter is never explained (no naming rules, uniqueness, or display purpose), leaving half the surface undocumented.

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 precise verb+resource ("Imports an OpenSSH public key") and even enumerates accepted key algorithms, which is far more specific than the title alone. It implicitly separates itself from gpucloud_generate_ssh_key (which creates a pair) by using "imports," though it never names that sibling explicitly.

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 permission scope (ssh_keys:write) and the account/MCP key prerequisite, which helps an agent know it can perform the call. However, it never says when to choose this over gpucloud_generate_ssh_key or how it relates to gpucloud_list_ssh_keys/gpucloud_delete_ssh_key; usage is only implied by "imports."

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 (which already declare idempotentHint and destructiveHint=false), the description discloses that nothing is charged, that a running launch attempt is stopped before a charge or launch occurs, the resulting status CANCEL_REQUESTED, the required permission servers:reserve, and the account/MCP key prerequisite. This is unusually rich behavioral 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?

The critical charge-free fact is front-loaded, and the sentences are dense with useful information. The parenthetical status and bracketed permission/account notes make it slightly cluttered but still efficient.

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 one-parameter mutation with no output schema and no nested objects, the description covers the outcome (CANCEL_REQUESTED), the cost implication, and the auth requirement adequately. A note on what happens if the reservation has already launched/been charged would close 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?

Schema coverage is 100% and the single reservationId parameter is already documented in the schema, including a pointer to gpucloud_list_reservations. The description adds no format, syntax, or sourcing detail beyond what the schema provides, so the baseline 3 applies.

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 (cancels) and a precisely scoped resource (a waiting GPU reservation), and clarifies the charge implication immediately. It is clearly distinguishable from gpucloud_cancel_server by the 'waiting reservation' qualifier.

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 implies the applicable context (a reservation that is waiting or mid-launch) but never explicitly names when to use this versus gpucloud_cancel_server or gpucloud_list_reservations, nor any exclusion or prerequisite trigger. Usage is inferable but not spelled out.

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, openWorld=true, so the safety profile is covered structurally. The description still adds real value beyond that: it spells out that all data is lost, that the order is closed when this was the last item, that canDelete is required, and that the operation is a two-step flow. Missing only failure/partial-failure behavior.

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 effect and densely packed with prerequisites in a few clauses; little waste. The trailing bracketed account/key note is slightly tacked-on but relevant.

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 mutation with no output schema, the description covers effect, permission requirement, and flow, with annotations handling reversibility and idempotency. The remaining gap is distinguishing this tool from gpucloud_delete_server, which an agent selecting between destructive siblings would want.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the two parameters are already documented, giving a baseline of 3. The description earns a bump by explaining the two-step flow, which is what makes the confirmationToken parameter necessary and ties it to a prior call.

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 its side effects: destroys the server, loses all data, and closes the order when it was the last item. It references gpucloud_delete_server as a similar operation, but does not clearly explain how cancel differs from delete, so the distinction an agent would need is only implied.

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 prerequisites (needs canDelete, permission servers:delete, account and MCP key) and notes the two-step flow, which is useful context. However it never says when to pick this over gpucloud_delete_server or gpucloud_cancel_reservation, so the routing decision is left 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?

Far exceeds annotations: discloses that the saved card is charged, the [SPENDS MONEY] warning, which billing modes are covered by the key caps (D7 monthly/annual), that provisioning uses the first account SSH key, the required orders:create permission, the account/MCP key prerequisite, and the single-use 10-minute token. Annotations only cover the generic safety profile.

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 action and its cost are front-loaded, and bracketed flags ([SPENDS MONEY], permission, prerequisites) make scanning fast. Slightly dense with stacked clauses in the first sentence, but 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?

Covers prerequisites, cost, provisioning side effect, and token constraints for a non-idempotent money-spending tool with no output schema. It does not say what is returned (e.g., order/server identifiers) or whether provisioning is synchronous, which is a minor gap given no output schema exists.

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 75% and already documents country, province, quantity, and the token. The description adds the origin and lifecycle of confirmationToken and the billing-cap constraint that governs which billing enum values are usable, plus the implicit dependency on an existing SSH key — meaningful additions 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+resource up front ('Places the quoted order and pays it with the saved card') and immediately distinguishes itself from the quoting sibling by requiring gpucloud_quote_order's confirmationToken. Side effects (card charge, server provisioning with first SSH key) make the purpose 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?

Explicit prerequisite chain: quote first via gpucloud_quote_order, then place the order with its token; the [SPENDS MONEY] flag and permission scope give clear context for when this is appropriate. However, it never contrasts with gpucloud_reserve_server or gpucloud_create_server, which an agent could plausibly confuse as the purchase path.

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 far beyond the annotations: discloses billing flow (credits pay the first hour, saved card charged for missing credits or monthly/annual orders), failure behavior (tool error with httpStatus 402, accountAction PAYMENT_REQUIRED / BUDGET_CAP_REACHED, console link), post-call fields (onFundsExhausted, autoReloadWarning), and an owner email per spend. Also states required permission servers:create and the free-account/MCP-key prerequisite. Nothing here contradicts destructiveHint=false, since data loss only occurs under the explicitly opt-in DELETE policy.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the action and cost implication, then layers prerequisites, payment logic, and error behavior in a single dense paragraph. It is long but nearly every clause carries decision-relevant information; the semicolon-chained sentences make it slightly harder to scan than ideal.

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 9-parameter, money-spending, non-idempotent mutation with no output schema, the description covers prerequisites, billing, error shapes, returned fields, and side effects (owner email). An agent has everything needed to call it correctly or recover from a 402 without further discovery.

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 100%, so the schema already documents all nine parameters and the baseline is 3. The description adds real meaning beyond it: the token is bound to 'exactly these arguments and the key caps', and the cycle choice drives whether credits or the saved card is charged, which the schema's cycle description only partly conveys.

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 ('Launches a GPU server billed to the account') and immediately ties it to its prerequisite sibling gpucloud_quote_server, so an agent can separate it from quote/create_order/reserve_server without opening schemas. The title's '(spends money)' reinforces the distinguishing trait.

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 states the prerequisite (a confirmationToken from gpucloud_quote_server for exactly these arguments and key caps) and spells out when a card is needed versus when credits suffice. It stops short of naming alternatives such as gpucloud_reserve_server or gpucloud_create_order for other purchasing paths, so it is strong but not a full when/when-not routing guide.

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 annotations: warns of a brief but real server interruption (shutdown then automatic restart), enforces the at-most-2-manual-backups limit, and documents the single-use 10-minute token. This is rich operational context the readOnly/destructive/idempotent hints alone do not 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?

Front-loads the core action and its most important consequence (interruption) before the procedural steps. Dense parentheticals pack in constraints efficiently, though the stacking of caveats makes it slightly crammed.

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 action, side effects, limits, prerequisites, auth requirements, and the confirmation protocol. An agent has everything needed to call it safely and 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 coverage is 100%, so the baseline is 3, but the description adds genuine workflow meaning for confirmationToken — the two-call handshake and why the first call is made without it — which the schema's one-line field description 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?

States a specific verb and resource — start a backup of the server's system disk now — and the 'now' scoping clearly distinguishes it from the sibling gpucloud_set_server_backup_policy (policy config) and gpucloud_restore_server_backup (restore). An agent can pick it correctly 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?

Explicitly states preconditions ('the option must be enabled'), the two-step confirmation flow, and the required permission (servers:backup). The call-without-token → ask-user → call-with-token sequence tells the agent exactly when and how to invoke it.

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 mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description's job is lighter. It usefully adds authorization context the annotations lack: the required scope is support:write and a free account plus MCP key is needed. It still omits practical traits such as duplicate-ticket behavior or any rate limit.

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 with zero filler, and the core action is front-loaded before the parenthetical permission and prerequisite notes.

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 mutation profile and prerequisites are covered, but with no output schema the description could have said what comes back (e.g. a ticket ID, which gpucloud_reply_ticket would need) and it adds nothing about the required subject/message parameters. Adequate but with visible gaps.

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 carry the parameter burden. It names the category choices (billing, technical, other), but those are already the enum values, so no real meaning is added for subject or message, whose content and length constraints are left 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 ('Open a support ticket') and scopes it with the team and the three categories. It is clearly distinguishable from read-oriented siblings like gpucloud_list_tickets, but it never explicitly contrasts itself with gpucloud_reply_ticket, the nearest alternative.

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 by the description and prerequisites ('Requires a free GPU Cloud account and MCP key') and the support:write permission, which helps an agent decide it can call the tool. However, there is no explicit when-to-use guidance or exclusion against gpucloud_reply_ticket / gpucloud_list_tickets.

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 safety profile is covered structurally. The description adds genuinely useful context beyond that: the required scope 'firewall:write', the preconditions (ready server, free GPU Cloud account + MCP key), which the annotations do not 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?

A single front-loaded sentence; the core action leads and supporting details are parenthesized/bracketed. It is appropriately sized for a two-parameter delete, with only mild clutter from the trailing account requirement note.

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 a delete tool returns little of consequence, and the annotations plus description jointly cover safety, idempotency, scope, and preconditions. What remains unstated (e.g., whether the rule ID stays valid afterward) is minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented in the schema, including the 'fw_...' format and the source list tool. The description restates the ruleId origin but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 ('Removes') and resource ('a firewall rule'), and goes further by naming where the ruleId comes from (gpucloud_list_firewall_rules) and the precondition that the server be 'ready'. It is clearly distinguishable from its nearest sibling gpucloud_add_firewall_rule, though the differentiation is implied by the verb 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 parenthetical pointing to gpucloud_list_firewall_rules hints at the prerequisite lookup step, and 'ready server' hints at a precondition. There is no explicit when-to-use vs when-not-to-use guidance, and no alternatives are named.

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=false, and the description adds real context on top: irreversibility of the data loss, the mandatory confirmation-token handshake, and the per-call permission requirement. This is exactly the behavioral detail 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 sentences, front-loaded with the irreversible consequence, then permissions, then the procedural steps. No filler; the bracketed account note is the only mildly extraneous element.

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 tool with no output schema, the description covers safety, authorization, and the full call sequence. An agent has everything needed to invoke it correctly without opening 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?

Schema coverage is 100%, so both fields are already documented, which sets the baseline at 3. The description goes further by explaining why confirmationToken exists and how it is obtained (first call returns warning + token), effectively describing the protocol rather than just the field.

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 destroys a server and ALL its data'), making the destructive scope unmistakable. It does not, however, contrast itself with the near-neighbor sibling gpucloud_cancel_server, so an agent must still infer the delete-vs-cancel 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?

Gives concrete operating context: the required permission (canDelete / servers:delete) and the exact two-step confirmation procedure. It stops short of stating when this is preferable to cancel_server or hibernate_server, which is the one remaining routing gap.

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 usefully adds behavior annotations do not carry: servers already created retain the key after deletion, and the call requires the ssh_keys:write permission. This is exactly the kind of non-obvious consequence an agent should know.

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?

One tightly written sentence with the consequence-of-deletion fact front-loaded, followed by a compact permission note and account prerequisite. No padding, though the bracketed account/MCP-key boilerplate is generic rather than tool-specific.

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 single-parameter delete, the description covers the operation, its side effect on existing servers, the required permission, and the account prerequisite, which is reasonable coverage given the annotations. The main gap is the unaddressed keyId parameter, leaving an agent unclear on how to obtain a valid value.

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% and the only parameter, keyId, is never mentioned in the description. With a required 1-parameter tool and no schema docs, the description should compensate by explaining where the keyId comes from (e.g., gpucloud_list_ssh_keys) or its format, 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 states a specific verb and resource ('Removes an SSH public key from the account'), which cleanly separates it from siblings like gpucloud_add_ssh_key, gpucloud_generate_ssh_key, and gpucloud_list_ssh_keys. It does not explicitly name an alternative, but the verb/resource pair 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?

Usage is only implied – an agent can infer this is the tool to revoke a stored key, and the parenthetical clarifies a side effect. There is no explicit statement of when to use this versus generate_ssh_key or add_ssh_key, nor any prerequisite ordering 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?

Goes well beyond the annotations (readOnlyHint=false, idempotent=false, destructive=false) by disclosing server-side generation, that only the public key is persisted, that the private key is returned exactly once and never stored, the chmod 600 follow-up, and the required permission/account. This is the exact behavioral context an agent needs for an irreversible one-shot secret.

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 the critical warning (private key shown once, save it) placed before the parenthetical prerequisites. Dense but every clause carries information; the trailing bracketed notes are slightly cluttered but not wasteful.

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 for the crucial part (private key returned once, public key stored). The only real gap is the undocumented 'name' input, but the operational contract is fully covered.

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 sole parameter 'name' has 0% schema description coverage and the description never mentions it, so neither structured field nor prose explains what the name is used for (label, uniqueness constraints, etc.). With coverage this low the description was required to 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?

States a precise verb and resource ('Generates a new ed25519 key pair server-side') and clarifies exactly what is stored vs returned, which cleanly separates it from the sibling gpucloud_add_ssh_key (upload an existing key) even without naming it.

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?

Prerequisites are stated (ssh_keys:write permission, free GPU Cloud account and MCP key), which is useful context, but there is no explicit when-to-use-this-vs-alternative guidance — nothing tells the agent to prefer this over gpucloud_add_ssh_key when the user already has a key.

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, so the safety profile is covered. The description adds genuine behavioral context beyond that: null means no cap, monthlyCapUsedCad is tracked in Montreal time, and once the cap is reached no automatic reload occurs until the next month. It stops short of describing the response shape or formatting, so not 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?

Front-loaded with the core purpose and dense with signal, but the single run-on sentence with heavily nested parentheticals makes it harder to parse than it needs to be. Every clause carries information, so little 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?

With no output schema, the description must carry the return-value burden, and it does — enumerating the cap, usage, and remaining/limit-reached fields. It also discloses the required billing:read permission and free-account prerequisite, leaving nothing an agent needs in order 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?

Zero parameters, so the schema imposes no semantic burden and the baseline is 4. The description instead clarifies the meaning of returned fields (null = no cap, timezone semantics), which is valuable though technically output rather than 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 resource (automatic credit reload settings) and enumerates exactly what is returned: threshold, amount charged to the saved card, and the monthly cap fields. An agent can distinguish this read-only getter from the sibling gpucloud_set_auto_reload 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?

Usage is implied by the getter/setter pairing with gpucloud_set_auto_reload, but the description never explicitly states when to call this versus alternatives, nor any exclusions. The permission/account prerequisites are given, but routing guidance is left 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: the required billing:read permission scope and the dependency on a free GPU Cloud account plus MCP key. It says nothing about freshness of the balance, return format, or currency conversion behavior, so it is additive but not rich.

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 compact sentence that front-loads the three things the tool returns, followed by the permission and dependency notes in brackets. Every clause earns its place, though the bracketed annotations make the line slightly dense.

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 no-parameter, read-only tool with no output schema, the definition covers what it returns and the auth/account prerequisites an agent needs before calling it. Minor gaps remain around return-field details and update cadence, but nothing essential to correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter syntax or semantics for the description to clarify, and it correctly makes no attempts to describe inputs.

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 a specific resource and its returned fields: credit balance in CAD, current hourly running cost, and low-balance notice. This is far more informative than a tautology and implicitly separates it from siblings like gpucloud_get_budget or gpucloud_list_transactions. It stops short of explicitly naming an alternative or scope boundary, so it lands at 4 rather than 5.

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 by the name and returned fields – an agent can infer 'call this to check credit', but there is no explicit when-to-use, when-not-to-use, or alternative (e.g., gpucloud_get_budget for spending limits). It does supply a prerequisite in the permission note, which lifts it above the bare 'no guidance' tier.

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=true and destructiveHint=false, and the description goes well beyond them: it discloses the enforcement consequence of hitting the limit (hourly servers hibernated with no data loss, prepaid servers unaffected), the specific refused operations and the BUDGET_LIMIT_REACHED error code, plus the billing:read permission and account/MCP-key prerequisites.

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?

Information-dense but the parenthetical clauses and the long enforcement sentence are all load-bearing; the core identity (budget limit, currency, period) is front-loaded. Slightly heavy prose, but very little 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?

With no output schema, the description carries the return-value burden, and it does so explicitly: limit, spend this month/today, percentage used, remaining, and whether the limit was reached. Permission, prerequisites, and enforcement side effects are all covered, so an agent has everything needed.

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 nothing for the description to disambiguate. The description instead fully characterizes the returned values, which is the closest analogue for a no-arg read tool.

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+resource (the account's monthly budget limit and optional daily limit) and pins down currency (CAD) and calendar definition (America/Toronto), which is unusual precision. It is clearly distinguishable from sibling tools like get_balance (money on account) and set_budget (the write counterpart).

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 the use case by enumerating what it returns (limit, spend, percentage used, remaining, reached flag), but it never states when to reach for this tool versus get_balance or get_auto_reload, nor does it name any alternative. Usage is left to inference from the content.

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 say readOnlyHint=true, idempotentHint=false, openWorldHint=false; the description adds substantial context the agent cannot get elsewhere: the required permission scope (servers:console), that no session link is ever issued to an agent, that the login password is never returned through this tool, and a precise enumeration of failure codes with remedies. No annotation is contradicted.

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 core action and the RUNNING/ACTIVE precondition, followed by behavioral caveats and then the error taxonomy. The error-code list is dense but each code maps to a distinct remediation, so it earns its length; the trailing permission/account note is slightly tacked-on.

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 must explain the return value — it does, stating a console page link and explicitly what is NOT returned (session token, login password). Combined with the precondition, permission requirement, and full failure-code coverage, an agent has everything needed to call this 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 100% and there is a single parameter with a descriptive field and a pointer to gpucloud_list_servers, so the schema carries the semantics. The description adds nothing parameter-specific beyond what the schema already states, which is the expected baseline when the schema is 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?

The description states a specific verb and resource: it returns a link to the web (VNC) console page of a RUNNING/ACTIVE server. It is unambiguous and clearly separable from data-returning siblings like gpucloud_get_server, since it explicitly says it merely issues a page link and never a console session token.

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 clear context for use (owner signed in, to repair SSH or network on a running server) and enumerates the refusal conditions with remediation (start, restore, retry, credits/budget, failed/deleted), which effectively defines when-not-to-expect-success. It stops short of naming alternative sibling tools an agent should call instead in those cases, so it is strong but not complete routing 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?

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description adds value beyond that by disclosing the required billing:read permission and the account/MCP-key requirement, and notes the response includes invoice lines.

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 fragments with the resource and identifier options front-loaded; no filler. Slightly telegraphic, but every clause 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 simple read-only getter with annotations covering safety and no output schema, the definition supplies the key facts: single-invoice scope, accepted identifier forms, required scope, and account prerequisite. Return-shape detail is minimal but the description notes 'its lines'.

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 0% and the lone invoiceId parameter has no schema description. The description compensates by explaining it accepts either an internal id or an invoice number, which is meaningful format guidance the schema omits.

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 (get) and resource (invoice) and narrows scope to a single invoice 'with its lines', implicitly distinguishing it from the sibling gpucloud_list_invoices. It never names the sibling explicitly, so it is clear but not fully differentiated.

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: fetch one invoice when you already have its id or number. There is no explicit when-to-use vs when-to-prefer-list_invoices guidance or stated prerequisites beyond the account requirement.

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 safety is covered. The description adds real behavioral context beyond that: the required 'orders:read' permission scope and the need for a free GPU Cloud account and MCP key, which an agent needs before attempting the call.

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 short, front-loaded fragment that delivers the core action first, followed by permission and account preconditions. No filler, though the parenthetical metadata makes it read more like a terse note than a structured guideline.

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 read-only lookup with no output schema, the description covers the action, the accepted identifier forms, the required permission, and the account prerequisite. Return-value and error semantics are left unstated, but the annotation set makes this largely adequate.

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 carry the parameter meaning. It does usefully state that orderId accepts either an internal id or a payment reference of the form GPU-CMD-..., which the bare schema property name would not convey. It leaves the exact id format loosely specified, hence not a 5.

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 (get) and resource (one order), and scopes it as single-record retrieval by id or payment reference. This distinguishes it from the sibling list_orders, though it stops short of naming that alternative.

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 'One order by id or payment reference' implies this is the single-record lookup used when you already have an identifier, but it never explicitly says when to prefer this over gpucloud_list_orders or what conditions select it. Usage is implied 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?

Annotations already carry the read-only/idempotent safety profile, yet the description still adds real value: the masked return fields, the 'required for any spend' constraint, the needsReentry=true failure mode (charges rejected until re-entered in console), and the billing:read permission scope. That is more context than the annotations provide.

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 resource and what it returns, then the usage constraint, then the edge case. Dense but every clause earns its place; the trailing bracketed account/key note and double parentheticals add minor visual clutter.

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 zero-param, no-output-schema read tool, the description covers the return shape (masked card), the precondition for calling it, the degraded-state behavior, and the required permission. Nothing an agent needs to invoke or interpret 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 tool takes zero parameters, so no per-parameter semantics are required — schema coverage is 100% and there is nothing to document. Baseline 4 applies; there is no parameter detail the description could add.

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+resource and even scopes the return ('The saved card (masked: brand, last 4 digits, expiry)'). It is trivially distinguishable from the sibling gpucloud_add_payment_method because this reads the stored card rather than creating one.

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?

'Required for any spend by an agent' tells the agent exactly when this call is a prerequisite, and the needsReentry note explains a state where re-entry must be routed to the console. It does not explicitly name an alternative tool, so it falls just short of 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 establish read-only, non-destructive, closed-world behavior, and the description adds real context beyond them: it works unauthenticated against public catalog prices, returns account-specific prices when an MCP key is present, and requires the catalog:read scope. It doesn't describe error behavior for an unknown productId, but the auth/cost model it discloses is the higher-value information.

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 statement and the ID source are front-loaded in the first sentence, and the auth/key semantics come near the end where they belong. The middle sentence about GPU models, Montréal, and 'launched in minutes' is marketing-flavored and mostly non-operational, though the CAD/hourly pricing detail does earn some of its space.

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 steps in by naming what comes back (CAD prices, live availability) and covers both authenticated and anonymous invocation paths plus the required permission. For a one-parameter read tool that is essentially complete, with only edge-case behavior 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?

Schema description coverage is 0% for the single productId parameter, so the description must carry the meaning — it does by stating where the ID comes from (gpucloud_list_products). It adds no format or length guidance, but the origin hint is enough to call the tool correctly.

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+resource: fetches one GPU server product with CAD prices and live availability. It also names the sibling that supplies the identifier (gpucloud_list_products), so an agent can distinguish this single-product getter from the catalog listing 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?

The parenthetical '(productId from gpucloud_list_products)' makes the precondition and the preceding call explicit, which is the key routing guidance for a by-ID getter. It doesn't address when to prefer gpucloud_get_stock or gpucloud_quote_server for pricing questions, so it stops short of full when/when-not coverage.

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 closed-world, so the safety profile is covered. The description adds real context beyond them: the required permission scope (profile:read), the account/MCP-key prerequisite, and the important boundary that email/password/2FA are owner-managed in the console and never handled by an agent.

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, front-loaded clauses: what is returned, then the credential-management boundary, then permission and prerequisites. The bracketed prerequisite is slightly noisy but each sentence carries distinct 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 compensates by enumerating the profile fields returned and stating the auth/permission prerequisites. Nothing essential for correct invocation is missing, though naming the sibling whoami tool would close the last 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?

The tool takes no parameters, so the baseline is 4. The description correctly implies a no-argument call and instead spends its words on what the read returns and the permission needed to perform 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?

The description names a specific resource (the account profile) and enumerates the fields returned (name, email, company, phone), so an agent knows exactly what it gets back. It does not, however, distinguish this from the sibling gpucloud_whoami or contrast with gpucloud_update_profile, which is the one remaining ambiguity.

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 — it is a read-only lookup gated by profile:read and an account/MCP key. There is no explicit statement of when to call this versus gpucloud_whoami (identity-only) or the console, leaving the agent to infer the distinction.

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 readOnly/destructive annotations, it discloses real behavioral traits: status is refreshed while an operation is in progress, a STOPPED server is still billed at the full hourly rate while a HIBERNATED one bills at the lower hibernation rate, and it requires the servers:read permission plus an account/MCP key. This is exactly the context an agent cannot 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?

It is a single long sentence, but it is front-loaded ('One server:') and the field enumeration earns its place because no output schema exists. Slightly dense, but nothing 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?

With no output schema, the description usefully carries the return shape (status, billing, IPs, suspension, activity events) and the permission requirement. It stops short of explaining how this differs from the metrics/usage siblings, which would complete the picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single serverId parameter, so the schema already carries the meaning (including its origin from gpucloud_list_servers). The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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 'One server' and enumerates exactly what comes back (status, machineState, billing rate, IPs, SSH command, activity events), making the retrieve-single-server purpose concrete. It does not name or distinguish itself from near siblings like gpucloud_get_server_metrics or gpucloud_get_server_usage, so it falls short of a 5.

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?

There is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives such as the metrics/usage siblings. The only routing hint is in the schema ('Server id from gpucloud_list_servers'), not the description.

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=true and destructiveHint=false, so safety is covered. The description adds genuine value beyond that: metrics come back null while the server is not ready or metrics are still collecting, plus a servers:read permission requirement and an account/MCP-key prerequisite.

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 resource ('CPU, RAM and network usage series') and appends the availability caveat and permission tags compactly. No filler, though the bracketed account requirement is somewhat boilerplate.

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 usefully characterizes the return as a usage series and explains the null state, and it discloses the permission scope and prerequisite. Only return formatting/window details are absent, which is a minor gap for a read-only metrics 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?

Schema coverage is 100% with a single serverId parameter that already documents its origin (from gpucloud_list_servers). The description adds no parameter syntax or format detail, so this is the baseline 3 where the schema carries the load.

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 resource and read action: 'CPU, RAM and network usage series of a server'. An agent can tell it retrieves a time series rather than a snapshot, but it does not distinguish itself from the similarly-named sibling gpucloud_get_server_usage.

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?

There is no explicit when-to-use guidance and no routing to alternatives such as gpucloud_get_server_usage or gpucloud_get_server. The only contextual pointer is the schema reference to gpucloud_list_servers as the id source.

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 (readOnlyHint=true, destructiveHint=false), yet the description adds substantial behavior detail: line-item contents (period, amount drawn from credit, balance after), the first-hour-at-deployment rule, refunds, totals, hourly rate, and live billing status. 'Read-only' merely restates the annotation, but the surrounding detail is genuinely additive. It stops short of disclosing pagination behavior, which matters because idempotentHint is 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?

The critical scope ('hour-by-hour billing of one server, deleted ones included') is front-loaded in a single dense sentence; the permission and account notes are tacked on compactly. The colon-and-semicolon enumeration is slightly run-on but every clause carries 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 the return shape and does so thoroughly (per-hour rows, amounts, balances, totals, rate, current billing flag). The main omission is pagination semantics for the two undocumented paging parameters.

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 only 33% — serverId is documented (referencing gpucloud_list_servers) but page and pageSize carry no description in either the schema or the description. With low coverage the description is expected to compensate, and it provides no parameter-level information at all.

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 (hour-by-hour billing of one server) and even scopes it with 'deleted ones included', which is a meaningful differentiator from sibling billing tools like gpucloud_get_invoice or gpucloud_list_transactions. An agent can tell exactly what this returns 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?

Usage is implied by the content (server-scoped billing history with a billing:read permission), but there is no explicit when-to-use or when-not-to-use guidance and no named alternative such as gpucloud_get_invoice or gpucloud_list_transactions. The 'Requires a free GPU Cloud account and MCP key' line is a prerequisite, not a routing rule.

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 readOnly/destructive/openWorld, so the safety bar is low; the description still adds real context by stating that no API key is required and that prices are public catalog prices, which materially affects how an agent may call it. It does not mention caching, refresh cadence, or what a returned entry contains, but with annotations present this is a solid contribution.

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 core claim and only three short sentences. The parenthetical GPU model enumeration is somewhat long for what it conveys, but it does double duty as scope documentation rather than 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?

No output schema exists, and the description does not say what a stock entry looks like (per-model price, quantity available, region), which is the one gap an agent must probe for. Everything else needed to decide whether to call it — region, auth, freshness semantics, permission — 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?

Zero parameters, so the baseline is 4 by rule. The description correctly gives no parameter guidance and instead usefully notes that the region scope is fixed to Montréal — information an agent would otherwise have to guess, since there is no region parameter to inspect.

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 (live availability) and resource (GPU servers for rent) with scope nailed down to Montréal and an enumerated GPU model list. The phrase 'what can be launched right now' clearly separates it from catalog-style siblings like list_products and get_product, which describe offerings rather than live stock.

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 by 'what can be launched right now' — an agent can infer this is the pre-launch availability check. But no sibling is named as an alternative, and there is no explicit statement of when to prefer this over gpucloud_list_products, gpucloud_get_product, or gpucloud_quote_server, all of which sit in the same discovery phase.

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 prose itself is unusually rich: it discloses billing change, work-disk erasure, memory/process loss, IP release and host-key change, backup-first option (~12 min, billed), the 72 h auto-deletion with notices, and required permissions. However, 'the WORK DISK ... is ERASED' is irreversible data loss, which conflicts with the destructiveHint=false annotation, so the description and annotations disagree on the safety profile.

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?

There is no filler — every clause carries operational meaning — but it is delivered as one very long, colon-chained block that buries key items (IP release, 72 h deletion) in the middle rather than front-loading them as scannable points.

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 covers the return payload (notKept, backupFirst, customerHibernation with maxHours/deleteAt/message), the permission requirement, and the full lifecycle, leaving nothing an agent needs to warn the user about.

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 already documents serverId at 100% coverage with its source (gpucloud_list_servers), so the baseline is met; the description adds the useful output-field semantics (notKept, backupFirst, customerHibernation) that an agent needs to interpret the result.

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 ('Hibernates a server') and immediately defines what hibernation means (lower billing rate, kept disk, erased work disk), which separates it from siblings like gpucloud_stop_server, gpucloud_cancel_server and gpucloud_delete_server.

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 states when to use it (to pay the HIBERNATION RATE instead of hourly), the alternative for a different goal ('to stop paying entirely, delete the server'), the restore path (gpucloud_restore_server) and the 72 h deadline, plus the obligation to tell the user the cost first.

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=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely useful context the annotations do not carry: the required permission (servers:read), the free-account/MCP-key prerequisite, and domain rules such as full refund if not in service within 7 business days. It stops short of describing ordering or result volume.

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?

Everything in the text earns its place because there is no output schema to carry the field list, but the delivery is a single ~120-word run-on sentence with nested parentheses, mixing the GPU/term enumeration, field list, status enum and refund policy without structure. Front-loading is decent (the resource comes first) but readability suffers.

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 no parameters, the description carries the full burden of describing what comes back, and it does so thoroughly: fields, status enum values, delivery deadline rule and the serverId once delivered. It omits ordering, pagination and any disambiguation from gpucloud_list_monthly_rentals, 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?

The tool takes zero parameters, which is the baseline 4 case. The description spends its words on the returned content instead, listing statuses, terms, amounts and dates, which is the right place for detail given the schema is empty.

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 resource and verb: guaranteed H100s rented by month on the account, with the exact fields returned. It is far more than a restatement of the name. However, it never addresses the awkward fact that the title calls this the 'former name' while the sibling gpucloud_list_monthly_rentals appears to cover the same subject, leaving the agent unable to tell the two apart.

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?

There is no when-to-use guidance, no exclusions, and no mention of the near-identical sibling gpucloud_list_monthly_rentals. The only usage-adjacent statement is 'Read only: the user rents it in the GPU Cloud console', which describes a constraint rather than when to select 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 readOnlyHint=true and destructiveHint=false, so safety is covered, but the description adds real behavioral context: results are empty during server creation, the read scope is firewall:read, and a free GPU Cloud account plus MCP key is required. It stops short of describing return format or pagination, which would push it higher.

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 compact fragments with no redundant prose, and the resource identity is front-loaded ahead of the state caveat and permission note. It is appropriately sized for a single-parameter read 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 one-parameter read-only list with no output schema, the description plus annotations cover what an agent needs: scope, safety profile, state caveat, and auth requirement. Only the return shape and pagination behavior are left unspecified, a minor gap for this tool class.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the serverId description already tells the agent to source the id from gpucloud_list_servers. The description adds nothing about the parameter, so the baseline 3 applies.

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 phrase 'Firewall (security) rules of a server' clearly identifies the resource and implies a read/list operation, distinguishing it from the sibling mutations gpucloud_add_firewall_rule and gpucloud_delete_firewall_rule. It omits an explicit verb like 'list', so it falls just short of the crispest possible statement of intent.

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 by the resource name; the description never states when to call this versus the add/delete firewall siblings or what prerequisite states exist. The one useful context nugget, that results are empty while the server is being created, is a state caveat rather than routing 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds real context beyond them: the call works without a key (auth requirement) and it discloses the required permission scope 'catalog:read'. It also notes the payload carries each image's default SSH user, which is behaviorally useful.

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 tight sentence plus a permission parenthetical — no padding or repetition. The ordering is slightly off, since it opens with what an image is rather than what the tool does, but the text is appropriately sized for a zero-arg list call.

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 parameterless read with no output schema, the description supplies the essential extra facts an agent needs: no key required, the permission scope, and one field present in the results (default SSH user). It stops short of confirming what else each entry contains or that the full catalog 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?

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The one parenthetical ('with its default SSH user') describes returned content rather than an input, so it does not add parameter meaning.

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 defines the resource ('Operating-system image installed on each GPU product') but never states the action — that this tool lists/returns the available OS images. An agent must recover the verb from the name and title. It also gives no differentiation from the neighboring catalog list tools such as gpucloud_list_templates or gpucloud_list_products.

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?

'Works without a key' is a faint usage hint (usable unauthenticated), but there is no when-to-use framing, no exclusions, and no pointer to the alternatives among the many list_* siblings. The agent gets no routing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds real value beyond them: the meaning of each status (PAID, CREDITED, DUE, VOID), the fact that some invoices were settled with credits, the required billing:read permission, and the account/MCP key prerequisite. It does not mention pagination or ordering of results.

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?

One dense sentence with the resource and status taxonomy front-loaded, followed by the read-only and permission caveats. The nested parentheticals make it slightly cluttered, but every clause carries information 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?

With no output schema, the description compensates by naming the fields returned (status, due date, overdue flag) and explaining the status enum values. Combined with the permission and account requirements, an agent has everything needed to call and interpret this 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies since no parameter documentation burden exists.

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 the resource precisely (invoices of the account) and defines both categories it covers: monthly usage statements paid with credits and invoices still to pay. It does not explicitly differentiate itself from the sibling gpucloud_get_invoice, relying on the reader to infer list-versus-single.

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 establishes the read-only context and notes that payment happens in the console, which implicitly tells the agent this tool is for viewing only. However, it never states when to reach for this tool versus gpucloud_get_invoice or gpucloud_list_transactions, so usage is implied rather than directed.

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=true and destructiveHint=false, so the safety profile is covered. The description goes further by disclosing the permission required (servers:read), the account/MCP-key prerequisite, and a concrete business rule (put in service within 7 business days or refunded in full), which is real context beyond the 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?

The core purpose is front-loaded, and every element earns its place given there is no output schema. It is a single dense sentence with a long parenthetical field list, which is slightly overloaded but justified by the absence of structured return documentation.

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 fully compensates by enumerating returned fields, the complete status enum, timing rules, permission, and prerequisites. An agent has everything needed to call this zero-argument tool and interpret its results.

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 input parameters, so the baseline is 4. Schema coverage is 100% and the schema accepts no properties; the description instead documents the return shape (statuses, amounts, dates), which is relevant but not a substitute for parameter documentation that doesn't exist.

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 (list) and a tightly scoped resource ('H100 rented by the month on the account'), which naturally distinguishes it from broader siblings like list_reservations or list_contracts. It never names an alternative tool, but the H100/monthly scope is specific enough that an agent can identify the right tool.

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 implies usage context by noting 'Read only: the user rents it in the GPU Cloud console,' which tells the agent this tool cannot create rentals. However, it gives no explicit when-to-use/when-not guidance or contrast with siblings such as list_reservations or list_contracts, leaving the routing 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 readOnly=true and destructive=false, so the safety profile is covered. The description adds non-annotation context: the required permission scope (orders:read) and the account/MCP-key prerequisite, which are real behavioral constraints. It doesn't disclose pagination or rate-limit behavior, keeping 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?

Two compact sentences with no filler; the resource and its contents are front-loaded before the permission and prerequisite parentheticals. Minor density from stacked brackets but still efficient.

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 read-only list tool with no output schema, the description usefully names the returned contents (items, payment reference) and the permission needed. However, with no output schema and an undocumented 'limit' parameter, it omits how results are paged or capped, leaving a modest 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 0% for the lone 'limit' parameter, so the schema only gives bounds and a default without meaning. The description never mentions 'limit' or how pagination/result capping works, failing 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?

Names a specific verb and resource ('Orders of the account') and clarifies scope with 'checkout and renewals', plus what each order carries (items, payment reference). It distinguishes itself from gpucloud_get_order implicitly via the plural list framing, but never names the sibling explicitly.

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 by the 'list' verb; there is no explicit when-to-use or when-not guidance, and no contrast with gpucloud_get_order, gpucloud_create_order, or gpucloud_list_invoices. The permission note ('orders:read') hints at the caller context but does not route between alternatives.

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 context beyond the annotations: works without a key returning public catalog prices versus account-specific billed prices with an MCP key, spot machines are interruptible and hourly-only, and the catalog:read permission is required. The 'launched in minutes' phrasing is marketing filler rather than behavior, keeping it from 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?

Front-loaded correctly with the 'start here' cue, but the body carries promotional padding ('from CA$0.78/h', 'launched in minutes') and a long list of GPU model names. The account-vs-public-key behavior is the key information and is buried mid-paragraph rather than stated up front.

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, so the description compensates by describing what is returned: CAD prices per machine (hourly and monthly) and live availability, plus account-specific prices and auto-deploy eligibility when keyed. Adequate for an agent to know what to expect from the response.

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 and full schema coverage, so the baseline is 4; there is nothing for the description to disambiguate. The description correctly avoids inventing parameters.

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 ('Lists every GPU server for rent') with scope spelled out: 1-8 GPUs per machine, spot vs hourly, CAD prices, live availability. It is clearly distinguishable from siblings like get_product (single product) and get_stock because it enumerates the whole 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?

Opens with an explicit entry-point directive: 'Start here when a user needs a GPU (training, fine-tuning, inference, LLM serving, rendering, notebooks).' That gives a clear trigger context. It stops short of naming an alternative or a when-not-to-use condition (e.g., vs get_product or list_stock).

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 closed-world, so the safety profile is covered. The description adds meaningful context beyond them: that the endpoint is callable without a key and requires the catalog:read permission, which tells the agent it can be invoked pre-authentication.

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?

Compact and front-loaded: the resource is stated first, then practical caveats (no key, permission scope). Every clause carries information, though the parenthetical permission note at the end is slightly buried and the region list is only an example, not exhaustive.

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 no parameters, the description should say something about the returned shape (e.g. region identifiers/codes and country fields) so an agent can chain it into create_server or quote_server. It covers auth and scope but leaves the return contract entirely 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?

The tool takes zero parameters and the schema is an empty object, so there are no parameter semantics to clarify; the baseline for a no-param tool is 4. The description correctly implies the call is parameterless and returns a fixed catalog.

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: regions where GPU servers can be deployed, with a concrete example (Montréal, Canada) that makes the resource unambiguous. 'Regions' is unique among the list_* siblings, so no explicit sibling differentiation is needed, though the description never confirms this is a global, account-independent 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?

Gives useful situational context ('works without a key', public catalog prices) that tells the agent this call needs no authentication, but offers no explicit when-to-use guidance or routing versus siblings such as list_products or get_stock, which an agent may confuse when looking for deployment locations.

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=true and destructiveHint=false, so the safety profile is covered; the description goes beyond them by disclosing the required permission scope (servers:read) and the account/MCP-key prerequisite, which are real invocation blockers. It stops short of mentioning pagination or result limits for large reservation lists.

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?

One dense sentence front-loads the resource and its fields, with prerequisites tucked into brackets at the end. Every clause carries information; the enumerated status values are slightly list-heavy but they communicate real domain state.

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's enumeration of returned fields (including serverId once fulfilled) usefully compensates. Combined with the stated permission and account prerequisites, an agent has enough to call it correctly; only pagination/result-size behavior is 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?

The tool takes zero parameters, so there is nothing for the description to clarify beyond confirming it is unfiltered account-wide listing. Per the zero-parameter baseline, a 4 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 gives a specific verb+resource ('GPU reservations of the account') and even enumerates the returned fields (machine, status, queue position, max price, end date, serverId), so the agent knows exactly what listing this returns. It does not explicitly name sibling tools like gpucloud_reserve_server or gpucloud_cancel_reservation, but the scope 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?

Usage is only implied: this is the read/list counterpart to gpucloud_reserve_server and gpucloud_cancel_reservation, and the status enum hints it is used to track reservation lifecycle. The description adds a hard prerequisite (free GPU Cloud account + MCP key) but never states when to prefer this tool over alternatives or that no arguments are accepted.

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=true, destructiveHint=false, and openWorldHint=false. The description adds the required permission and account context, but it spends most of its text describing the backup feature itself (including server interruption during backups), not the behavioral traits of this read-only listing call, and it never mentions pagination or return shape.

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 text is a long run-on that front-loads a dense parenthetical enum list instead of clearly stating what the tool does. Much of the content explains backup policy and billing details rather than the listing operation, so it is not efficiently structured for this 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?

With no output schema, the description does usefully enumerate returned backup fields (id, kind, status, date, size) and their possible values. However, it does not clearly distinguish backup records from backup option state, nor does it explain the return shape or pagination, leaving the agent with an incomplete picture for a list 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?

Schema description coverage is 100%, so the single serverId parameter is already explained by the schema as coming from gpucloud_list_servers. The description adds little beyond the schema, so the baseline 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 names the resource and enumerates backup fields and statuses, but it never states the action clearly — no verb such as 'list' or 'returns' — and it conflates the backup option with the backups themselves. The name 'gpucloud_list_server_backups' does most of the work; the description alone leaves the purpose somewhat vague.

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?

There is no guidance on when to use this tool versus siblings such as gpucloud_create_server_backup, gpucloud_set_server_backup_policy, gpucloud_restore_server_backup, or gpucloud_list_server_snapshots. The only prerequisite-like context is the permission note 'servers:read' and the account requirement.

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=true and destructiveHint=false, so the safety profile is covered. The description adds what the annotations do not: the required permission scope (servers:read), the account/MCP-key prerequisite, and the set of fields returned, which is valuable behavioral context for a read tool lacking 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?

Two short clauses with no filler: the resource and returned fields come first, followed by the permission and account prerequisites. Every word earns its place and nothing is repeated from the structured fields.

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 no-argument, read-only list tool with no output schema, the description compensates by enumerating the returned fields and stating auth/permission requirements. It omits pagination behavior and result ordering, which are the only remaining gaps for an agent calling this 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 per the baseline there is no parameter semantics to document and the description cannot add value here. It does not misdescribe any input, so the neutral baseline of 4 applies.

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 resource ('GPU servers of the account') and enumerates the fields returned (status, IPs, rate, paid-until date, suspension), so an agent knows this enumerates servers rather than fetching one. It does not explicitly name the verb 'list' or distinguish itself from the sibling gpucloud_get_server, but the plural resource makes the distinction inferable.

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 gives prerequisites ('Requires a free GPU Cloud account and MCP key') and a permission scope, which is genuinely useful context, but it never says when to use this versus gpucloud_get_server or the metrics/usage siblings, nor any exclusion. Usage is only implied by the plural resource.

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=true, destructiveHint=false, openWorldHint=false, and idempotentHint=false, so the safety profile is fully covered. The description adds useful auth context by stating the required permission (servers:read) and account/MCP key requirement. It does not add return format or pagination details, but given the annotation coverage, this is an appropriate level.

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 very short, but its main sentence 'Snapshots of a server' is redundant with the title and does not earn its place. The bracketed permission and account notes are useful, but the overall structure is under-specified rather than efficiently concise, similar to sparse definitions that leave an agent without needed context.

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 simple read-only list operation with a fully documented single parameter and complete safety annotations, the description provides the essential auth requirements and confirms the resource. However, it still lacks a clear operational verb and any usage context, so it is only minimally complete for an agent unfamiliar with the API. The combination of annotations and schema fills most of the 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 100% and the single serverId parameter is documented in the schema as coming from gpucloud_list_servers. The description adds no additional parameter meaning, syntax, or examples beyond what the schema provides. With full schema coverage, the baseline score of 3 is correct.

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 'Snapshots of a server' merely restates the tool title 'Server snapshots' without a verb or explicit statement that it lists snapshots. It does not distinguish this tool from the closely named sibling gpucloud_list_server_backups. This is a tautological restatement rather than a clear purpose statement.

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?

There is no guidance on when to use this tool versus alternatives such as gpucloud_list_server_backups or when to call it at all. The only conditions mentioned are permission and account requirements, which are prerequisites rather than usage selection criteria. No exclusions or comparisons are provided.

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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description does add value beyond the annotations by disclosing the required permission scope (servers:read) and the account/MCP key prerequisite, but says nothing about pagination, result size, or what an empty response means.

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 compact fragments with the resource stated first and constraints parenthesized afterwards; nothing is padded. The account/MCP-key boilerplate is somewhat generic, but it is brief and clearly secondary.

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 one-parameter, read-only list tool whose annotations carry the safety profile, this is close to adequate, but it lacks any note on return shape or pagination behavior, and no output schema exists to fill that 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 100% and the single serverId parameter is fully documented in the schema, including its provenance ('from gpucloud_list_servers'). The description adds nothing further about the parameter, so the baseline of 3 applies.

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 a concrete resource ('Storage volumes attached to a server'), which clearly distinguishes it from siblings like list_server_snapshots, list_server_backups, and list_servers. It omits an explicit verb ('list'), though the tool name and the sibling family make the read intent 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?

There is no statement of when to use this tool versus alternatives, nor any prerequisite about needing an existing server id (that hint lives only in the schema). The permission scope and account requirement are contextual facts, not usage 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?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), but the description adds real value beyond them: the required permission scope (ssh_keys:read) and the account prerequisite (free GPU Cloud account plus MCP key). It stops short of describing pagination or return shape.

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 bracketed fragments, front-loaded with the resource. Every clause carries information (resource, purpose, permission, prerequisite), though the stacked parentheses are slightly clunky to read.

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 zero-parameter, read-only list tool with no output schema, the description covers what is listed, why the keys exist, the auth scope, and the account requirement. Nothing essential to calling 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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies per the rules.

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 resource — the account's SSH public keys — and adds parenthetical context that these keys are used to access new servers. The verb is implied rather than stated (it comes from the name), and it doesn't explicitly distinguish itself from add_ssh_key, delete_ssh_key, or generate_ssh_key, but the resource 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?

The clause 'used to access new servers' hints at why the keys matter, but there is no explicit when-to-use guidance or routing against the sibling ssh-key tools (add/delete/generate). Usage is only implied.

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 read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds genuinely useful context beyond them: it works without an API key and requires the catalog:read permission. The details about HTTPS-only exposure, authentication requirements, and credentials being shown only in the web console are about the templates' applications rather than the list call itself, but still informative.

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 content is front-loaded with what templates are, then downstream usage, then security/permission notes. It is dense but each clause carries real information; the HTTPS/certificate/credentials sentence is somewhat tangential for a pure list operation but not 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?

With no parameters and no output schema, the description does the heavy lifting by explaining what the templates contain and how they are used downstream. It stops short of describing the returned fields (e.g., that templates carry an id/name/model), which would fully close the loop for an agent consuming the list.

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 the baseline is 4. The templateId/templateModel mentions refer to parameters of sibling tools (quote_server/create_server), not this one, and correctly do not create confusion about arguments to provide here.

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 clearly identifies the resource ('Ready-to-use machines: the application installed at creation') and enumerates the concrete templates (JupyterLab, Ollama + Open WebUI, vLLM, ComfyUI, PyTorch), which lets an agent distinguish it from siblings like gpucloud_list_images or gpucloud_list_products. The 'list' action itself is only implied by the topic and title rather than stated as a verb.

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 shows the downstream path ('Pass templateId... to gpucloud_quote_server / gpucloud_create_server'), which implies this tool is the discovery step before creating a server, and notes 'Works without a key.' However, it never explicitly states when to call this vs. alternatives such as gpucloud_list_images, leaving usage 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 the safe read-only, idempotent, closed-world profile. The description goes beyond them by disclosing the required permission scope (support:read), the prerequisite of a free GPU Cloud account plus MCP key, and the constraint that image bytes are only viewable in the console rather than returned via the 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?

Front-loads the core purpose in the first sentence, then adds return-shape detail and prerequisites. It is dense with parentheticals, but each clause (permission, account requirement, image-bytes caveat) carries information 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?

With no parameters, no output schema, and strong annotations, the description carries the remaining burden well: it explains what comes back (tickets, messages, image metadata), the permission needed, and the account prerequisite. The only gap is the absence of explicit routing to the create/reply siblings.

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 per the rubric the baseline is 4; there is nothing for the description to clarify on the input side.

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+resource ('List support tickets') and even previews the content of the result (tickets with messages, and per-message images with id/fileName/mimeType/sizeBytes). This clearly separates it from the create_ticket and reply_ticket siblings, though the description never names those alternatives explicitly.

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 by the 'list' verb and the fact that tickets belong to the account, but there is no explicit when-to-use guidance or routing to create_ticket/reply_ticket for the write side. Adequate but not directive.

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 establish the safe read-only, non-destructive, closed-world profile. The description adds meaningful context beyond that: the permission scope required (billing:read) and the account/key prerequisite. It still omits ordering guarantees, pagination, and whether the list is capped by 'Latest'.

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 compact fragments with zero filler. The core purpose is front-loaded, and the permission/account notes are clearly delimited in parentheses and brackets.

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 simple, one-optional-parameter list tool with no output schema, the description adequately conveys what is returned (credit movements with payment references) and the auth context. It is slightly incomplete on limit behavior and result ordering, but nothing critical is missing for correct 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?

Schema description coverage is 0% for the single limit parameter, and the prose never mentions it. The schema supplies default 25 and max 100 but no meaning for the parameter, so the description 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 the resource clearly — credit movements — and enumerates the content types (top-ups, hourly usage, refunds) plus the included payment reference. It does not distinguish itself from adjacent siblings like list_invoices or get_balance, but an agent can identify the tool's function 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?

The description covers prerequisites (billing:read permission, free account + MCP key) but gives no guidance on when to choose this over get_balance, list_invoices, or other billing-related siblings. 'Latest' implies recent activity but is not framed as a selection rule.

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 openWorldHint=true and non-idempotent, but the description adds critical un-annotated behavior: the original server stays billed until deleted, only the 100 GB system disk is copied (work disk NOT copied), a new public IP is assigned, and the migration timing (~20 min fresh / ~5 min latest). These are consequential details an agent must surface before spending money.

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 core action and the money warning, then packs prerequisites and the step flow densely. Long but nearly every clause carries operational information; the "[SPENDS MONEY]" emphasis and repeated billing warnings are slightly redundant with the title but justified for a costly irreversible-ish action.

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, yet the description explains what each call variant returns (GPU list with prices; price+warning+token; start confirmation) and where results appear afterward. For a complex, high-stakes, multi-step tool, this leaves nothing essential unsaid.

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 100%, so the schema documents all six parameters; the description still adds value by explaining the stateful three-step progression of targetProductId (absent → lists GPUs with prices) and confirmationToken (absent → returns price/warning/token; present → starts), which the schema alone doesn't convey as a workflow.

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+resource+scope ("Moves a server to ANOTHER GPU model in stock") and immediately clarifies the mechanism — a new server is created from the system disk while the original is untouched. This distinguishes it cleanly from gpucloud_create_server and gpucloud_restore_server among the many siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lays out the when-to-use via prerequisites (backup option on, canLaunch, saved card, credits for one hour, budget/key caps) and the three-step call flow with each parameter combination. It also names follow-up tools (gpucloud_list_servers, gpucloud_get_server) so the agent knows the sequence.

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=true and destructiveHint=false, so the safety profile is covered; the description adds meaningful extras: taxes are included, the price matches what will actually be charged, a confirmationToken is returned, and the required orders:quote permission. No contradiction with the read-only annotation.

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 front-loaded sentence states purpose, output, and the downstream call, followed by two compact parentheticals for permission and prerequisites. Nothing 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, and the description partially compensates by naming confirmationToken and stating that prices include taxes. It omits the shape of the price breakdown and any pagination/expiry detail for the token, but overall an agent has enough 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 67% and the description contributes no parameter-level detail (items, country, province are never mentioned). The schema carries the weight via enum/default descriptions, so 3 is the appropriate 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 (prices/quotes a cart) with the exact output named (confirmationToken). It explicitly distinguishes itself from the sibling gpucloud_create_order by explaining the token hand-off, so an agent can route between quote and order 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?

Implies the workflow clearly: quote first, then feed the token to gpucloud_create_order with the same items. It also states a prerequisite (free GPU Cloud account + MCP key). It stops short of an explicit when-not or a pointer to the related gpucloud_quote_server sibling for single-server quotes.

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 establish it is a safe read (readOnlyHint=true, destructiveHint=false), and the description goes well beyond them: it enumerates what the quote returns (price charged now with taxes for monthly/annual, hourly rate, credits required, card charge needed, blockers, confirmationToken) and discloses the single-use token dependency that gates the follow-up create call. That is real behavioral context an agent cannot get from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and the call-then-create workflow are front-loaded, and the dense field listing is largely justified by the absence of an output schema. It is slightly overstuffed with return-field names in one long sentence, which costs a point but not a major one.

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 full burden of describing what comes back, and it does so thoroughly: charge-now amount, hourly rate, credits, card charge, blockers, and the hourly-specific hibernation threshold and AUTO_RELOAD_OFF warning. An agent has everything it needs to present a quote and proceed to creation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all eight parameters, including the cycle semantics and onFundsExhausted behavior. The description mirrors the hourly return fields but adds no new syntax, format, or constraint information about the inputs themselves, so the baseline 3 applies.

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 — 'Price of a new GPU server BEFORE launching it' — and immediately anchors the result to a concrete action (call gpucloud_create_server with the same arguments and token). This separates it from the sibling create tool and from the launching path without needing either schema opened.

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 workflow: show the price and warning to the user, get approval, then call gpucloud_create_server with the SAME arguments and the confirmationToken. It also names the prerequisites (free GPU Cloud account and MCP key) and the permission scope (servers:quote).

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=false, idempotent=false, destructive=false, openWorld=true, so the safety profile is covered. The description adds genuinely new context: the required permission scope (servers:reboot), the account/MCP-key prerequisite, and the 'hard' qualifier distinguishing it from a graceful reboot. It stops short of stating downtime or impact on running workloads.

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, action front-loaded, with permission and auth requirements tucked into parenthetical/bracket clauses. No wasted words, though the bracketed account note reads as boilerplate rather than tool-specific 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?

For a single-parameter mutation tool with annotations covering the safety profile, the description covers purpose, required permission, and account requirements. It omits any indication of what happens on success (no output schema exists) and whether reboot causes transient unavailability, leaving an agent with a bare minimum picture.

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 is a single parameter with 100% schema description coverage, and the schema already documents serverId including its source (gpucloud_list_servers). The description adds no parameter-level detail, so the baseline of 3 applies.

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 scope: 'Hard-reboots a running server'. The verb 'hard-reboot' is unique among siblings (start_server, stop_server, hibernate_server, restore_server), so an agent can route to it without confusion. It does not, however, explicitly contrast itself with those siblings, keeping it just short of a 5.

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 'a running server' implies a precondition (the server must be running), which is implicit usage guidance. There is no explicit when-to-use statement, no naming of alternatives (e.g., stop+start vs reboot), and no exclusion for stopped/hibernated servers.

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 substantial context beyond the annotations: it explicitly flags that it spends money, charges the saved card within the caps, requires the servers:renew permission plus an account/MCP key, and notes that a server stopped at period end is restarted. Annotations only give generic mutation/idempotency hints, so this descriptive detail is genuinely additive.

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?

Dense but front-loaded, with the action, cost implication, and step sequence stated up front and bracketed markers for money/permission/account requirements. Packed tightly, though the trailing bracketed metadata is a little cluttered.

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 compensates by describing what the first call returns (price and token) and what the second call does (pays and extends the paid-until date). It covers cost, auth, permissions, and side effects, leaving nothing critical unstated for a mutating payment 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?

Schema coverage is 100% so the baseline is 3, but the description adds workflow meaning by tying confirmationToken to the quote-then-pay sequence and clarifying what the token-less call returns, which is more than the schema's field-level text alone conveys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with scope: renew a monthly/annual server for one more month, charged to the saved card. An agent can immediately distinguish this from create_server, reserve_server, or quote_server 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?

Explains the two-step flow clearly: call without confirmationToken to get price and a token, then call with it to pay and extend. This tells the agent exactly how to sequence the operation, though it never names the sibling quote tool explicitly or states when-not to use it.

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 (readOnlyHint=false, destructiveHint=false, idempotentHint=false) by disclosing the required permission support:write, an account/MCP-key prerequisite, accepted image formats, a 5-image cap, a ~1 MB / ~700 KB request budget, the allowance of empty text when an image is attached, and what is returned. This is unusually rich 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?

A single dense paragraph that front-loads the core action and constraints with no filler sentences. It is packed tightly, but every clause (formats, limits, return, permission) carries useful information, so little 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?

For a 3-param, no-output-schema mutation tool, the description supplies the missing param constraints, embeds the necessary permission/auth context, and explicitly states the return values (new message id and updated ticket). Nothing an agent needs to invoke it correctly is absent.

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 0% schema description coverage the description must carry the param burden, and it does so for images (formats, base64 encoding, count, size) and content (may be empty with an image). ticketId is only implied by 'existing support ticket' — no format or lookup guidance — so it slightly under-specifies one of three parameters.

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: 'Add a message to an existing support ticket of the account.' The word 'existing' cleanly disambiguates it from the sibling gpucloud_create_ticket, so an agent can route 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?

The 'existing support ticket' scope implies this is the tool for replying rather than opening a ticket, and the account/permission requirement sets a precondition. It stops short of naming create_ticket or list_tickets as explicit alternatives, leaving the when-not case 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?

Goes well beyond the annotations: discloses the 402 PAYMENT_REQUIRED path with card link, that an AI must never enter card details, consent requirement and wording, that nothing is charged at reservation time, the partial-charge behavior at launch, the onFundsExhausted / autoReloadWarning return fields, and flags [SPENDS MONEY] with the required permission. Annotation-consistent (readOnlyHint=false) and richly behavioral.

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 core differentiator (out-of-stock reservation with automatic launch) and keeps everything in two dense paragraphs. The many parentheticals and trailing disclosure clauses make it heavy, but each sentence carries operational information rather than 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 compensates by describing the returned fields (onFundsExhausted, autoReloadWarning) and the full billing/consent flow. Prerequisites, spend implication and permission are all present, leaving nothing needed for 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?

Schema description coverage is 100%, so all ten parameters are already documented in the schema, including consent wording, maxHourlyCad bounds and onFundsExhausted semantics. The description mostly echoes those constraints (consent, max hourly price) rather than adding new per-parameter meaning, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (reserves) on a specific resource (a GPU machine that is out of stock) and describes the distinctive automatic-launch behavior. An agent can separate this from gpucloud_create_server (immediate launch) or gpucloud_list_reservations 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 clear context for when this applies (machine out of stock, launch on restock, first-come-first-served) and lists prerequisites: saved credit card, explicit consent, maximum hourly price. It does not explicitly name the sibling alternatives such as gpucloud_create_server for an in-stock machine, so it falls short of the top band.

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 substantial context beyond the annotations: hourly billing resumes (matching readOnlyHint=false), the operation takes minutes and depends on GPU availability, a NEW public IP is assigned requiring polling, and it requires the servers:start permission plus a free account/MCP key. This is exactly the operational detail an agent needs before spending money.

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 core action and billing impact, then the IP caveat, then bracketed permission/account signals. Dense but every clause carries operational weight; the parenthetical nesting is slightly heavy but not wasteful.

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 return-value burden and does so: it tells the agent to poll get_server until publicIpv4 is populated and describes the wait via publicIpStatus/publicIpNote. Billing, duration, IP change, and auth requirements are all covered for a one-parameter mutation.

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 100% and the single serverId parameter is fully documented in the schema (including its source, gpucloud_list_servers), so the description adds no parameter-level information. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (restores) and a precise resource state (a hibernated server), which cleanly distinguishes it from gpucloud_start_server and gpucloud_restore_server_backup without opening either schema. The parenthetical billing note reinforces that this is the hibernation-wake path.

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?

Makes the trigger condition clear (only for a hibernated server) and prescribes the follow-up workflow: poll gpucloud_get_server until publicIpv4 is set, and never reuse the old address. It stops short of explicitly naming start_server as the alternative for non-hibernated servers, so routing is implied 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?

Annotations only flag readOnlyHint=false and destructiveHint=false; the description goes well beyond them by disclosing the billing model (first hour from credits, then hourly), the exact prerequisites, the permission scope (servers:create), the account/MCP-key requirement, and the single-use 10-minute token flow. This is the full behavioral picture an agent needs before spending money.

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 create action and the non-destructive guarantee, then prerequisites and the two-step flow. Dense but every clause earns its place; the only waste is '[SPENDS MONEY]', which duplicates the title's '(spends money)' warning.

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 correctly states what each step returns (price and token, then launch) and points to gpucloud_get_server for follow-up status. Prerequisites, cost, permissions, and the confirmation workflow are all covered, leaving no gap for a costly mutation 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics the schema cannot express: the meaning of calling with versus without confirmationToken (price quote + token vs. actual launch). It does not explain the optional 'name' parameter, but the token flow is the semantically important part.

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 precise verb and resource ('Creates a NEW server ... from an AVAILABLE backup') and immediately scopes it with 'the original server is not changed', which cleanly separates it from gpucloud_restore_server (in-place) and gpucloud_create_server (from scratch). The GPU-model/region inheritance is spelled out, so no schema inspection is needed to understand what gets created.

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 preconditions (canLaunch, saved card, one hour of credits, budget and key caps) and the two-step call sequence, plus polling via gpucloud_get_server. The contrast with gpucloud_restore_server is implied by 'the original server is not changed' rather than named, so the agent must infer which sibling to pick for an in-place restore.

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 annotations, it discloses critical behavior: the tool spends money, requires canCharge, uses a single-use confirmation token, and has different immediate behavior for turning off. It also explains charge-cap and budget interactions, which are important for a financial mutation 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?

The purpose is front-loaded and the dense detail is mostly necessary for a complex financial tool. However, the long run-on sentences and heavy parentheticals make it less scannable than it could be.

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 complex money-moving operation with no output schema, the description provides enough context to call it correctly: permissions, account requirements, two-step confirmation, parameter ranges, monthly cap behavior, and off-state behavior are all covered.

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 only 20%, so the description must carry parameter meaning, and it does: it covers enabled, threshold, reload amount, monthlyCapCad null/absent semantics, and confirmationToken usage. Some wording is dense, but all five parameters receive meaningful explanation 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?

The description opens with a specific verb and resource: it turns automatic credit reload on/off. It clearly distinguishes this mutation tool from the read-only sibling gpucloud_get_auto_reload by describing configuration changes and two-step confirmation.

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 explains the operational flow: turning on or changing while on requires a confirmation token and a second call, while turning off applies immediately. It references gpucloud_get_auto_reload for reading the saved amount, but does not explicitly frame all read/update alternatives.

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 (readOnlyHint=false, destructiveHint=false, idempotentHint=true): it discloses the asymmetric approval requirement for raises vs. lowers, the retry protocol, the required permission scope (billing:budget), the account prerequisite, and the non-obvious side effect that raising a limit does not un-hibernate servers.

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 core behavior, then the approval nuance, then the caveat and permissions. No filler or 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 mutation tool with no output schema, the description covers the mutation semantics, the two-phase approval flow, the return-and-retry contract, and prerequisites — enough for an agent to invoke it correctly without extra inference.

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 100%, so the baseline is 3, but the description adds value beyond the schema by explaining the confirmationToken's role in the two-call flow (retry with the same arguments) rather than just restating its format limits.

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 ('Sets the monthly budget limit of the account'), immediately distinguishable from the sibling gpucloud_get_budget which only reads it. The scope (monthly limit, daily limit, alert threshold) is clear from the first sentence.

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 describes the when-and-how: lowering applies at once, raising/removing requires the confirmationToken round-trip with the same arguments after user approval. It does not name gpucloud_get_budget as the read alternative, which keeps it short of 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?

Goes beyond the annotations (which only say idempotent, non-destructive, non-read-only) by disclosing the notice frequency caps (once an hour for payment/balance, at most every 2 hours for GPU offers), the key-scoped blast radius, and the required permission account:notices.

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 effect of the tool and packs rates, scope, and permissions into three sentences with no filler. Parenthetical asides make it dense but each clause carries information 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?

Covers the prerequisites (free GPU Cloud account + MCP key), permission, scope limitation, and parameter effect. With no output schema and a single boolean input, nothing essential is missing, though the return value 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?

Schema description coverage is 0%, so the description must carry the semantics — and it does, explicitly defining enabled:false as off and enabled:true as on. It compensates for the schema gap, though it cannot say more about a single boolean.

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: turn GPU Cloud notices on or off via a single boolean. It also scopes the change precisely ('for THIS MCP key only. Changes nothing else'), which no sibling tool does, so an agent can distinguish it immediately.

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?

Explains the context in which notices appear (payment card, low balance, GPU availability) and maps enabled:false/true to off/on, giving clear usage context. It stops short of naming when-not-to-use or an alternative, since no alternative exists.

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 far beyond the annotations: discloses the 14.99 $/month cost with pro-rata vs prepaid billing mechanics, that disabling permanently deletes backups with no refund, that canDelete permission is required when backups exist, and that the confirmation token expires in 10 minutes and is single-use. It also names the required permission scope (servers:backup).

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 core action and cost signal, and every clause carries real information. It is dense to the point of being run-on with nested parentheses, which slightly hampers scanning, but nothing 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?

For a destructive, money-spending mutation with no output schema, all decision-critical facts are present: cost model, deletion/no-refund warning, permission requirements, two-step token mechanics, and valid parameter ranges. Nothing an agent needs 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?

Schema coverage is only 40%, but the description compensates fully: hourLocal is 0-23 in Eastern time, retention is 1-7 daily backups, enabled is the on/off switch, and confirmationToken is the two-step token. This adds meaning well beyond the bare schema types.

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 (turns on/off, changes hour/retention) applied to a specific resource (a server's backup option), with concrete value ranges inline. It is clearly distinguishable from gpucloud_create_server_backup and gpucloud_restore_server_backup because it modifies the policy rather than creating or restoring a backup.

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 states the two modes of use: on/off requires a two-step confirmationToken flow, while hour/retention changes apply directly. It also explains the downstream consequence that enabling backups enables migration to another GPU via gpucloud_migrate_server, giving the agent a reason to choose one path over another.

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 (readOnlyHint=false, idempotentHint=true, openWorldHint=true, destructiveHint=false), and the description still adds substantial context: 'Spends nothing', the required permission (servers:update), the free-account requirement, the full consequence chain of HIBERNATE (12h window, hibernation fee, restart-then-delete) and DELETE (immediate, no fee, data lost). Notably it discloses the data-loss outcome even though destructiveHint=false, which is useful downstream context rather than a contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The consequence semantics are front-loaded in a single dense sentence, and the trailing operational notes (cost, permission, account) are short. The HIBERNATE clause's nested parenthetical is heavy, but the overall length is proportionate to the behavioral detail being conveyed.

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, no-output-schema policy tool with full annotation coverage, the description supplies the trigger condition, per-enum consequences, hardware restriction, cost, and auth requirements. Nothing an agent needs to invoke this 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?

Schema coverage is 100%, so the baseline is 3, but the description goes further by defining what each enum value actually does to the server (retention window, fees, restart behavior, data loss), which the schema's bare 'HIBERNATE or DELETE' enum description does not convey. serverId is left to the schema, which is acceptable given the parenthetical reference to gpucloud_list_servers.

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 ('What happens to an hourly server when the account balance reaches its threshold') and scopes it to hourly servers, clearly distinguishing it from siblings like gpucloud_hibernate_server, gpucloud_set_auto_reload, and gpucloud_set_budget. An agent can identify exactly what policy this tool configures 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?

It states the triggering context (balance reaches threshold and no automatic reload restores it) and a validity constraint (spot machines only accept DELETE). It does not explicitly name the sibling tools an agent should use for related balance/reload settings, so the alternative-selection guidance is implied rather than spelled out.

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 only say readOnly=false, destructive=false, idempotent=false, openWorld=true; the description adds the material behavior an agent actually needs: this spends money, the billing mechanics of the next hour, the card/credits requirement, the required 'servers:start' permission, and the account/MCP-key prerequisite. That is real cost and authorization context beyond structured fields, and it is consistent with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The action and its scope are front-loaded, and the bracketed [SPENDS MONEY] / permission / prerequisite tags are scannable. The billing sentence is dense and heavily parenthesized, which costs a little readability, but every clause carries 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 costly mutation with no output schema, the description covers cost, payment source, permission, and prerequisites — the essentials. It stops short of saying what happens after a successful start (state transition, whether boot completes asynchronously), which would have made it fully complete.

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 is one parameter with 100% schema coverage, and the schema already explains that serverId comes from gpucloud_list_servers. The description adds no further semantics about the id or its format, so the schema is doing all the work — baseline 3.

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 ('Starts a stopped server') and immediately scopes it: only stopped servers, not hibernated ones. It explicitly routes the hibernated case to gpucloud_restore_server, so the agent can distinguish it from sibling power tools (stop, reboot, restore, renew) 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?

Gives the when ('stopped server'), the when-not plus the exact alternative ('For a hibernated server use gpucloud_restore_server'), and the preconditions for the spend (credits covering the hour, or a saved card with ≥$25 available within caps). Nothing about selecting this tool over its siblings is left 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?

The annotations only cover safety profile (destructiveHint=false, idempotentHint=true), but the description adds the critical non-obvious behavior that a stopped server is still billed at full hourly rate because the GPU stays reserved. It also discloses the required permission scope (servers:stop) and account prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the action and its state effect, then the cost warning, then the alternatives, then permissions. Every clause carries distinct information 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?

For a single-parameter mutation tool with no output schema, the description covers effect on data, billing consequences, alternatives, permission scope, and account requirements. Nothing material is left for the agent to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single serverId parameter is already documented with its source (gpucloud_list_servers). The description adds no additional syntax, format, or constraint detail beyond the schema, so the baseline 3 applies.

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 ('Stops (shuts down) a server') and immediately clarifies the effect on state ('Disk and data are kept'), which separates it from delete and hibernate. An agent can identify the operation 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?

Explicitly names both alternatives and the conditions selecting them: use gpucloud_hibernate_server to pay much less, delete the server to stop paying entirely. This is textbook when/when-not/alternative routing.

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 the saved card is charged, that the owner is emailed, that it costs money ('[SPENDS MONEY]'), the required permission scope (billing:charge), and hard prerequisites (account + MCP key). Annotations cover only readOnly/idempotent/openWorld, so this added operational context is genuinely valuable.

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 core action and the two-step flow, then bracket-tagged facts (spends money, permission, prerequisites). Efficient overall, though the trailing '[Requires a free GPU Cloud account and MCP key]' reads as standing boilerplate rather than task-specific 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?

For a money-spending, non-idempotent mutation with no output schema, the description covers the full picture: two-step confirmation, what each step returns (amount + token), the side effects (card charged, owner emailed), caps, and auth prerequisites. Nothing an agent needs to invoke this safely is absent.

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 50%: confirmationToken is documented in the schema (validity window, single use), while amountCad has only constraint bounds (25–10000) and no prose. The description explains the token workflow and the key caps, but adds no currency or amount-capping semantics beyond what the schema and caps note imply, so it lands 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?

States a specific verb+resource ('Buys credits') with the funding source ('with the saved card') and a scope qualifier ('within the key caps'). It is clearly distinguishable from siblings like create_order, add_payment_method, or set_auto_reload, and the title reinforces the money-spending nature.

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 two-step protocol is spelled out — call without confirmationToken to get the amount and token, call with it to charge — which tells the agent exactly how to sequence invocations. It does not, however, contrast itself against adjacent siblings such as set_auto_reload/get_budget or add_payment_method, so the alternative-routing guidance is implied rather than explicit.

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