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

Even though destructiveHint is already true, the description adds materially new and non-obvious behaviors: it downloads weights, registers the instance for automatic teardown, and guarantees a hard deadline. It also discloses the confirmation gate and cost-estimate requirement. There is no contradiction 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?

Three sentences, front-loaded with the core side effectsches. Each sentence carries distinct information: the operation, the confirmation requirement, the deadline guarantee, and the return envelope. No filler or repetition.

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

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

For a 12-parameter, destructive, paid operation, the description packs the critical lifecycle facts and the return format. The schema covers many parameter details and the output schema handles return values. It would be slightly more complete if it explicitly routed the agent to the cost-estimate prerequisite, but it is already sufficient 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?

The description only reinforces confirm=true, which the schema already documents with 'Must be true.' It adds no explanation for force, template, disk_gb, work_minutes, or allow_unverified. With schema description coverage at 58%, the description neither harms parameter understanding nor compensates for the undocumented parameters beyond what the schema provides.

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 concrete action chain—rent, start container, download weights, register for teardown—and matches the title's 'Rent the GPU and start the workload.' This clearly distinguishes it from sibling monitor/destroy tools like get_instance or destroy_instance.

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

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

It clearly states a mandatory precondition: the user must see a cost estimate and confirm=true is required. It also gives a when-not signal: no instance can be created that runs forever, so this tool is unsuitable for unbounded sessions. It does not explicitly name estimate_deployment or recommend_plan as the chained prerequisite tools, so it stops 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 indicate destructive and open-world behavior, but the description adds valuable context: the confirm=true requirement, the postcondition of nothing remaining billable, and the JSON response shape including next_tool and next_args. No contradiction with 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 concise sentences cover the action, the prerequisite, and the return format with no filler. The most important information is front-loaded.

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

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

For a one-parameter destructive tool with an output schema and annotations covering safety, the description is complete. It explains the scope, the guardrail, and the response envelope, leaving no critical gap for an agent 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 100%, with confirm already described as 'Must be true.' The description repeats this requirement but does not add new parameter semantics beyond what the schema already provides.

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

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

The description uses a specific verb, 'Destroys every instance on the account,' which clearly defines the tool's scope and distinguishes it from the sibling destroy_instance. It also states the intended result: confirming nothing is left billing.

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 usage for a full account-wide teardown, especially with the title 'Panic button,' but it does not explicitly say when to use this tool instead of destroy_instance or list_instances. There is no direct mention of alternatives or exclusions.

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

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

Annotations already mark the tool as destructive, and the description adds meaningful behavior beyond that: it stops billing, deletes the disk, verifies deletion, and returns a structured result. There is no contradiction 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 description is compact and front-loaded: action, consequences, and return format. The return JSON sentence is somewhat redundant with the output schema, but it is still brief and adds the useful next_tool field.

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?

Core destructive context is covered well, including billing, disk deletion, prerequisite downloads, and verification. However, it omits any explanation of the required instance_id parameter and does not situate this tool against destroy_all or extend_teardown.

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 carries full responsibility for explaining parameters, but it never mentions instance_id or reason. An agent cannot tell what each parameter means or how required instance_id should be selected.

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 specific action: destroying an instance immediately, stopping billing, and verifying deletion. The singular 'the instance' helps differentiate from the sibling destroy_all, even though that alternative is not named.

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 tool is for immediate destruction and includes a key prerequisite: 'make sure the renders have been downloaded first.' However, it gives no explicit when-not-to-use guidance and does not mention alternatives such as extend_teardown or destroy_all.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds useful behavioral context: it performs multiple verification checks and returns a JSON envelope including next_tool and next_args, which signals orchestration behavior beyond a simple read. No contradiction with 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 cover purpose, when to use, and return shape with zero filler. The diagnostic scope is front-loaded first, followed by usage guidance and output format.

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 diagnostic tool with a read-only annotation and an output schema, the description is complete: it states what is verified, when to call it, and the return envelope including next_tool/next_args. Nothing essential is missing.

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

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

The tool has zero parameters and schema description coverage is 100%, so the schema fully documents the input surface. The description does not need to explain parameters; it adds no parameter details, but none are required.

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

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

The description uses a specific verb ('Verifies') and names the exact resources checked: API key, account balance, Vast API reachability, and the auto-teardown reaper. It clearly identifies this as a diagnostic health-check tool, distinct from siblings like get_balance or list_instances.

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?

'Call this first when anything misbehaves' gives an explicit, actionable trigger for use. It does not explicitly list when not to use it or name alternatives, but the instruction to call it first provides clear routing for troubleshooting situations.

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 readOnlyHint and destructiveHint annotations, the description explicitly states 'Spends nothing,' explains that it exactly mirrors create_instance, and describes the JSON return shape including next_tool and next_args. This gives the agent a concrete model of the tool's side-effect-free 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 description is two sentences with no filler. It front-loads the core behavior, then gives the key cost safety detail, then summarizes the return contract.

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

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

The description covers the essential behavior, return shape, and safety profile, especially with strong annotations and an output schema present. The remaining gap is parameter semantics, but the analogy to create_instance plus the existing schema makes the tool reasonably actionable.

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 20%, and the description does not compensate by explaining template, idle_minutes, work_minutes, or teardown_minutes. It only says 'with these arguments,' which links parameters to create_instance but leaves their individual meaning and requirements under-specified.

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 tool as a dry-run that replicates create_instance behavior, including teardown deadline and worst-case bill. It distinguishes itself from create_instance by stressing that it spends nothing, so an agent immediately knows what this tool is for.

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 references create_instance as the real operation being previewed and emphasizes 'Spends nothing,' which clearly implies using this before committing to create_instance. It does not explicitly list when not to use it or alternative conditions, but the context is clear enough.

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 signal mutability (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds meaningful context: it only extends a hard deadline, never removes it, and returns a JSON structure with next_tool and next_args for chaining—valuable behavior not in 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 pack the core action, usage trigger, a key behavioral constraint, and return format. Everything earns its place, and the primary action 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?

An output schema exists, so return format details are handled. However, the optional idle_minutes parameter is entirely unexplained, and there is no mention of side effects beyond extending the deadline. Adequate for basic use but leaves gaps for an agent that needs to understand all 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% (only additional_minutes has a description). The description reinforces what additional_minutes does but adds no meaning for instance_id or the optional idle_minutes, leaving a significant coverage gap for a low-coverage 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 action (moves), the exact target (hard teardown deadline), and a defining constraint (never removes the deadline entirely). This clearly differentiates it from destructive sibling tools like destroy_instance and destroy_all.

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 when a render needs longer than planned', giving a clear trigger condition. It does not name alternative tools or provide when-not guidance, but the constraint 'never removes the deadline entirely' implies it is not for canceling teardown.

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. The description adds the return envelope structure ({ok, message, next_tool, next_args, ...}) and the conversion behavior, which goes beyond the annotations. It does not over-explain or contradict them.

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

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

Two tight sentences: the first lists what the tool reports, the second shows the return format. No filler, and the most important information is front-loaded.

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

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

For a read-only, zero-required-parameter balance lookup with a documented optional parameter and an explicit return structure, nothing an agent needs to invoke it correctly is missing. The output schema and annotations cover the rest.

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%: usd_per_hour is fully documented with type, description, and default. The description adds a light reference to 'a given rate' but does not need to elaborate further since the schema carries the 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?

The description clearly enumerates the resource (prepaid credit, cash balance, lifetime spend) and the derived output (GPU-hours at a rate). It is immediately distinguishable from sibling tools like list_instances or get_instance, which concern instances rather than account financials.

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 conveys the natural use case - checking balance and converting it to GPU-hours - but does not explicitly state when to use it versus alternatives, nor does it mention any exclusions. 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 mark this as read-only and non-destructive. The description adds useful behavioral context beyond those hints: the instance will be destroyed, so renders must be retrieved beforehand, and the response follows a specific JSON envelope with ok/message/next_tool/next_args. No contradiction with 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 dense sentences with no filler; the core usage facts are front-loaded and the return format is summarized compactly. The first sentence is slightly list-like but still efficient and easy to scan.

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 output schema exists and annotations cover safety, so the return envelope need not be fully explained. However, the tool has two required parameters with zero schema documentation and zero description coverage, and there is no guidance on which instance/template values to provide. For a tool that is essentially an instruction guide, this is a significant completeness 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%, and the description does not mention instance_id or template at all. An agent cannot determine what values these parameters should take or how they affect the returned endpoint usage. The description completely fails to compensate for the undocumented 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 clearly enumerates what the tool provides: ComfyUI URL, SSH command, workflow POST instructions, and render retrieval. This makes the purpose concrete and understandable. It does not explicitly distinguish itself from sibling tools like get_instance or get_logs, which prevents 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?

Usage context is implied rather than stated: the service is 'running' and renders should be pulled 'before it is destroyed,' suggesting it is meant for an active instance near teardown. However, there is no explicit when-to-use statement, no exclusions, and no mention of alternatives among the many sibling tools.

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 clear. The description adds the return format (JSON with {ok, message, next_tool, next_args, ...tool-specific fields}) and the specific data fields, which is useful. However, it does not disclose behavior like whether the instance must exist, error handling, or rate limits. With annotations covering safety, a 3 is appropriate.

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 concise and front-loaded with the key fields returned. The return format is mentioned in the second sentence, which is useful. It is appropriately sized for a simple read tool, though it could be slightly more structured by separating the return format from the field list.

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 tool has an output schema, so return values are partially covered. However, the input schema has 0% description coverage, and the description does not explain the 'template' parameter or any prerequisites. For a read-only tool with annotations covering safety, the description is adequate but not complete. The missing parameter semantics and lack of usage guidance leave 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 compensate for the undocumented parameters. The description mentions 'a single instance' but does not explain the 'instance_id' parameter or the optional 'template' parameter. The schema only provides types and required status, leaving the agent to infer the meaning of 'template'. This is a significant gap.

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

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

The description states a specific verb ('get') and resource ('a single instance') and lists the concrete fields returned (status, endpoint, SSH command, spend, teardown schedule). It is clear what the tool does, though it does not explicitly distinguish itself from sibling tools like list_instances or wait_for_instance.

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 usage for retrieving detailed information about one instance, but it does not explicitly state when to use this tool versus alternatives like list_instances or wait_for_instance. The context signals and sibling list provide some context, but the description itself lacks explicit when-to-use or when-not-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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds beyond these by disclosing the return envelope ('Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}') and the specific log content, which is useful behavioral context not present in 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 with no filler. The core action is front-loaded ('Tail of the container log') and the return format is succinctly stated. 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?

With an output schema present and annotations covering safety, the description provides enough for a competent agent: it names the resource, the notable log content, and the response envelope. The only notable gap is the lack of clarification for instance_id, but this is a common identifier and the schema marks it required.

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%: only 'tail' is documented, while required 'instance_id' has no description. The description does not mention either parameter or compensate for the missing instance_id semantics. An agent must infer that instance_id identifies the container, which is plausible but not explicit.

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 action and resource: 'Tail of the container log.' It adds a distinctive detail (weight-download progress from setup script) that makes it clear what this tool offers beyond generic log retrieval. No sibling tool appears to overlap with this purpose, so an agent can reliably distinguish 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?

The description implies when to use (inspect container logs, especially setup progress) but provides no explicit guidance on when not to use it or alternatives. It does not name sibling tools or state prerequisites, so usage context is only inferred.

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

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

Annotations already cover read-only, open-world, and non-destructive behavior. The description adds value by disclosing the return envelope ({ok, message, next_tool, next_args, ...}) and the fact that the tool tells you how to proceed once the workload is online.

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 filler, with the core purpose front-loaded and the return shape following immediately. Every clause contributes useful 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 a single well-documented parameter, a rich output schema, and annotations covering safety, the description is complete. It also flags the next_tool/next_args continuation mechanism, which is critical for an agent driving a multi-step workflow.

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

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

The schema covers the single template parameter at 100% including an example, so the description does not need to add parameter syntax. It provides only indirect context by framing the parameter as a workload, which is adequate but not extra semantic 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?

The description is specific: 'Full detail for one workload' identifies the resource and scope, and the enumerations (weight files, hardware gates, drive instructions) make it unmistakable. The singular 'one workload' separates it from list-oriented siblings like list_templates and list_gpus.

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 makes the usage context clear: use this when you need complete detail about a single workload/template. It does not explicitly name alternatives or exclusions, but the singular scope and the mention of next_tool/next_args strongly imply a selection-and-drill-down flow.

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

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

Annotations already declare this is read-only and non-destructive, and the description adds genuinely extra behavioral detail: the bucket categories, the 'not by sticker $/hour' ranking with download time weighted, and the {ok, message, next_tool, next_args} response envelope. Nothing in the description contradicts 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?

Three tight sentences: the first states the purpose, the second adds the ranking nuance that prevents misuse, and the third gives the return envelope. There is no filler, repetition, or redundant restating of the tool name.

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 output schema, annotations, sibling context, and a small param set, the description covers the tool's role, ranking behavior, and return wrapper. The main gaps are the unclarified max_usd_per_hour parameter and the lack of explicit usage boundaries, but those do not make the tool unusable for an agent.

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

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

The schema documents limit, template, and work_minutes, covering 3 of 4 params; the description mainly reinforces template via 'workload' and work_minutes via 'weight download time included'. It does not clarify max_usd_per_hour, whose schema field has no description, so the description only partially compensates.

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 'Live Vast offers for a workload' names a concrete resource and action, and the bucket/ranking explanation ('ready_now ... unsupported', ranked by actual session cost) differentiates it from sibling listing tools like list_templates or list_instances. The title reinforces the central differentiator: ranked by real cost.

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 usable context: call it when you need live offers that can run a specific workload/template. However, it never names an alternative or an explicit exclusion, such as 'use estimate_deployment instead when you only need a cost estimate', so it does not fully meet the bar for a 5.

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

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

Annotations already cover read-only, non-destructive, open-world behavior. The description adds meaningful behavior beyond that: it flags instances lacking a teardown entry and reveals the return envelope includes next_tool and next_args, implying possible follow-up routing. This is useful context not present in 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?

Three tight sentences: the first defines scope and data, the second adds the flagging behavior, the third documents the return envelope. No filler or redundancy; all content 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 parameterless read-only listing tool with an output schema and safety annotations, the description fully equips an agent to select and invoke it. It covers scope, included fields, special flagging, and the response shape, with no obvious missing guidance.

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

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

There are zero parameters, so the schema carries no burden. The description correctly focuses on what the tool returns rather than parameters, matching the baseline for a parameterless 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?

The description identifies the resource ('every instance on the account'), the scope ('account'), and the specific data included (cost per hour, total spend, scheduled teardown). It clearly differentiates from siblings like get_instance (single instance) and list_templates/list_gpus (different resources).

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 makes the tool's purpose obvious, so an agent can infer when to call it for account-wide instance inventory. However, it does not explicitly state when to prefer this over get_instance or how it relates to the many lifecycle sibling tools, leaving the routing partly 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 cover readOnlyHint=true and destructiveHint=false. The description adds a concrete return envelope ({ok, message, next_tool, next_args, ...}) and emphasizes that the data reflects 'real' requirements, which is useful behavioral context beyond the annotations. No contradiction with 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 first sentence and return-format note are efficient and useful. The middle sentence about MiniMax H3 and LTX-2.5 is promotional, subjective, and unnecessary for selecting or invoking the tool, adding noise without operational 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?

For a zero-parameter read-only list with an output schema, the description is mostly adequate. However, it does not explain what next_tool/next_args mean or how an agent should proceed after receiving them, and it gives no usage context relative to the deployment workflow.

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 has zero parameters and schema coverage is 100%, so the description carries no parameter burden. The baseline for a zero-parameter tool is 4.

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 identifies the resource as 'Ready-to-run workloads' and specifies the key attributes returned (VRAM, architecture, download requirements), making it clear this is a catalog/list operation. It does not explicitly name a sibling, but the content is distinct from list_gpus and get_template. Some extraneous model commentary slightly weakens the focus.

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 guidance about when to use this tool versus alternatives like get_template, list_gpus, or recommend_plan. The description implies browsing workloads before deployment, but never states a condition, prerequisite, or exclusion.

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 (readOnly, openWorld, non-destructive), the description discloses a real behavioral guarantee—'Never picks hardware the workload cannot run on'—and explains that it accounts for weight-download costs rather than sticker price. It also reveals the return envelope {ok, message, next_tool, next_args}, making its recommend-then-delegate behavior concrete. No contradiction with annotations; readOnlyHint is consistent with producing next_args rather than creating.

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 clauses front-load the core value proposition, and every sentence earns its place: plan contents, the compatibility guarantee, and the return envelope. There is no filler, restatement of the schema, or marketing language.

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

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

The description covers the plan contents, cost model (weight download), safe-selection guarantee, and return envelope, and an output schema exists so return values need not be re-explained. Gaps are moderate: no statement of failure behavior when no offer fits, and no explicit routing relative to estimate_deployment—though the core calling contract is clear.

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 83%, so the baseline is 3 even without parameter details in the description. The text reinforces the planning model (session cost, work_minutes context) but adds no parameter-specific semantics and does not compensate for max_usd_per_hour, the single parameter lacking a schema 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?

States a specific verb+resource: it turns a workload template into a concrete rental plan. Names the exact deliverables (offer to rent, session cost including weight download, avoided sticker-price trap, create_instance arguments) and differentiates from siblings like estimate_deployment and create_instance by framing itself as the planning step that outputs next_tool/next_args.

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

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

Usage context is implied—'One call from a workload to a concrete plan' signals this is the pre-create planning step, and 'exact create_instance arguments' hints at its place in the workflow. However, it never names alternatives or exclusions; with siblings like estimate_deployment that could plausibly serve the same role, an explicit 'use this when X, use that when Y' is missing.

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 indicate a mutating, idempotent, non-destructive operation. The description adds the key side effect: it restarts the reaper if it died while instances remain scheduled, and it discloses the return shape. This is meaningful context beyond the annotation flags.

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 compact sentences: state, side effect, when-to-call, and return format. Every sentence adds a distinct piece of information and the most important behavior is front-loaded.

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

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

For a single optional-parameter status tool with an output schema and annotations, the description covers behavior, trigger, side effect, and return envelope. Nothing needed to select or invoke 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 100%, so the restart_reaper parameter is already documented with its default. The description adds a restart condition ('if it died while instances are still scheduled'), but does not explain or map the parameter by name, so it stays at the high-coverage 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 states the tool exposes the teardown ledger and reaper process state and can restart a dead reaper, which is a clear resource and action. It doesn't explicitly contrast with sibling tools, but 'proof that nothing will be left running' makes its role distinctive.

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

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

It gives an explicit trigger: 'Call this whenever you want proof that nothing will be left running.' It does not enumerate exclusions or alternatives, but the context is sufficient for routine selection among teardown-related siblings.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses the polling timeout, the exact phase vocabulary, the need to call repeatedly, and the response envelope including next_tool and next_args. This gives the agent a strong behavioral model of 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?

Three front-loaded sentences with no filler: the polling behavior, phases, repeat guidance, boot-time hint, and return format each earn their place. The structure makes the key call pattern immediately visible.

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 an output schema present and annotations covering safety, the description supplies the essential operational context: polling duration, phase list, repeated calls, and the JSON envelope. The unexplained template parameter is the only notable completeness 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 only 33%, yet the description adds no parameter-specific details. It only indirectly reinforces max_seconds via 'up to 45 seconds' and leaves instance_id and template unexplained, which is a real gap for correct invocation.

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 action: polls for up to 45 seconds and returns the instance phase. It lists the possible phase values, making the tool's scope evident. It does not explicitly differentiate from sibling get_instance, but the polling/repeated-call behavior separates it enough for a strong score.

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

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

The description gives concrete usage guidance: 'Call repeatedly until online' and notes that weight downloads take most of the boot time. It does not explicitly state when to avoid this tool or name alternatives, but the usage context is clear.

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