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

With no annotations, the description carries the full transparency burden. It adds the HTTP PUT method, but does not disclose permissions, price validation rules, reversibility, or error/edge-case behavior. The phrase 'Change' only restates the mutation; it doesn't explain side effects beyond the obvious.

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 plus an example, front-loading the core purpose and providing a usage snippet with no filler or redundant explanation.

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 is simple with two required parameters and has an output schema, so the missing return-value explanation is acceptable. However, it lacks parameter semantics and any caveats about interruptible instances, making it minimally adequate but not fully self-contained.

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. The example shows arguments (instance_id=12345, price=0.25) but provides no meaning for price units, allowed ranges, or how instance_id is resolved. The schema's names are self-explanatory, but the description adds minimal semantic value beyond the example.

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 ('Change the bid price') on a specific resource ('interruptible instance') and includes the endpoint path, which clearly distinguishes it from sibling tools like manage_instance or create_instance. The example call reinforces the purpose.

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 identifies when to use the tool: to change the bid price of an interruptible instance, and gives a concrete invocation example. It doesn't provide explicit exclusions or alternative tool names, but no sibling appears to handle bid pricing, so the context is sufficient.

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 carries the full burden and does disclose important behavior: env must be a flat dict and how port mappings are encoded, onstart behavior on SSH/Jupyter runtypes, and that the entrypoint is replaced by Vast's. It does not cover side effects like billing or authentication, but the provided behaviors are substantive and help the agent understand what the tool does beyond a simple create.

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 well-structured: a concise opening, followed by essential usage notes, then four diverse examples. Every sentence adds value, and the examples cover the main variations (image-based, template-based, spot instance, env/onstart usage). It is appropriately sized for the tool's complexity.

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 tool with 14 parameters and no annotations, the description covers the most critical aspects and provides a range of examples. An output schema exists, so return values do not need to be explained. It misses explanation of some parameters and does not mention billing or permission requirements, but overall it gives enough for common use cases.

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

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

Schema description coverage is 0%, so the description must compensate. It explains several key parameters (image, template_hash_id, price, env, onstart, runtype) and provides examples. However, 14 parameters exist, and several (disk, label, args_str, image_login, jupyter_dir, volume_info, use_jupyter_lab) are not explained at all, leaving gaps for an agent to infer their 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 clearly states the tool's purpose: 'Rent a GPU by accepting offer_id (PUT /asks/{offer_id}/)'. This is a specific verb+resource combination. It is distinct from sibling tools like list_instances, destroy_instance, and search_offers, leaving no ambiguity about when to invoke 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 provides clear usage context: it states the required fallback between image and template_hash_id, explains how to request spot instances via price, and shows how to use onstart for app launch. It does not explicitly mention when not to use the tool or alternative tools, but the guidance is strong and practical.

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 carries the full burden of behavioral disclosure. It states the operation is permanent and irreversible, and includes the HTTP DELETE method, providing essential safety-critical information. It does not mention potential side effects on associated resources beyond 'all its data', but the key destructive behavior is transparent.

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 extremely concise: two sentences plus a code example. It front-loads the purpose and warning with zero redundancy. Every word 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 one-parameter destructive tool, the description covers the core action, irreversibility, and usage example. Since an output schema exists, return value details are not needed. It could be more complete by noting whether the instance must be stopped first, but it is sufficient for an agent to understand the tool's role.

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 one required integer parameter, instance_id. The description adds a usage example (destroy_instance(instance_id=12345)) which demonstrates the parameter format, but does not explicitly explain its semantics. With 0% schema coverage, the description provides only minimal compensation beyond the self-explanatory parameter name.

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 'Permanently destroy an instance and all its data', using the specific verb 'destroy' and resource 'instance'. This distinguishes it from sibling tools like manage_instance or get_instance, leaving no ambiguity about its purpose.

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 the tool (when you want to permanently delete an instance) and adds a strong warning ('Irreversible. Call carefully.') but does not explicitly compare it to alternatives or state any exclusions, such as needing to stop the instance first. Usage context is implied rather than explicitly guided.

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, description fully discloses behavioral details: API rejects on running instances with an exact error message, enforced command whitelist (400 'Invalid command given'), and which commands are accepted vs. rejected. It also clarifies that arbitrary commands require ssh_exec, giving the agent a complete mental model.

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

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

The description is front-loaded with the most critical constraint (STOPPED instance) and uses paragraph breaks for readability. Every sentence adds value: error behavior, whitelist, alternatives, and example. It's appropriately sized for the complexity.

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, error scenarios, command whitelist details, alternatives, and an example. With an output schema present, the missing return-value documentation is acceptable. The description is fully self-contained for selecting and invoking 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 0%, but description compensates with a concrete example: execute_command(instance_id=12345, command="ls /workspace"). This clarifies both parameters' roles and command format. However, it doesn't explicitly define parameter types or constraints beyond the example, so it's strong but not exhaustive.

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 opens with a specific verb+resource+scope: 'Execute a constrained remote command on a STOPPED instance'. It clearly distinguishes from sibling ssh_exec by explicitly noting it only works on stopped instances and directing running-instance commands to ssh_exec.

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 when to use ('Only works on instances whose actual_status is stopped'), why (transient launch commands), and when not to (running instances API rejects with quoted error). Names the alternative (ssh_exec) and explains the command whitelist, including example accepted and rejected commands.

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 the full burden. It discloses the HTTP method (GET), which implies a read-only operation, and mentions the 'authenticated user', indicating authentication is required. It does not cover error cases or rate limits, but for a zero-parameter read-only tool, the essential behavior is conveyed.

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, front-loaded with the main purpose, and includes the endpoint and an example call. Every element is useful, with 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?

Given the tool's simplicity (zero parameters) and the presence of an output schema, the description is complete. It identifies what the tool returns (account info and credit balance) and how to call it, leaving no significant 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?

The tool has zero parameters, so the schema already covers everything. The description adds no parameter details, but none are needed. The baseline score of 4 is appropriate for a no-parameter 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 clearly states the tool retrieves the authenticated user's account info and credit balance, with a specific verb ('Retrieve') and resource. It includes the exact endpoint (GET /users/current/) and is distinct from all sibling tools, which focus on offers, instances, GPUs, 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?

The description implies usage when a user needs their own account info or credit balance, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. Since no sibling tool is similar, the implicit context is acceptable but not fully explicit.

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

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

No annotations are provided, so the description carries the full burden. It only states it returns a snapshot and gives the endpoint; it does not disclose return format, filter effects, authentication needs, rate limits, or read-only behavior. This is a significant gap for a data query 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 description is compact and front-loaded: the first sentence states the purpose, the endpoint is included parenthetically, and examples are useful without being verbose. Every element 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?

An output schema exists, so return value details are covered, but the description fails to explain the datacenter parameter or how this tool relates to alternatives like get_gpu_trends. The lack of annotation context makes this incomplete for an agent deciding how to invoke it.

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

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

Schema description coverage is 0%, but the examples add meaning by showing gpu_name accepts a list of strings (e.g., 'RTX 4090', 'A100') and verified accepts a boolean. However, the datacenter parameter is completely undocumented in both the schema and the description, leaving a 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 first sentence clearly states it provides a 'current snapshot of supply, demand, and pricing across GPU types,' which is a specific action on a specific resource. This also distinguishes it from sibling tools like get_gpu_trends, which implies time-series data.

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

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

Examples show invocation patterns, but there is no explicit guidance on when to use this tool versus alternatives such as search_offers or get_gpu_trends. Usage context is only implied by the 'current snapshot' wording.

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 the burden of behavioral disclosure. It does reveal the default sampling behavior ('~20 sampled data points over the window by default') and implies read-only via the GET endpoint, but it lacks statements about permissions, side effects, or rate limits. It adds some value beyond the 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?

The description is short and front-loaded with the main purpose. It includes a useful endpoint reference and two concrete examples. However, the opening is a fragment ('Time-series of...') which is slightly awkward 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?

An output schema exists, so return types are not needed. The tool has 3 optional parameters, and the description covers two through examples but omits step entirely. Given the absence of annotations and schema descriptions, the tool is not fully self-explanatory, but it is adequate for a read-only data retrieval 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 0%, so the description must compensate. While examples illustrate gpu_names and window_hours, the step parameter is never mentioned, and no parameter is described in terms of format, units, or effect. The phrase about sampling hints at step but does not explain 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 clearly identifies the tool as providing a time-series of GPU supply/demand/pricing, with the specific endpoint. It distinguishes itself from the sibling get_gpu_metrics by focusing on historical trends ('Time-series'). The examples further clarify 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?

The usage is implied through examples and the time-series nature, but there is no explicit statement of when to use this tool versus alternatives like get_gpu_metrics or search_offers. No exclusion criteria or prerequisites are mentioned.

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 carries the full burden of disclosing behavior. It explicitly says 'GET', which indicates a read-only operation, and 'Retrieve' further clarifies that it doesn't mutate data. However, it does not mention potential errors (e.g., 404 for missing instance), authentication requirements, or rate limiting, which are relevant for a network 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?

The description is extremely concise—two sentences plus a code example—with every element earning its place. It front-loads the core action ('Retrieve details of a specific instance') and the example is helpful. No fluff or 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?

The tool is a simple get-by-id operation, and the description covers the essential action, endpoint, and example. Since an output schema exists, return values are already handled. It could benefit from a brief note about error behavior or prerequisites (e.g., instance must exist), but these are minor gaps for such a straightforward 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 input schema has one required integer parameter (instance_id) with zero description coverage. The description adds an example call (get_instance(instance_id=12345)) that demonstrates the syntax, and the endpoint clarifies that the ID identifies the target instance. However, it does not explain the type system or how to obtain a valid instance_id (e.g., from list_instances).

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 'Retrieve details of a specific instance' and includes the exact HTTP endpoint (GET /instances/{id}/), which makes the tool's purpose unambiguous. This positions it distinctly as a single-item getter compared to siblings like list_instances, destroy_instance, or create_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?

No guidance is provided on when to use this tool versus alternatives. The description only shows an example invocation, leaving the agent to infer that it should be used when a specific instance_id is known. It does not mention related tools like list_instances for discovering IDs or how to handle different scenarios.

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 carries the burden of disclosing behavior. It states that the tool resolves and returns a command (not executing it), and it specifies runtime requirements. This is sufficient for a low-risk read-only tool, though it doesn't explain error handling if preconditions are unmet.

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

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

The description is two concise sentences plus a relevant example. It front-loads the main action and output, then adds preconditions. No superfluous text, and the example reinforces usage without being verbose.

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 simple one-parameter tool and the presence of an output schema (not shown here), the description sufficiently covers the purpose, preconditions, and output format. It could mention what happens on failure, but for a lookup tool this is a minor gap. The context from sibling tools helps round out 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?

The schema has 0% parameter description coverage, but the description compensates by showing an example (`get_instance_ssh_info(instance_id=12345)`) and referencing instance attributes (`actual_status`, `runtype`) that give context to the `instance_id` parameter. This makes the parameter's meaning clear even though the schema does not describe 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 uses a specific verb ('Resolve') and identifies the resource ('instance's direct SSH endpoint'), clearly stating the output (a ready-to-run ssh command). It implicitly distinguishes itself from siblings like ssh_exec by clarifying that it returns a command rather than executing 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?

The description provides explicit preconditions for use ('Requires actual_status == "running" and a ssh_direct or jupyter_direct runtype'), which helps the agent know when it is applicable. It does not explicitly name alternatives, but the preconditions and output make the usage context 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?

With no annotations, the description carries the full burden. It adds the scoping fact that only the authenticated user's instances are listed, which is useful. However, it does not disclose whether the operation is read-only, any authorization requirements, or behavior like pagination or filtering semantics beyond the example. This is adequate but minimal.

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 extremely concise, front-loaded with the core purpose, and includes two clear usage examples. Every element earns its place with no fluff.

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

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

Given the simple nature of the tool (one optional parameter, output schema exists), the description covers the core operation and examples adequately. It lacks caveats about pagination or rate limits, but these are less critical for a simple list operation with an output schema.

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

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

Schema description coverage is 0%, so the description must compensate. The examples show how to pass a label, hinting that it filters instances, but the description never explicitly explains the label parameter's meaning. This marginal addition is slightly better than nothing but not a full semantic explanation.

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 the authenticated user's instances and includes the API endpoint (GET /instances/). This is a specific verb+resource combination that distinguishes it from siblings like get_instance or create_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 provides clear context (lists the user's own instances) but does not explicitly state when to use this tool versus alternatives like get_instance or search_offers. It gives examples of how to call it but lacks explicit 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?

No annotations are provided, so the description carries the transparency burden. It adds the HTTP method (GET /ssh/) and implies a read-only operation through the word 'List.' However, it does not explicitly state auth requirements, side effects, or scope (e.g., all keys on the account), which could be 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?

The description is one sentence plus a concise example. It is front-loaded with the key purpose and adds no fluff. Every word 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 list tool with zero parameters and an output schema present, the description covers the essential purpose and useful endpoint detail. It doesn't mention authentication or pagination, but these are either implied or likely covered by the output schema. Overall, it is sufficiently complete for this simple tool in 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?

The tool has zero parameters, and the schema coverage is 100% (empty schema). Per the rubric, baseline for 0 parameters is 4. The example `list_ssh_keys()` reinforces that no arguments are needed, adding marginal value 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 clearly states 'List SSH keys registered on the Vast.ai account,' which uses a specific verb ('List') and resource ('SSH keys registered on the Vast.ai account'). This distinguishes it from sibling tools like register_ssh_key (which creates a key) and get_instance_ssh_info (which targets a specific instance's SSH info).

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 by specifying it lists account-level SSH keys, but it does not explicitly mention when to use this tool versus alternatives (e.g., getting instance-specific SSH info). No clear exclusions or alternative guidance is 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?

With no annotations, the description takes on full disclosure burden. It reveals key behavioral details: reboot stops/starts preserving GPU priority, recycle destroys and recreates from fresh image pull. It also documents endpoint patterns. It doesn't mention auth or rate limits, but for the core actions it is transparent.

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?

Structured with a clear summary line, bullet points for actions, and relevant examples. Every sentence adds value, and the formatting is easy to scan. No redundant content.

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 is comprehensive for a multi-action tool, covering all action types and their differences. Output schema exists, so return value explanation is unnecessary. Minor gaps include no explicit mention of error conditions or prerequisites, but the examples and action semantics make it largely 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?

Schema coverage is 0%, so the description must compensate. It explains the action enum values, notes that label is required when action='label', and provides examples showing parameter usage. instance_id is self-explanatory. This is adequate coverage for the 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?

The description clearly states the tool's function: 'Control instance state' and enumerates specific actions (start/stop/label/reboot/recycle). It distinguishes from sibling tools like destroy_instance and create_instance by focusing on state management, and provides concrete action definitions.

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 clear guidance on each action's semantics, including when to use reboot vs recycle (preserves GPU priority vs fresh image pull). Includes examples for common usage. However, it doesn't explicitly contrast with alternative tools like destroy_instance for permanent deletion, which would strengthen 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?

No annotations are provided, so the description carries full burden. It explains path construction but fails to disclose potential side effects (e.g., destructive methods like DELETE), authentication requirements, or error behavior. This is a notable gap for a tool that can execute arbitrary API calls.

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 only a few lines, front-loads the key phrase 'escape hatch', and uses two examples to illustrate usage. Every sentence earns its place with 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?

Given low schema coverage and no annotations, the description provides essential info (base URL, path formation, examples) but omits safety warnings and any guidance on the ambiguous 'params' field. An output schema exists, so return values are handled, but the description could be more complete for a raw request 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 description clarifies that 'path' must include a leading slash and shows examples with 'method' and 'body', but it does not explain the 'params' parameter at all. With 0% schema coverage, this leaves one of four parameters undocumented, though path and body are partially explained.

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 this is an 'escape hatch' for REST endpoints not covered by other tools, with the path appended to a base URL. It distinguishes from siblings by being the catch-all raw request tool, and includes concrete examples.

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 to use when an endpoint is 'not covered by other tools', implying preference for more specific tools. Provides examples for GET and POST, demonstrating 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals critical side effects: the key is automatically applied to all current and future instances, and it explicitly states that only the .pub file is read, never the private key. This is highly transparent.

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 yet complete: it states the endpoint, explains the side effect, adds a safety note, and includes two realistic examples. Every sentence adds value with no padding.

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

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

For a simple tool with only two parameters and an output schema, the description covers purpose, behavior, parameter semantics, and safety. The existence of an output schema means return-value details are not required, and the description sufficiently addresses all necessary 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?

The schema has no parameter descriptions (0% coverage), so the description must compensate. It does so via concrete examples (name='laptop', public_key_path='C:/Users/me/.ssh/id_ed25519.pub') and the note about reading the .pub file, which clarifies the meaning of public_key_path. It does not explicitly define 'name' beyond the example, but the provided examples are clear enough.

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 purpose: 'Register a local SSH public key on the Vast.ai account' with a specific verb and resource. It also distinguishes from siblings like list_ssh_keys and ssh_exec by focusing on the registration action.

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

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

The description implies when to use the tool by showing examples and explaining the key is applied to all current and new instances. However, it does not explicitly mention alternatives or exclusions, so it stops short of a full 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?

With no annotations provided, the description carries the full burden. It discloses the HTTP method (GET), the return type (list), and example fields (gpu_name, value, type), plus an example call with no arguments. This goes beyond a minimal statement, though it omits potential pagination or auth details.

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: two sentences and an example call. It front-loads the main purpose and includes the endpoint and return fields, with no redundant content. It is appropriately sized for a simple 0-parameter 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?

The tool is simple (0 params, read-only list retrieval) and an output schema exists, so the description need not explain return values beyond what fields are included. The description provides the endpoint, return structure, and example, making it complete for the tool's 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?

The input schema is empty and has no parameters, so schema coverage is trivially 100%. The description reinforces this by showing an example call with no arguments. Baseline for 0 params is 4, and the description adds no unnecessary param details.

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 'Retrieve all GPU benchmark records' with a specific verb and resource, and also provides the HTTP endpoint GET /benchmarks/. It is distinct from sibling tools like search_offers, search_templates, get_gpu_metrics, and get_gpu_trends, 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?

The description implies usage (when you need GPU benchmark records) but does not explicitly mention alternatives or exclusion criteria. It names no sibling tools or conditions, so the guidance is only implicit, not explicit enough for a 4.

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 burden. It discloses that the body is passed as-is to POST /bundles/, and explains filter operators (eq, neq, gt, etc.) with two concrete examples. It does not mention rate limits, authentication, or response structure, but the read-only nature is apparent from 'search'.

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 opens with a clear purpose statement, then concisely explains the API mapping, filter syntax, and gives two illustrative examples. No redundant information; 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 the complex query syntax and a bare-bones schema, the description provides thorough guidance on constructing valid queries, including operators and representative examples. It stops short of detailing response format, but an output schema exists (not shown) to cover that, making it sufficiently 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?

Schema has a single generic 'query' object with additionalProperties: true and no property descriptions, so schema coverage is 0%. The description compensates fully by explaining top-level keys, filter object structure, operator list, and providing examples that illustrate parameter composition.

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 uses a specific verb ('Search') and resource ('Vast.ai GPU marketplace for rentable machine offers'), clearly distinguishing it from siblings like search_benchmarks and search_templates. Even without a title, the purpose is unmistakable.

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 clear context (searching marketplace offers) and extensive examples showing how to formulate queries, but does not explicitly contrast with alternative tools like list_instances or get_gpu_trends. No exclusions are stated, so it meets the 'clear context, no exclusions' level.

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 the burden of behavioral disclosure. It explicitly discloses the endpoint method, the required body constraint, and the default behavior ('defaults to {}'). It does not discuss auth or rate limits, but the 'search' verb implies read-only, and the examples clarify invocation 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 concise and front-loaded with the purpose. Each sentence adds value: the endpoint, the body requirement, the default behavior, and two examples. There is no wasted text, and the examples make the usage immediately understandable.

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 tool's simplicity (one optional parameter, output schema present, no annotations), the description is complete enough. It covers the parameter semantics, default behavior, and provides examples. Return values are presumably covered by the output schema, so no additional return description is 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?

Schema coverage is 0%, so the description fully compensates by explaining the `select_filters` parameter: it shows the format for 'all' (`{}`) and provides a concrete example with a tag filter (`{"tag": {"eq": "pytorch"}}`). This adds meaning far beyond the bare schema definition of object/null.

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: 'Search user and public templates', with the specific endpoint '(GET /template/)'. This uses a specific verb and resource, and the resource 'templates' distinguishes it from siblings like search_offers and search_benchmarks.

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 clear usage context: it explains that the endpoint requires a `select_filters` body, shows how to pass `{}` for 'all', and includes two practical examples. It does not explicitly mention alternative tools, but the distinct resource makes alternatives unnecessary; 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently reveals a non-obvious behavior: logs are uploaded to S3 and the response contains a URL to fetch them, rather than returning logs directly. It also mentions the PUT method, which is unusual for a 'show' operation. However, it omits details like URL expiration or asynchronous processing, which would be additional valuable 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 description is concise and well-structured: a single sentence introducing the action, a second sentence disclosing the S3 URL behavior, and two clear example calls. Every sentence adds value and the examples are front-loaded to illustrate usage without unnecessary prose.

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 presence of an output schema (which defines return values) and the tool's moderate complexity (2 parameters), the description covers the core behavior adequately: endpoint, S3 URL, and example calls. The only notable gap is the undefined meaning of the 'tail' parameter, which is a minor omission for an otherwise sufficiently described 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 0%, so the description must compensate for parameter meaning. The example calls show parameter names and values (e.g., tail=5000), but they do not explain the semantics of 'tail' (e.g., number of lines to fetch) or the role of instance_id beyond what the schema already provides. The description adds no meaningful semantic detail beyond the schema's type/default information.

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 purpose with a specific verb ('Request') and resource ('instance logs'), including the exact HTTP endpoint (PUT /instances/request_logs/{id}). It also distinguishes the tool from siblings by noting that logs are uploaded to S3 and a URL is returned, which is unique among the listed tools.

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

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

The examples imply typical usage (e.g., show_instance_logs(instance_id=12345) and show_instance_logs(instance_id=12345, tail=5000)), but the description does not explicitly state when to use this tool versus alternatives like get_instance or execute_command. There are no clear exclusions or alternative tool references.

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 present, so the description carries the full burden. It discloses key non-obvious behaviors: automatic host/port resolution, private key never sent to the API, and key_path falling back to VASTAI_MCP_SSH_KEY_PATH env var. It does not detail failure modes or return formats, but an output schema exists to cover returns.

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 with the core purpose, followed by a short security note and three illustrative examples. Every sentence adds value; no fluff or 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?

For a tool with no annotations, the description covers authentication, connection resolution, and key path defaults, and the output schema handles return value documentation. It gives examples for common commands but does not discuss shell environment or failure behavior, which would be nice but not essential.

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 compensates. Three examples illustrate all five parameters, and it explicitly explains key_path's env-var default. It does not explicitly state timeout units or null key_path behavior in prose, but the examples and schema defaults provide adequate 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?

Description opens with 'Execute a command on a running instance over SSH (paramiko)', clearly identifying the action, resource, and transport. It distinguishes itself from sibling tools like ssh_transfer (file transfer) and execute_command (potentially API-based) by emphasizing direct SSH 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 provides clear context: it automatically resolves ssh_host/ssh_port, requires a local private key, and includes practical examples. It does not explicitly name alternative tools or state when not to use it, but the 'over SSH' qualifier and examples supply enough situational 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?

With no annotations, the description carries the full burden. It discloses important behavioral traits: directories are unsupported, ssh_host/ssh_port are auto-resolved, the private key stays local, and key_path defaults to an env var. It does not mention overwrite behavior or return specifics, but it covers key operational expectations.

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 well-structured: a single clear statement, bullet points for directions, a limitation note, a default note, and two representative examples. Every sentence adds value with no fluff.

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

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

The description fully covers the tool's main behavior, limitations, and examples. It does not explain user/timeout parameters or potential overwrite behavior, but the tool is simple and the output schema likely covers return values. Overall, it is complete enough for a straightforward file transfer 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 0%, so the description must compensate. It explains the core parameters (direction, local_path, remote_path, instance_id) and the key_path default. It omits the user and timeout parameters, but those have defaults and are secondary. The examples also illustrate parameter usage clearly.

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 transfers a single file over SFTP and distinguishes upload vs download directions. It specifies the exact resource (single file) and action (transfer), making it distinct from sibling tools like execute_command or ssh_exec.

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 clear context on when to use the tool (for single-file transfers) and explicitly notes that directories are not supported, requiring per-file calls. However, it does not explicitly name alternatives or state when not to use this tool, just missing the explicit 'when-not-to' guidance.

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