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

Discloses side effect (sends one email) and states it does not charge. However, lacks details on error handling, rate limits, or behavior on invalid email, though schema provides pattern validation.

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

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

Two sentences plus a note, all front-loaded with essential information. No wasted words, each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given single parameter, no output schema, and simple action, the description covers purpose, side effect, optionality, and next steps. No missing information needed for agent decision.

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 covers the parameter fully with format and pattern, achieving 100% coverage. Description adds context that the email receives a code, enhancing understanding beyond 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?

Clearly states the verb 'claim' and resource 'AgentMetal account', and describes the action: sends a one-time code to email. Distinguishes from sibling tool 'verify_claim' by specifying it as the next step.

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

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

Explicitly notes accounts are optional and explains when to use: for fleet management, billing, quotas. Also instructs to call 'verify_claim' next, providing clear step-by-step guidance.

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

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

Discloses irreversibility, no lease refund, auth error without key, and that it destroys before lease expires. No annotations provided, so description carries full burden and does so thoroughly.

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

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

Three sentences, each serving a purpose: stating the action, warning about consequences, and giving usage guidance. Could be slightly more concise but is well-structured and 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?

Covers auth, irreversibility, refund policy, and use cases. No output schema exists, but description is sufficient for this simple delete action. Lacks mention of error responses or idempotency, but not critical.

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 already describes the parameter and its irreversibility. The description adds a concrete example ('srv_abc123') and reiterates the consequence, providing slight extra clarity 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 uses the verb 'destroy' and specifies the resource 'server' with emphasis on permanence. It distinguishes from sibling tools like 'extend_server' by contrasting with natural expiration.

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 the tool (free quota, unneeded box) and provides an alternative: 'To let a box expire naturally instead, simply do not extend it.' Also notes auth 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?

With no annotations, the description fully discloses behavior: runs as root, non-interactive, no TTY, returns exit code/stdout/stderr, timeout with timed_out flag, 256KB output cap, and error for missing managed_key. This meets the transparency requirement comprehensively.

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 a single, well-structured paragraph that front-loads the core purpose. Each sentence adds value (prerequisites, constraints, use case). It is concise but thorough, though slightly long due to multiple constraints; a 4 reflects this minor trade-off.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains all return elements (exit code, stdout, stderr, timed_out) and covers edge cases (no_managed_key, timeout, output cap). It is complete for a command execution tool, and sibling tools complement it without overlap.

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 baseline is 3. The description adds minor context beyond the schema (e.g., 'Must be a running, managed-key server you own' for id, and restates non-interactive for command). It does not introduce new parameter information, so score remains 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?

The description clearly states 'Run a single shell command as ROOT on a server over SSH and get back its exit code, stdout, and stderr.' It precisely conveys the action, resource, and expected outcome, and it is distinct from all sibling tools which deal with server lifecycle management, not command execution.

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 explicitly lists prerequisites: API key, ownership, and server with managed_key:true. It warns about non-interactive shell and suggests chaining commands with && or ;. It also specifies a use case: 'Use to install packages, run scripts, or inspect a box you own without opening your own SSH session.' This provides clear when-to-use 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?

Warns about real money spend 'SPENDS REAL USDC — signed on-chain via x402' and describes effects and return value, fully compensating for absent 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?

Two sentences, front-loaded with main action, then financial warning and guidance. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers action, side effects, return value, prerequisite, and financial impact. Complete given no output schema and sibling context.

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 covers both parameters with descriptions. Description adds the effect ('Adds days...') and return value context, going beyond 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?

Clearly states 'Extend an existing server's lease' with specific verb and resource. Distinguishes from siblings like destroy_server, provision_server, etc.

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 advises to 'Use before a lease runs out to keep a box alive; check the current expiry first with get_server,' providing clear when-to and prerequisite.

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?

Clearly declares it is free, read-only, and requires no wallet/account. With no annotations provided, the description adequately covers behavioral traits.

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

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

Two sentences, no redundancy, front-loaded with purpose. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Describes all output categories and usage order. Without output schema, this is sufficient for an agent to understand the tool's purpose and 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?

No parameters exist, so baseline 4 applies. Description adds value by listing what the output includes (plans, regions, pricing).

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

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

Description explicitly states it lists server plans, regions, and add-on pricing. It distinguishes itself from siblings like get_server and list_servers by being a pre-provisioning discovery 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?

States to call this first before provisioning, making its usage context clear. Does not explicitly mention when not to use it, but its read-only nature implies it's always safe.

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?

With no annotations, the description fully discloses behavioral traits: it is read-only, never charges money or changes the server, and lists possible statuses. This goes beyond what the input schema provides.

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

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

Three sentences, each serving a purpose: what it does, safety assurance, and when to use. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (one param, no output schema), the description covers all needed context: return fields, usage scenarios, and safety profile. Sibling tools provide clear contrast.

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% for the single parameter, and the description adds context about the parameter's source and format ('Server id returned by provision_server, e.g. srv_abc123'), enriching the schema's description.

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 states the tool's function (look up live status), lists specific fields returned, and distinguishes it from sibling tools like destroy_server or list_servers by emphasizing read-only 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 description provides explicit usage scenarios ('confirm a box is up and reachable, or to see how long it has before auto-destroy'), but does not explicitly mention when not to use it or name 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?

With no annotations provided, the description carries full behavioral burden. It explicitly states 'Read-only — never charges or changes anything,' which is critical. It also discloses the default wallet behavior. It does not mention rate limits or pagination, but for a simple list operation, the transparency is sufficient.

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: first states purpose, second declares read-only and default, third gives usage example. No wasted words. Front-loaded with key 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?

Given no output schema, the description could explain return format, but 'list every server' implies an array. The description covers core use, wallet scope, and safety. It is complete enough for a list tool with clear sibling context.

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% (1 parameter fully described). The description adds 'pass `wallet` to list a different payer' which essentially restates the schema. Baseline is 3; no significant extra meaning added beyond the schema's own description.

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 states the tool lists servers for a payer wallet or whole account. It uses specific verb+resource ('List every server') and implicitly distinguishes from sibling 'get_server' (singular) and 'provision_server'. Additionally, it mentions enumeration for use before 'extend_server' or 'destroy_server', reinforcing its distinct role.

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

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

The description provides usage context: 'use to enumerate active boxes before calling extend_server or destroy_server.' It also notes default wallet behavior and optional parameter. However, it lacks explicit when-not-to-use guidance or comparison to alternatives like 'get_server', though sibling list helps.

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?

No annotations are provided, so the description carries the full transparency burden. It discloses key behaviors: real payment via on-chain x402, return values (server id, IP, ssh target), typical reachability within 60 seconds, auto-destroy after lease, and consequences of omitting ssh_key. It does not cover error cases or rate limits.

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

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

The description is somewhat long but tightly packed with useful information. It front-loads the critical warning about spending real USDC and then details parameters and return values. Every sentence earns its place, though minor trimming could be possible.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of provisioning (5 parameters, no output schema), the description covers core aspects: payment, return values, lease duration, SSH options, and mentions auto-destruction and extension via sibling. It lacks error handling details but is sufficient for an AI agent to use the tool correctly.

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

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

Schema coverage is 100% as all parameters have descriptions. The description adds value beyond schema: it explains that omitting ssh_key blocks SSH access, managed_key enables exec_command, and via is analytics-only. It also recommends choosing the smallest plan that fits the workload.

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 states it provisions a Linux VPS and pays for it in a single call. It uses specific verbs ('provision', 'pay') and resource ('server'), and distinguishes from sibling tools like list_servers and destroy_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?

The description explicitly says when to use: 'when an agent needs its own compute to build, run, or host something with no human signup.' It provides guidance on passing or omitting ssh_key but does not explicitly list alternatives or when not to use another 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?

No annotations, so description covers all: non-destructive, no charge, immediate return with status, quick recovery, auth error. Full behavioral disclosure.

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

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

Two sentences, front-loaded with action and key constraints. Every sentence adds value without redundancy.

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?

Single parameter, no output schema. Description covers purpose, usage, behavior, prerequisites, and result fully. No gaps given simplicity.

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 100% with clear 'id' description. Description adds no extra parameter info beyond schema, meeting baseline expectation.

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?

Clearly states it soft-reboots a server gracefully without data loss, distinguishing from sibling destroy_server. Verb 'reboot' and resource 'server' are specific.

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

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

Explicitly says use for unresponsive box or applying changes needing restart. Mentions prerequisites (API key, ownership) and auth error. Lacks explicit alternatives, but context from siblings suffices.

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?

No annotations provided, so description fully covers requirements (API key, ownership), confirms no charge, explains limitation of no text serial console, and clarifies what is returned versus what is not.

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?

Description is somewhat long but all information is relevant and front-loaded. No redundant sentences.

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 tool with no output schema, description fully explains return values (status, actions, console, metrics). Parameter is well described. Complete for the complexity.

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 'id' with schema description; description adds example format and clarifies it's the server to diagnose. Schema coverage is 100%, baseline 3, and description adds value.

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?

Clearly states it's for hypervisor-level diagnostics without logging in, and lists specific outputs (status, actions, console, metrics). Differentiates from siblings like get_server and exec_command.

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

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

Explicitly says use to diagnose stuck/unreachable boxes. Could be improved by contrasting with get_server or exec_command, but context is clear.

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?

Despite no annotations, the description fully discloses behaviors: returns a long-lived API key that authorizes other tools, optionally links a wallet to attach servers, and details expiry and invalidation rules. No annotation 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?

Three sentences with no redundancy. Front-loaded with main purpose, then key security note about API key, then wallet option, then retry logic. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema or annotations, the description covers all needed information: inputs, output (API key), side effects, error conditions, and relationship to sibling tools. Completely adequate for an AI agent to use 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%, but the description adds context beyond the schema: emphasizes that email must match claim_account, code is 6-digit, and wallet is optional with specific effect (attaching servers). This enriches parameter understanding.

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 states it completes an account claim with a 6-digit code, and references the related 'claim_account' tool. It distinguishes by explaining the output (API key) and optional wallet linking, making its 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?

Provides explicit context on when to use (after claim_account), with critical usage constraints: code expires in 10 minutes, invalidated after 5 wrong attempts, and instruction to re-run claim_account to retry. This guides appropriate invocation and failure handling.

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