lambda-labs

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

The description contradicts the annotation. The annotation declares destructiveHint: true, but creating a filesystem is a non-destructive, additive operation. The description itself does not mention any side effects, costs, or other behavioral traits beyond the creation action. This is a serious inconsistency that could mislead an agent about the tool's safety profile.

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

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

The description is concise and front-loaded: a single main clause stating the purpose, a parenthetical clarifying usage, and the REST endpoint for reference. There is no wasteful wording, and every clause adds information.

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

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

For a simple create operation with two parameters and no output schema, the description covers the main purpose and the practical downstream use (attaching to instances). It could be more complete by noting whether the operation is idempotent or what the return value is, but given the low complexity, it is largely sufficient.

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 already provides full descriptions for both parameters (name with pattern and region with example). The description adds no additional parameter-level information, so it does not exceed the baseline of 3 set by the high schema coverage.

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

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

The description clearly states the action ('Create a new persistent filesystem') and specifies the resource and scope ('in a region'). It also notes that the filesystem can be attached to instances at launch, which distinguishes it from sibling tools like lambda_delete_filesystem and lambda_list_filesystems.

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 for when to use the tool: when a new persistent filesystem is needed and possibly to be attached to instances. It does not explicitly state when not to use it or list alternative tools, but the context is sufficient for a creation tool with no similar sibling.

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?

While annotations include destructiveHint=true, the description adds critical context: 'Irreversible — DESTROYS all data on it,' which goes beyond the annotation. It also discloses the attachment constraint, providing fuller behavioral transparency.

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

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

Two sentences, front-loaded with the core action, followed by warnings and a constraint. The REST endpoint is a minor but useful addition. No wasted words.

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

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

For a simple one-parameter delete operation with destructive annotations, the description covers the action, irreversibility, and a critical precondition. With no output schema, no further return-value explanation is needed. This is 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?

The input schema has 100% coverage with the description 'The filesystem id to delete.' The description merely says 'by id' and adds no additional semantics beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states 'Delete a persistent filesystem by id' with a specific verb and resource, and includes the REST endpoint. This distinguishes it from sibling tools like lambda_create_filesystem and lambda_list_filesystems.

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

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

Explicitly states a precondition: 'The filesystem must not be attached to any instance,' which serves as a when-not-to-use condition. It does not name alternatives, but none exist among siblings for this operation.

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, so the description need not restate safety. It adds minimal behavioral detail by specifying the endpoint and that it retrieves by ID. It does not describe error handling or response format, but for a read-only get operation, the annotation covers the key behavioral aspect.

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

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

A single sentence that communicates the essential action, resource, and constraint. No redundancy, well-structured, and immediately front-loaded with the verb 'Get'.

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 get-by-id operation with one parameter and no output schema, the description is sufficiently clear. It includes the REST endpoint and what the tool does. Could benefit from mentioning the return value, but it is implicit that it returns the firewall ruleset, and the low complexity keeps this from being a significant gap.

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

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

Schema description coverage is 100% with the only parameter 'id' described as 'The firewall ruleset id.' The description's mention of 'by id' adds no new semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Get'), the resource ('a single firewall ruleset'), and the specific scope ('by id'). It distinguishes from sibling tools like lambda_list_firewall_rulesets by explicitly indicating a single item lookup using an identifier, and the REST endpoint adds further precision.

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 context: use when you have a specific ruleset ID and need that single ruleset. Although it does not explicitly exclude list alternatives, the phrase 'single firewall ruleset by id' provides clear context for when this tool is appropriate compared to listing 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 the description adds valuable context by enumerating the returned fields (status, ip, region, instance_type, ssh/filesystem attachments, jupyter url, available actions) and the REST endpoint, going beyond a simple 'get details' statement.

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

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

The description is a single sentence, front-loaded with the main purpose, and includes the REST endpoint and key response details. Every word adds value with no 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?

Even though there is no output schema, the description enumerates the specific fields returned and the REST endpoint, making it complete for a simple, single-parameter read tool. It provides sufficient context for an agent to know what to expect.

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 already provides 100% coverage for the single parameter 'id', and the description only says 'by id' without adding format or usage details beyond what the schema offers. Baseline 3 is appropriate.

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

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

The description clearly states it gets full details of a single instance by id, listing specific attributes (status, ip, region, etc.), which distinguishes it from sibling tools like lambda_list_instances that list multiple 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?

The phrase 'single instance by id' clearly indicates when to use this tool, but it does not explicitly name alternatives or exclusions. Context is clear, but no direct 'when-not' 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?

Annotations include destructiveHint=true, but the description adds valuable behavioral context beyond that: 'COSTS MONEY: billing starts as soon as the instance boots (hourly rate per instance_type)'. It also discloses the constraint that exactly one SSH key is supported and keys must already exist. This is useful side-effect information not captured in 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 three sentences: purpose, cost warning, and usage guidance. It is front-loaded with the most important information and contains no fluff. 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 tool has 11 parameters and no output schema, the description focuses on the most critical aspects: required params, cost implication, and prerequisite data. Optional parameters are left to the schema, which fully documents them. This is a reasonable trade-off for a complex launch operation, though a mention of optional capabilities would push it higher.

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

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

Schema covers 100% of parameters, so baseline is 3. The description adds meaning by specifying how to select values for region_name and instance_type_name (from lambda_list_instance_types, capacity-aware) and ssh_key_names (exactly one existing key). It also clarifies quantity billing. This enriches the schema without repeating 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 states the tool's function: 'Launch one or more GPU cloud instances.' This is a specific verb+resource, and it distinguishes from sibling tools like terminate, restart, or list operations. The REST endpoint is also provided for clarity.

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 explicit guidance on where to obtain parameter values ('Pick region_name + instance_type_name from lambda_list_instance_types'), prerequisites ('only regions with capacity available', 'exactly one existing SSH key'), and a critical caveat (billing starts on boot). It does not explicitly mention alternatives or when-not-to-use, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, and the description adds the GET endpoint and pagination behavior, which is useful context. However, it doesn't disclose any other behavioral traits like rate limits or return format. The added info partially overlaps with the schema, so it doesn't go far beyond the annotation baseline.

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

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

The description is a single, front-loaded sentence that states the primary action, optional filters, pagination, and REST endpoint. Every word earns its place, with no redundancy or filler.

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

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

For a simple read-only list tool with no output schema, the description is sufficiently complete. It covers the purpose, filtering, pagination, and endpoint. It doesn't explain return-values format, but that's not necessary given the tool's straightforward nature and the absence of 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?

The schema provides 100% description coverage for all 4 parameters, so the baseline is 3. The description mentions 'time window' and 'resource type' as a summary but doesn't add any meaning beyond what the parameter descriptions already state. No extra syntax or formatting details are provided.

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

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

The description states a specific verb ('List') and resource ('account audit-log events'), clearly distinguishing it from sibling list tools like list_instances or list_images. It also mentions optional filters and pagination, making the tool's 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 provides clear context on when to use the tool (to list audit events) and describes optional filtering and pagination. It doesn't explicitly name alternatives or exclusions, but no sibling tool covers audit logs, so a 4 is appropriate.

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 the description adds only the fields returned and the API endpoint. No additional behavioral traits such as pagination, rate limits, or scoping details are disclosed. The description is accurate but not rich beyond the annotation.

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

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

The description is two concise sentences that are front-loaded with the main action ('List your persistent filesystems') and include essential details without any waste. Every word contributes 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 parameterless list operation, the description covers the what (persistent filesystems), the key fields returned, and the use case (attachable at launch). No output schema exists, but the description sufficiently communicates return values, so it is 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?

The tool has zero parameters, so the schema is trivially fully documented. The description adds no parameter-specific meaning, but with no parameters, the baseline of 4 applies.

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

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

The description clearly identifies the tool as listing persistent filesystems with specific fields (id, name, region, status, created_at), and distinguishes it from sibling create/delete filesystem tools. It also states the REST endpoint, leaving no ambiguity about its function.

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 for when to use the tool: to list filesystems that can be attached to instances at launch. It does not explicitly mention alternatives or exclusion cases, but the context is specific enough for an agent to select it appropriately among sibling list 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?

The annotation readOnlyHint=true already declares this a read operation, so the description doesn't need to repeat that. It adds useful context about the scope and returned fields, but does not disclose potential pagination, rate limits, or authentication requirements, which would make the behavior more 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 one sentence, front-loaded with the verb and resource, followed by a compact field list and an API endpoint reference. Every element adds value and there is no redundancy or filler.

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

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

For a parameterless list tool with a readOnly annotation, the description adequately covers the resource scope and the main output fields. It omits details like pagination or response envelope, which would make it more complete, but the core intent and return content are 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?

The tool has zero parameters and the input schema is empty with 100% coverage, so there is no parameter semantics to document. The parenthetical list describes output fields, not parameters, and the 0-parameter baseline of 4 applies.

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

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

The description uses a specific verb ('List') and a specific resource ('the account's inbound firewall rules') with a parenthetical field list. This clearly distinguishes it from sibling tools like lambda_list_firewall_rulesets and lambda_get_firewall_ruleset, which target rulesets rather than the rules themselves.

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 clearly states it lists the account's inbound firewall rules, which gives an agent the context to select it for that purpose. However, it does not explicitly call out when not to use it or mention the ruleset-related alternatives, leaving the distinction to the sibling tool names.

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 the description adds the REST endpoint (GET) and the response shape (id, name, region, rules). It does not mention pagination or ordering, but for a simple read-only list operation this is sufficient behavioral detail.

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

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

A single, front-loaded sentence states the operation and key fields, followed by a REST reference. There is no wasted wording, and the structure leads with the action before providing context.

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

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

The description covers the returned fields, the use case, and the underlying REST call, which is essential given there is no output schema. It could mention pagination or limits, but for a zero-parameter list tool this is adequately 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?

The tool has zero parameters, so the schema is empty and schema description coverage is 100%. Per the rubric, a baseline of 4 applies when there are no parameters, and the description correctly omits parameter 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 explicitly states the action (list) and resource (firewall rulesets), and enumerates the returned fields (id, name, region, rules). The plural 'rulesets' and the mention of 'list' clearly distinguish it from the singular get_firewall_ruleset sibling.

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 context that these rulesets can be applied to instances, implying a use case, but it does not explicitly state when to prefer this tool over alternatives such as lambda_get_firewall_ruleset or lambda_list_firewall_rules. No exclusions or alternative comparisons are provided.

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

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

Annotations provide readOnlyHint=true, and the description adds useful context beyond this: the specific fields returned and the REST endpoint. It does not contradict annotations and discloses what the tool returns, which is sufficient for a read-only list.

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 short sentences with no unnecessary words. It front-loads the verb and resource ('List available machine images') and includes the REST endpoint as a clear reference.

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 no parameters and no output schema, the description is complete: it states what it lists, the key fields, the purpose, and the API endpoint. No further documentation 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?

The tool has zero parameters, so the description adds no parameter syntax or semantics. The baseline score of 4 applies because there is nothing to document beyond the schema, which is empty.

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

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

The description clearly states 'List available machine images' and specifies the content (id, name, family, version, region availability) and purpose (selecting when launching an instance). This distinguishes it from sibling list tools like list_instances and list_filesystems.

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 needing to select an image for launching an instance, providing clear context. It does not explicitly mention alternatives or exclusions, but the use case is unambiguous for a simple list operation.

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

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

The annotation readOnlyHint=true already establishes the read-only nature, so the description's added value is the returned field list and REST endpoint. It does not mention pagination, authentication, or potential side effects, and the word 'running' could mislead about the scope of results, but there is no direct 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 description is two sentences, front-loaded with the verb and resource, and includes the REST endpoint without 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 no-parameter, read-only listing tool, the description covers the purpose and output fields well. However, it does not explicitly clarify that all instance statuses are returned, and the 'running' qualifier may under-specify the actual behavior, making the description slightly incomplete.

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 description carries no parameter-documentation burden. According to the rubric, a no-parameter tool receives a baseline of 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 clearly states the action (List) and resource (GPU cloud instances), and enumerates the returned fields, which distinguishes it from singular get_instance and other resource-specific list tools. However, the qualifier 'running' is slightly inaccurate or ambiguous relative to the referenced GET /api/v1/instances endpoint, which returns all 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?

The description implies this is for listing instances as opposed to managing or retrieving a single one, but it provides no explicit guidance about when to prefer this over get_instance or other list tools. No exclusions or alternatives are mentioned, so usage context is only implied.

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

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

Annotations already indicate readOnlyHint=true, and the description aligns with that (a list operation). The description adds value by detailing the return contents: specs, hourly price, and current capacity availability, which helps set expectations beyond the annotation.

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

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

The description is only two sentences, front-loaded with the core purpose, and includes usage guidance and an API reference. Every sentence earns its place with no redundant or vague wording.

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 tool with no output schema, the description is complete: it states what the tool does, what data it returns, and how to use it. The mention of current capacity availability is critical for the agent's selection task.

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 in the schema, so the baseline is 4. The description enriches understanding by naming the returned fields (vcpus, memory, storage, gpus, price_cents_per_hour, regions with capacity), which is useful despite having no parameters to document.

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 'List all GPU instance types with their specs' clearly identifying the resource (GPU instance types) and the action (list). It also distinguishes from siblings like lambda_list_instances by noting it's for instance *types* with specs and capacity, not running 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?

The description explicitly says 'Use this to pick region_name + instance_type_name before launching,' giving clear context for when to invoke this tool. It does not explicitly mention alternatives or when not to use it, but the pre-launch use case 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?

The description explicitly says 'instances are NOT destroyed', which directly contradicts the destructiveHint=true annotation. This is a critical inconsistency that misleads the agent about the tool's safety profile.

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

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

Two sentences, action-oriented, with no redundant phrasing. The inclusion of the API endpoint adds useful context without bloat.

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?

Despite the tool's simplicity, the annotation contradiction creates significant confusion about whether the operation is destructive. The description does not address this conflict or disclose potential service disruption, making the overall guidance inadequate.

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 fully documents the only parameter (instance_ids) with a clear description. The description adds minimal extra meaning beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb 'Restart' with a clear resource ('one or more running instances by id') and clarifies it is a reboot, not destruction. This clearly distinguishes it from sibling tools like terminate_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?

Explicitly states it applies to 'running instances' and explains that billing continues and instances are not destroyed, which helps an agent decide when a reboot is appropriate versus termination. However, no explicit alternative tool is named.

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

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

The annotations only provide destructiveHint=true, but the description adds crucial behavioral context: permanent destruction, billing stops, non-persistent data destroyed, persistent filesystems survive, and irreversibility. It also includes the REST endpoint, providing an excellent level of transparency beyond the annotation.

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

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

The description is two sentences, front-loaded with the core purpose, and every sentence earns its place: the first states the action and target, the second provides critical side effects and irreversibility. No fluff 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 destructive, single-parameter tool with no output schema, the description covers the key aspects: action, side effects, data persistence, and irreversibility. It lacks an explicit description of the return value, but the REST endpoint hint and overall clarity make it sufficiently complete for an agent to use correctly.

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

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

The schema already fully describes the only parameter (instance_ids) with a clear description. The tool description mentions 'by id' but adds no additional semantic value beyond the schema. Given 100% schema coverage, a baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Terminate (permanently destroy)') and clearly identifies the resource ('one or more instances by id'). It distinguishes itself from sibling tools like restart and launch by emphasizing permanent destruction and irreversibility.

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 clearly conveys when to use it: when you need to permanently destroy instances and stop billing. It implies contrast with restart (temporary) and launch, but does not explicitly mention when not to use or name alternatives, so it falls just short of a 5.

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

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

The description adds the important behavioral detail that only provided fields are changed (partial update), which complements the destructiveHint annotation. It also notes the live instance aspect, implying no restart is needed. 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 convey purpose, behavior, and API endpoint without waste. Front-loaded with the most important 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?

The tool is simple enough with schema and annotations covering the essentials. The description provides the key semantic (partial update) and endpoint context. No output schema exists, but that is not a critical gap for an update tool. It could mention response format, but overall it is complete for selection and invocation.

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

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

Schema coverage is 100%, so parameters are already described. The description adds value by clarifying that only provided fields are changed, which is crucial for understanding id, name, and tags behavior, especially the partial-update semantics for name and tags.

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 ('Update') and the resource ('a live instance's name and/or tags'), which distinguishes it from sibling tools like launch, terminate, or restart. The specific fields are mentioned, making the purpose unambiguous.

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

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

The description implies usage context: updating name/tags on an existing instance, and notes that only provided fields are changed. It does not explicitly contrast with alternatives like launch or restart, but the context is clear enough for an agent to select this tool for modification tasks.

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