Lambda Labs MCP by usefulapi

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

Annotations already declare destructiveHint=true, so the description needn't restate the safety profile. It adds the useful behavioral fact that the filesystem is 'persistent' and confirms the underlying REST operation (POST /api/v1/filesystems), but says nothing about permissions, quotas, or whether region is immutable after creation.

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

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

Two short sentences, zero waste, with the primary action and scope front-loaded before the lifecycle note and endpoint. Nothing to trim.

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

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

For a simple two-parameter creation tool with full schema coverage and no output schema, the description covers purpose, scope, and follow-on use. It stops short of stating the creation result (e.g. an ID to reuse) or any regional constraints, which are minor gaps at this 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?

Schema coverage is 100% and both parameters carry pattern/format details (name regex, region example), so the schema does the heavy lifting. The description adds no parameter-level meaning beyond naming the region concept, which is the baseline-3 case.

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

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

States a specific verb+resource ('Create a new persistent filesystem') with scope ('in a region') and adds what happens next ('can then be attached to instances at launch'). An agent can tell this apart from lambda_delete_filesystem and lambda_list_filesystems without inspecting the schema.

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

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

The workflow hint that the filesystem 'can then be attached to instances at launch' implies when this tool fits in a sequence, but there is no explicit when-to-use/when-not guidance or named alternative. Usage is inferred rather than stated.

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

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

Annotations already declare destructiveHint=true, so the base safety profile is covered, but the description adds genuinely new behavioral context: irreversibility, total data loss, and the attachment precondition that gates the call. It does not say what happens if the precondition is violated or whether the operation is idempotent, leaving a minor gap.

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

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

Three short sentences, front-loaded with the action and escalated to the destructive warning, then the precondition, then the endpoint. No filler and each sentence carries distinct information.

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

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

For a one-parameter destructive tool with no output schema, the description covers what it does, the irreversibility, the precondition, and the backing API route. Nothing an agent needs in order to call it correctly or safely is missing.

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

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

Schema description coverage is 100% for the single 'id' parameter, and the description adds only the phrase 'by id' with no format, prefix, or lookup guidance beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb (Delete) and resource (persistent filesystem) scoped by id, and even names the underlying REST operation. An agent can distinguish this from sibling tools like lambda_list_filesystems or lambda_create_filesystem without opening the schema.

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

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

Gives a concrete precondition for use: the filesystem must not be attached to any instance. It does not name an alternative path (e.g., detach first, or use another tool to check attachment status), so it stops short of full when/when-not/alternatives guidance.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the underlying REST endpoint (useful provenance), but says nothing about error behavior for a missing id, auth requirements, or rate limits. Some added value, not rich.

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

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

Two short sentences, action and identifier first, API mapping second. Zero waste, nothing to trim.

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

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

For a single-resource getter with annotations covering the safety profile, the description is nearly sufficient. It does not describe the returned ruleset shape, but with no output schema that is a minor omission for such a simple lookup.

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

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

Only one parameter and schema coverage is 100%, so the schema fully documents 'id'. The description adds no format or source detail (e.g., where to obtain the id) beyond what the schema provides — the correct baseline of 3.

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

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

States a specific verb ('Get') and resource ('a single firewall ruleset by id'), and the word 'single' implicitly contrasts with the sibling lambda_list_firewall_rulesets. An agent can distinguish it from the list variant without opening the schema.

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

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

Usage is only implied by the word 'single' versus the listing siblings; there is no explicit 'use this when you have an id and need one ruleset' statement, nor any mention of exclusions or alternatives. Adequate but with a clear gap.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable behavioral context by enumerating the returned detail fields (status, ip, region, instance_type, ssh/filesystem attachments, jupyter url, available actions) and naming the underlying REST operation, though it does not cover auth requirements or error 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?

A single front-loaded sentence communicates purpose, key, and return contents, followed by a compact REST endpoint reference. No filler, no repetition, and every clause earns its place.

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

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

With no output schema, the description compensates by enumerating the fields returned, and the readOnly annotation covers the safety dimension. An agent has everything needed to select and invoke this tool correctly for a single-instance lookup.

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 one well-described id parameter, so the schema does the heavy lifting. The description restates 'by id' but adds no syntax, format, or source guidance beyond what the schema already provides, matching the baseline of 3.

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

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

States a specific verb (Get) and resource (a single instance) with a clear lookup key (by id), and the parenthetical enumerates exactly what 'full details' includes. This distinguishes it from sibling list_instances and other get_* tools without requiring schema inspection.

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

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

The description implies usage for retrieving one instance by id, but never explicitly states when to choose this over lambda_list_instances or lambda_list_instance_types, nor any exclusions or prerequisites. Usage is inferable but not 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 only destructiveHint=true in annotations, the description carries real behavioral weight: it warns that billing starts at boot and is hourly per instance_type, and that exactly one SSH key is supported. It does not explain reversibility (that cleanup requires lambda_terminate_instances) or failure modes, so not a 5.

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

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

Three tight sentences, front-loaded with the highest-stakes fact (cost) before the prerequisite sourcing and the endpoint. No filler or repetition of schema 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?

For an 11-parameter, no-output-schema mutation tool, it covers cost, hard prerequisites, and the SSH key constraint well. It omits any pointer to how to observe the launched instance afterward (lambda_get_instance / lambda_list_instances) and doesn't address the image_id/image_family exclusivity left to the schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema lacks: which fields are sourced from lambda_list_instance_types, that only capacity-available regions work, and that ssh_key_names must hold exactly one existing key. It says nothing about quantity/name/tags behavior beyond the schema.

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

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

States a specific verb and resource with scope: 'Launch one or more GPU cloud instances.' It is immediately distinguishable from siblings like lambda_terminate_instances and lambda_restart_instances, and the REST endpoint (POST /api/v1/instance-operations/launch) pins the exact operation.

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

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

Gives concrete preconditions and routes the agent to sibling tools for inputs: region/type must come from lambda_list_instance_types (only regions with capacity), and SSH keys must already exist. It does not state when NOT to use this tool or name an alternative launch path, so it stops short of a 5.

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

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

readOnlyHint=true already tells the agent this is a safe read, and the description is consistent with that. It adds the pagination mechanism ('page_token pagination') and the endpoint mapping, which is genuine operational context, but omits ordering, default page size, and any scoping/permission caveats for audit data.

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

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

Two compact sentences with the purpose front-loaded ahead of filters and pagination. The trailing 'Lambda Cloud REST: GET /api/v1/audit-events' is useful for API-native agents but is arguably redundant metadata rather than task guidance.

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

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

No output schema exists, so the description bears some responsibility for explaining what an audit event contains or how results are ordered/limited, and it does not. Given the tool is a simple read-only list with fully described parameters, it is adequate but not 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 description coverage is 100%, so all four parameters are already documented in the schema, including the ISO 8601 format and example resource types. The description only restates the filter intent, adding no syntax or constraint beyond the schema — the baseline 3 is correct.

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

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

States a specific verb+resource ('List account audit-log events') with scope qualifiers (time window, resource type) and even names the underlying REST endpoint. No sibling tool covers audit events, so it is unambiguously distinguishable from the list_filesystems/list_instances family.

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 via 'optionally filtered by time window and resource type', so an agent can infer that filters are optional. However, it names no alternatives, no when-not conditions, and no prerequisites (e.g. permission scope needed for audit logs).

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating call, so the description's main job is to add context beyond that. It adds the field list and the REST endpoint mapping, but says nothing about pagination, ordering, or what an empty result means.

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

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

Two compact sentences: the purpose and returned fields come first, the REST endpoint reference trails as supporting detail. Nothing is padded or redundant.

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

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

With no output schema, enumerating the returned fields (id, name, region, status, created_at) is the key thing the description must supply, and it does. Minor gaps remain around result size or pagination behavior, but for a zero-parameter list tool this is close to 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 takes zero parameters, so per the baseline there is no parameter semantics to document. The description does not need to compensate for anything here, and the return-field list is a bonus rather than a schema substitute.

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

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

The description gives a specific verb and resource ('List your persistent filesystems') and enumerates the returned fields, so an agent knows exactly what it gets back. It distinguishes itself implicitly from the create/delete filesystem siblings by being the read-only enumeration, though it never names an alternative tool.

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

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

The clause 'that can be attached to instances at launch' hints at the use case (call before launching an instance), but there is no explicit when-to-use or when-not-to-use guidance and no reference to sibling tools. Usage is only inferable.

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 readOnlyHint annotation already establishes this as a safe read. The description adds worthwhile behavioral context by naming the returned field set (protocol, port range, source CIDR, description) and the underlying REST call, but says nothing about ordering, volume, or pagination 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?

A single front-loaded sentence carries the purpose and returned fields, followed by the API endpoint as compact supporting metadata. No sentence is wasted.

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

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

With no output schema, the description usefully compensates by enumerating the returned attributes. It is nearly complete for a no-arg read tool, with only minor gaps around result size or pagination.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate; the zero-parameter baseline of 4 applies. The field list describes the output rather than inputs, which is a reasonable substitute given the empty schema.

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

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

States a specific verb ('List') and resource ('account's inbound firewall rules') with the returned fields enumerated, so the agent knows exactly what comes back. The distinct resource name separates it from lambda_list_firewall_rulesets and lambda_get_firewall_ruleset, but the description never explicitly contrasts them.

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

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

Usage is implied by the resource itself ('the account's inbound rules') but there is no explicit when-to-use statement, no note on when to prefer lambda_list_firewall_rulesets or lambda_get_firewall_ruleset, and no mention of prerequisites or pagination for large rule sets.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read. The description adds useful context by naming the fields returned and the REST endpoint, but says nothing about pagination, filtering, or auth requirements, so it adds moderate value over the annotations without being rich.

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

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

Two compact sentences with the scope front-loaded and the REST endpoint trailing as supporting metadata. Nothing is redundant or padded.

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

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

With no output schema and no parameters, the description carries the return-shape burden and discharges it by listing id, name, region, and rules. For a simple read-only list this is nearly complete, missing only pagination/ordering behavior and auth prerequisites.

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

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

The tool takes zero parameters, which is the baseline-4 case: there is no parameter semantics to convey and the description correctly does not invent any. The enumerated return fields serve as the only meaningful contract detail available.

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

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

The description gives a specific verb and resource ('List firewall rulesets') and enumerates the returned fields (id, name, region, rules), plus the underlying REST call. It never names a sibling to distinguish itself from, so it falls just short of the top band despite being unambiguous about what it returns.

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

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

Usage is only implied by the phrase 'that can be applied to instances' – an agent can infer this is the lookup step before attaching a ruleset to an instance, but there is no explicit when-to-use, no exclusion, and no pointer to lambda_get_firewall_ruleset or lambda_create_filesystem as alternatives.

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

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

The readOnlyHint=true annotation already establishes that this is a safe read operation. The description adds value beyond that by specifying the returned fields and the underlying REST endpoint (GET /api/v1/images), which partially compensates for the absence of an output schema. It does not cover pagination or ordering, but for a read-only list this is solid.

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 tightly written sentence covering purpose, return contents, usage context, and endpoint. There is no filler, and the most important information (what it lists) is front-loaded.

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

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

For a zero-parameter, read-only list tool with no output schema, the description supplies the returned field names and the operational context, which is everything an agent needs to select and invoke it correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to document beyond confirming there is no input. The baseline for a parameterless tool is 4.

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

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

The description gives a specific verb ('List') and resource ('available machine images') and enumerates the returned fields (id, name, family, version, region availability). It also states the operational context ('that can be selected when launching an instance'), making it easy to distinguish from siblings like lambda_list_instance_types or lambda_list_instances.

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

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

The phrase 'that can be selected when launching an instance' clearly signals when an agent should call this tool (as a precursor to lambda_launch_instance). There are no explicit exclusions or named alternatives, but the context is unambiguous for a zero-parameter list tool.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description's useful additions are the returned field set and the underlying REST endpoint. It does not address pagination, result limits, or whether non-running instances are excluded, which is real behavioral context for a list endpoint.

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

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

Two compact sentences, with the purpose and returned fields front-loaded and the API reference trailing as supporting detail. No filler.

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

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

With no output schema, the description compensates by listing the returned fields, which is exactly the information an agent needs. It stops short of covering pagination behavior or state filtering, so it is strong but not fully complete.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify beyond the schema. Baseline 4 applies; no parameter meaning is missing because no parameters exist.

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

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

States a specific verb+resource ('List your running GPU cloud instances') and enumerates the returned fields, so the scope is unambiguous. It does not explicitly distinguish itself from the sibling lambda_get_instance, so it stops short of a 5.

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

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

The description gives no when-to-use guidance, no exclusions, and never names the alternative lambda_get_instance for fetching a single instance. The word 'running' hints at a filter but the agent must infer when this list tool is preferred over its siblings.

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

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

readOnlyHint=true already establishes the safe-read profile, and the description adds genuinely new context: the exact fields returned and the capacity-availability information. It also names the underlying REST endpoint, which helps an agent reason about behavior. It stops short of discussing staleness or caching of capacity data.

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 tightly packed sentences plus an endpoint reference, all front-loaded. The returned-field list is dense but each item earns its place by helping pre-launch selection.

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

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

With no output schema, the description carries the burden of explaining returns, and it does so by enumerating the key fields and the capacity/region information. Combined with the usage hint, an agent has everything needed to call and interpret this tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly implies no arguments are needed.

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

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

States a specific verb and resource ('List all GPU instance types') and enumerates the payload (vcpus, memory, storage, gpus, price_cents_per_hour, regions with capacity). It is easily distinguished from siblings like lambda_launch_instance and lambda_get_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?

Explicitly says 'Use this to pick region_name + instance_type_name before launching', giving a clear triggering context. No explicit exclusions or negative cases, but the pre-launch workflow is unambiguous.

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

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

Annotations only carry destructiveHint=true, so the description meaningfully adds that this is a reboot rather than a destruction and that billing continues — exactly the facts an agent needs to avoid misclassifying it as a delete. It stops short of disclosing downtime, whether in-memory/ephemeral state is lost, or auth requirements, so it is strong but not complete.

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

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

One sentence plus endpoint reference, with the operation and its non-destructive nature front-loaded. Every clause earns its place and nothing is padded.

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

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

For a one-parameter operation with no output schema, the description supplies the action semantics, target scope, and the key non-destruction/billing behavior. It omits what the response looks like and error conditions (e.g. restarting a non-running instance), which are the only remaining 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?

With 100% schema description coverage on a single well-documented array parameter (minItems 1, 'Ids of the instances to restart'), the schema already does the work. The description's 'one or more ... by id' roughly restates that, adding no syntax or formatting detail beyond the structured field.

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

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

States a specific verb and resource ('Restart one or more running instances'), plus the scoping constraint ('by id') and the exact API endpoint. The parenthetical 'a reboot — the instances are NOT destroyed and billing continues' cleanly separates this operation from the destructive sibling lambda_terminate_instances without naming it.

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

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

Usage is only implied: 'running instances' conveys the precondition that the target must be in a running state, and 'one or more' conveys batching. There is no explicit when-to-use/when-not guidance and no alternative tool is named (e.g. terminate_instances or update_instance), leaving the agent to infer selection from the name alone.

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

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

Annotations only flag destructiveHint=true; the description goes well beyond by disclosing the exact blast radius — billing stops, non-persistent data is destroyed, persistent filesystems survive, and the action is irreversible. It also names the underlying REST endpoint, all of which materially affects how an agent should reason about invoking it.

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

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

Three short sentences, front-loaded with the verb and the most important consequence (destruction), with no filler. Every sentence carries decision-relevant 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 single-parameter destructive tool with no output schema, the description covers the operation, its consequences, data persistence caveats and reversibility. Nothing an agent needs in order to call it safely is missing.

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

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

Schema coverage is 100% for the single instance_ids parameter, so the schema already documents format, array type and minItems. The description adds only the obvious 'by id' and no batching or id-format detail, so baseline 3 applies.

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

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

States a specific verb (terminate/permanently destroy) and resource (instances by id), and the parenthetical clarifies the semantics of 'terminate' versus a softer stop. It is clearly distinguishable from siblings like lambda_restart_instances or lambda_update_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 irreversibility warning implies this should be a last resort, but the description never states when to use this instead of an alternative such as restart_instances, nor any precondition (e.g., confirm the instance id first). Usage is implied rather than 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?

The annotation destructiveHint=true already flags the mutation risk, so the bar is lower. The description adds useful behavioral context in 'Only provided fields are changed', clarifying this is a partial update rather than a full overwrite. It does not, however, explain what makes the operation destructive (the tags parameter replaces the entire tag set, per the schema), nor does it mention permissions or reversibility.

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

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

Three short, front-loaded sentences with no padding: purpose, partial-update behavior, then the underlying REST endpoint. The endpoint reference is mildly redundant for tool-invocation purposes but is plausibly useful for an API-aware agent, so only a minor deduction.

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 three-parameter mutation tool with no output schema and only a destructiveHint annotation, the description is adequate but not complete: it omits that the tags parameter replaces (rather than merges) existing tags, says nothing about required permissions, and does not describe the response, so an agent must infer the destructive scope from the schema.

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

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

Schema description coverage is 100%, so the schema already documents id, name (max 64 chars), and the tags replacement semantics, making the baseline 3 appropriate. The description only restates the mutable fields and adds no format or syntax detail beyond what the schema provides.

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

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

States a specific verb (update) and resource (a live instance) plus the exact mutable fields (name and/or tags), which cleanly separates it from read-oriented siblings like lambda_get_instance and lifecycle siblings like lambda_restart_instances and lambda_terminate_instances. The only gap is that it does not name a competing sibling as an explicit alternative.

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

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

'Update a live instance's name and/or tags' plus 'Only provided fields are changed' implies when the tool is applicable and signals partial-update semantics, which is genuine guidance. However, it states no prerequisites, no permissions requirements, and no when-not-to-use conditions relative to alternatives, so usage is only implied.

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