Google Compute Engine

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

Annotations already indicate this is a write operation (readOnlyHint=false) with destructive potential (destructiveHint=true). The description adds useful behavioral context by explaining the asynchronous operation monitoring: check for errors and wait for status DONE, and use get_zone_operation for details. It also reveals default image and machine type behavior, which is not discoverable from the schema alone. It does not contradict 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 efficiently structured: purpose first, then requirements, defaults, optional parameters, and finally success criteria. It is somewhat long, and the phrase 'without any errors' is redundant, but every sentence contributes actionable information. The front-loaded purpose makes it easy to scan quickly.

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 rich annotations, complete schema coverage, and the presence of an output schema, the description covers essential operational details: prerequisites, default values, optional configuration, and how to verify a successful operation via get_zone_operation. No critical information is missing for an agent to safely invoke the 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 coverage is 100%, so the schema documents all parameters, but the description adds value by specifying defaults for machineType and imageProject/imageFamily, and by naming guestAccelerators and maintenancePolicy as optional. It uses slightly different parameter names ('guest_accelerator' vs 'guestAccelerators'), which is a minor inconsistency, but the overall meaning is still conveyed.

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

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

The description opens with a specific verb and resource: 'Create a new Google Compute Engine virtual machine (VM) instance.' This clearly distinguishes create_instance from sibling tools like delete_instance, reset_instance, or start_instance. It also lists required parameters, making the tool's scope immediately obvious.

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 practical context: required inputs (project, zone, name), default machine type and image, and optional parameters. It also instructs the agent to check the operation status and references get_zone_operation. It does not explicitly state exclusions or when to prefer alternatives, but the create/delete/update sibling set makes the use case 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?

The description adds behavioral context beyond the annotations: it reveals that deletion is asynchronous and advises verifying the operation's completion and status. This is valuable information not present in the destructiveHint or other annotations, which only flag the destructive nature.

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 long, with the purpose stated upfront and each subsequent sentence adding necessary operational guidance. There is no redundant or filler content, making it highly efficient.

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

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

The description covers the essential operational aspects: the destructive nature (supported by annotations), the asynchronous behavior, and the verification step. It references a related tool for follow-up, which is helpful. Given the output schema exists, the description does not need to detail return values, and it sufficiently addresses 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?

Schema description coverage is 100%, so the input schema already fully documents each parameter. The description only restates the required inputs without providing additional semantic details or context beyond what the schema already contains.

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 ('Delete') and the resource ('Google Compute Engine virtual machine (VM) instance'), making the tool's purpose unambiguous. It is distinguished from sibling tools like start_instance, stop_instance, and reset_instance, which perform different lifecycle operations.

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

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

The description provides usage guidance by instructing the agent to check the operation status and proceed only when the response is error-free with DONE status. It also points to get_zone_operation as an alternative for retrieving operation details. However, it does not explicitly state when not to use delete or compare it with other destructive operations.

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, idempotentHint, and destructiveHint, covering the safety profile. The description adds the specific field list returned, which gives some behavioral context, but does not disclose error behavior or other side effects. No contradictions with annotations.

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

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

Two sentences with a clear, front-loaded action and succinct detail. No filler or redundant phrasing. The description efficiently conveys purpose and key inputs.

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 operation with a complete input schema and an output schema present, the description is sufficiently complete. It could mention when to use list_commitments to discover names, but that is not essential given the tool's straightforward nature.

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 baseline is 3. The description merely restates that project, region, and name are required, adding no format, type, or constraint information beyond what the schema already provides.

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

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

The description clearly identifies the verb ('Get'), the resource ('Compute Engine Commitment'), and the scope ('basic information'). It also specificies key fields returned (name, ID, status, plan, type, resources, timestamps), distinguishing it from sibling list or detail 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 description states the required inputs (project, region, name) but does not explicitly say when to use this tool instead of alternatives like list_commitments or other get_basic_info tools. Usage is implied but not contrasted with other options.

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, idempotentHint=true, and destructiveHint=false, so safety is clear. The description adds behavioral context by enumerating the exact fields returned (creation timestamp, last attach/detach timestamps), which goes beyond the schema and helps the agent understand the tool's output scope.

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, front-loaded with the core purpose, then a list of returned fields and required inputs. Every sentence contributes value with no repetition 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?

This is a simple read-only tool with 3 required params and an output schema. The description fully covers what it does, what it returns, and what inputs are needed. No additional context is necessary for a tool of 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 description coverage is 100%, with each parameter (project, zone, name) already described. The description merely restates 'Requires project, zone, and disk name' without adding new semantic details like formats, constraints, or relationships, so it does not surpass the schema baseline.

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

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

The description clearly states the tool's function: 'Get basic information about a Compute Engine disk' with a specific verb and resource. It lists concrete fields returned (name, ID, description, timestamps, size, type, status), distinguishing it from siblings like get_disk_performance_config or list_disks.

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 stating required inputs (project, zone, disk name) but provides no explicit guidance on when to use this tool versus alternatives like get_disk_performance_config or list_disks. No exclusions or alternative recommendations are given, making usage context 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by listing the specific performance fields returned, which gives the agent a concrete sense of the tool's output scope beyond the generic 'Get' operation.

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

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

The description is a single, well-structured sentence that front-loads the action and lists key details. No wasted words or redundant information beyond the necessary scope.

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 get operation, clear annotations, and an existing output schema, the description fully covers the tool's purpose and requirements. There is no missing information about return values or prerequisites beyond what structured data already provides.

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

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

Schema coverage is 100% with descriptions for all three parameters (project, zone, name). The description only repeats that these inputs are required without adding semantic detail beyond the schema, so the baseline 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 'Get performance configuration of a Compute Engine disk' and enumerates the specific attributes returned (type, size, IOPS, throughput, block size, storage pool, access mode). This distinguishes it from sibling tools like get_disk_basic_info, which covers basic disk 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 indicating it returns performance configuration, but it does not explicitly state when to use this tool versus alternatives such as get_disk_basic_info. No exclusions or alternative references 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by explicitly listing the returned attributes and noting the required inputs, giving the agent a clear expectation of output without contradicting 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 well-structured sentences: the first states the purpose and output fields, the second lists required inputs. No redundant filler or unnecessary detail.

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 getter with a comprehensive output schema and full parameter coverage, the description is sufficient. It communicates what the tool returns and what inputs are needed, without needing to explain return values since the output schema exists.

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

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

Schema coverage is 100%, with each parameter (project, zone, name) already described. The description only restates that these three inputs are required, adding no deeper semantic meaning beyond the schema. Baseline 3 applies due to 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 tool gets basic information about a specific Compute Engine VM instance, enumerating the fields returned (name, ID, status, machine type, creation timestamp, guest accelerators). This distinguishes it from sibling tools targeting other resource types like disks or templates, and from 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?

Usage context is implied: it requires project, zone, and instance name to fetch a single instance's basic info. However, the description provides no explicit guidance on when to choose this over alternatives (e.g., list_instances for multiple VMs, or other get_* tools for different resources).

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral traits beyond listing return fields, which is partially covered by the output schema. This is adequate but not highly informative.

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, information-dense sentence that front-loads the main action and resource. It lists the output fields without unnecessary words, making it concise and well-structured.

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, presence of an output schema, and comprehensive annotations, the description is complete. It provides enough context for an agent to select and invoke the tool correctly without needing additional details about return values or side effects.

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 all three parameters, and each parameter has a meaningful description. The tool description only restates that project, zone, and name are required, adding no extra semantics 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 the tool's purpose: to get basic information about a Compute Engine managed instance group (MIG). It lists specific fields returned, distinguishing it from sibling tools that target other resources like instances, templates, or disks.

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: it is for retrieving basic MIG details. It also specifies required inputs (project, zone, name), but it does not explicitly contrast with alternative tools or state when not to use 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the list of returned fields and input requirements, which is helpful but not extensive behavioral context. It does not describe auth needs, error cases, or pagination, but the output schema mitigates the need for return-format 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 two succinct sentences, front-loading the action and resource, then listing key fields and input requirements. No filler 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 simple read-only getter with detailed annotations and an output schema, the description adequately covers purpose, inputs, and output content. It could have explicitly differentiated from get_instance_template_properties, but the 'basic info' framing provides sufficient context for correct selection.

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 (project, name) are already documented in the schema. The description simply restates that project and name are required, adding no deeper semantic meaning beyond what the schema provides.

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

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

The description clearly states the verb ('Get') and resource ('Compute Engine instance template'), and enumerates the specific fields returned (name, ID, description, machine type, region, creation timestamp). This distinguishes it from sibling tools like get_instance_template_properties by focusing on 'basic information'.

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 states required inputs (project and instance template name) and implies this is the tool for retrieving basic template info. However, it does not explicitly mention when to choose this over get_instance_template_properties or list_instance_templates, so usage guidance is implied rather than 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the list of returned properties, which gives a sense of the response content but does not disclose additional behavioral traits like pagination or error handling. It does not contradict 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 concise: two sentences. The first delivers the core purpose, and the second enumerates the property list, which is valuable for understanding the tool's scope. No superfluous words or repeated schema information.

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

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

Given the existence of an output schema and the simple two-parameter input, the description is largely complete—it explains what the tool returns by enumerating property categories and states the required inputs. It falls short only in not addressing when to use this over the sibling 'basic info' variant, but that gap is covered under usage guidelines.

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

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

The schema covers 100% of parameters with descriptions for 'project' and 'name'. The description merely restates that these are required, adding no extra semantics or details beyond what the schema already provides. Thus, it meets the baseline for good schema coverage but does not elevate 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 gets instance properties of a Compute Engine instance template, with a specific verb and resource. It enumerates the exact property categories included (description, tags, machine type, etc.), which distinguishes it from sibling tools like get_instance_template_basic_info that likely return only a summary.

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 retrieving detailed properties, but it does not explicitly compare with alternatives or state when to choose this over get_instance_template_basic_info. It mentions the required inputs (project and template name), which is a usage requirement, but offers no exclusionary 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by specifying the exact set of returned fields, which is beyond what the input schema shows. No contradiction exists.

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 front-load the purpose and immediately list required inputs and returned fields. No wasted words or redundant 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 read-only lookup tool with rich annotations and an output schema, the description fully captures the tool's purpose, required inputs, and the content of the response. No additional behavioral details are necessary.

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%, and the description simply lists the required parameters (project, zone, name) without adding formats, constraints, or other semantic details that the schema does not already provide. 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 the tool 'Get Compute Engine reservation basic info' and enumerates the specific fields returned (name, ID, creation timestamp, zone, status, specific reservation required, commitment, and linked commitments). This is a specific verb+resource+scope that distinguishes it from sibling tools like get_reservation_details.

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 by stating that it returns basic reservation info and requires project, zone, and name. However, it does not explicitly mention alternative tools or provide when-to-use versus what-not-to-use guidance relative to get_reservation_details.

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

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

Annotations already cover readonly/idempotent/non-destructive behavior, so the bar is lower. The description adds context about the breadth of returned data (specific vs. aggregate properties, commitments, sharing settings), giving insight into the tool's behavior without contradicting 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 moderately sized with purposeful detail. The list of returned properties is long but relevant, helping differentiate from basic info tool. It is front-loaded with the main purpose, and the requirement sentence is clear. Slight redundancy exists with the schema's field names.

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

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

Given the output schema exists and annotations cover safety, the description provides sufficient context: it states what the tool does, the key inputs, and the scope of returned details. It is complete enough for an agent to select and invoke correctly, though it could be more explicit about when to choose this over sibling tools.

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 has 100% parameter description coverage for all three required fields (project, zone, name). The description merely restates that these inputs are required, adding no new semantic meaning 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 the tool's purpose: to get Compute Engine reservation details. It enumerates the specific properties returned (e.g., machine type, guest accelerators, local SSDs, commitment, sharing settings), distinguishing it as the comprehensive counterpart to sibling 'get_reservation_basic_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 provides clear context on what details are returned, implying when to use this tool for full reservation details. However, it does not explicitly name alternatives or state 'use this when' vs. other reservation-related tools, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds transparency by listing exactly what data will be returned (id, name, status, errors) and the required input parameters. This goes beyond the minimal annotation coverage, though it does not mention permissions or rate limits.

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

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

The description is two well-structured sentences. The first sentence states the action and return values, and the second lists input requirements. No unnecessary words or repetition of schema details.

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 3-parameter get operation with full schema coverage, comprehensive annotations, and an output schema, the description is complete. It accurately conveys what the tool does, what it returns, and what it requires, without needing additional behavioral caveats.

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 each parameter (project, zone, name) having a clear description in the input schema. The description merely reiterates that these inputs are required without adding new semantic detail. The schema carries the full burden, so 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 clearly states the tool's purpose: 'Get details of a zone operation' and enumerates the specific fields returned (id, name, status, creation timestamp, error, etc.). This specific verb+resource combination distinguishes it from sibling tools like list_instances or get_instance_basic_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 for retrieving a single zone operation by explicitly requiring project, zone, and operation name. However, it does not provide explicit guidance on when to choose this tool over alternatives (e.g., listing operations) or mention any exclusions. Usage context is implied but not 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 readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the tool's safety profile is known. The description adds value by specifying the required inputs (project, zone) and the return fields (id, creation timestamp, name, etc.), offering useful context beyond 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 two short sentences, front-loaded with the primary purpose, and includes essential details without any redundant filler. Every word contributes to understanding the tool's function.

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 purpose, required inputs, and return information for this simple list operation. An output schema exists, so return values are also structurally defined, making the tool 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?

Schema description coverage is 100%, with both 'project' and 'zone' already described in the input schema. The description only restates that project and zone are required, adding no new meaning beyond what the schema already provides. This matches 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?

The description clearly states the tool's purpose with a specific verb ('Lists') and resource ('Google Compute Engine accelerator types'). It also distinguishes itself from sibling tools like list_machine_types by focusing on accelerator types, making it 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 when to use the tool (when listing accelerator types in a specific project/zone) but provides no explicit guidance on alternatives or when not to use it. It does not mention sibling tools or exclusions, so the 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 declare read-only and idempotent behavior. The description adds value by detailing the return content (reservation details, properties, sharing settings, etc.) and required inputs, which helps the agent understand what to expect without conflicting with annotations.

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

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

The first sentence is concise and front-loads the purpose. The second sentence lists many return properties, which is informative but slightly lengthy. Overall, the description is well-structured 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?

For a read-only list operation with an output schema and comprehensive annotations, the description is adequate. It covers the tool's scope and key output details without needing to explain return values in depth, as the output schema handles that.

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 description coverage is 100%, with each parameter clearly described. The description merely restates that project, region, and commitment name are required, adding no new semantic meaning beyond what the schema already provides.

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

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

The description clearly states the tool lists reservations for a specific Compute Engine Commitment, using a specific verb and resource. It distinguishes itself from sibling tools like list_reservations (which lists all reservations) and list_commitments (which lists commitments) by focusing on a commitment's reservations.

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 by requiring project, region, and commitment name, indicating it's for a specific commitment. However, it does not explicitly compare with alternatives or state when not to use other list tools, leaving the guidance somewhat implicit.

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, idempotentHint, and destructiveHint, so the safety profile is well covered. The description adds value by detailing the exact output fields (name, ID, status, plan, type, resources, timestamps) and specifying required inputs. It does not reveal all behavior (e.g., pagination), but the annotations lower the burden.

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 long with no redundant phrasing. It front-loads the core purpose and includes only necessary details. Every sentence adds value: the first states what the tool lists, the second details the output and required inputs.

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, the description provides all essential context: the resource, scope, required inputs, and output fields. The output schema exists and covers return values, and annotations cover safety. Pagination behavior is inferable from the schema. This is complete for an agent to select and invoke the 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 100%, so the schema already documents all parameters. The description mentions 'Requires project and region as input,' which aligns with the required fields but adds no new meaning beyond the schema. Optional parameters (pageSize, pageToken) are not discussed, but the schema covers them.

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 ('Lists'), the resource ('Compute Engine Commitments'), and the scope ('in a region'). It also enumerates the fields returned, which further clarifies what this tool does. This distinguishes it from sibling tools like list_commitment_reservations and get_commitment_basic_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 states that project and region are required inputs, providing clear usage context. However, it does not explicitly mention when to use this tool over alternatives, such as list_commitment_reservations or get_commitment_basic_info. There is no guidance on exclusions or alternative 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 readOnly and idempotent behavior. Description adds return field details and required inputs (project, zone), which is useful but does not disclose pagination behavior or zonal scoping beyond the input parameter.

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, front-loaded with action and resource, no redundant information.

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

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

Given output schema exists and annotations cover safety, description adequately covers purpose and prerequisites. Minor gap: zonal scope not explicitly stated beyond the zone parameter.

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 description adds minimal parameter context beyond restating required inputs. Baseline of 3 applies since schema handles parameter documentation.

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 specific verb 'Lists' with resource 'Compute Engine disks' and enumerates returned fields. It clearly distinguishes from sibling tools like get_disk_basic_info (single disk) and list_instance_attached_disks (instance scoped).

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 explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of exclusions or alternative tools for different disk listing needs.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the requirement for a project and enumerates the returned fields, which is useful but not substantially beyond what annotations and output schema already imply. No contradictory behavior is disclosed.

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 primary action, and every sentence adds value. The first sentence states the purpose, the second provides output details and the key input requirement. No unnecessary words.

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

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

For a simple list tool with strong annotations, a complete input schema, and an output schema, the description provides an adequate overview. It covers the resource, output fields, and required input. The lack of usage guidance is a separate dimension and does not make the description incomplete for this simple 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 100%, so the schema already documents all parameters. The description's mention of requiring a project only repeats the schema's required field. It does not add new semantic meaning to pageSize or pageToken beyond what the schema provides.

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

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

The description clearly states the action ('Lists') and the resource ('Compute Engine Images'), and provides specific detail about the fields included (name, ID, status, family, creation timestamp). This distinguishes it from sibling list tools like list_disks and 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 description does not provide guidance on when to use this tool versus alternatives. It only notes that a project is required, which is a prerequisite rather than usage context. No exclusions or alternative tool recommendations are given.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the operation is known to be safe. The description adds the list of response fields and the input requirements, which provides some behavioral context but does not go beyond what annotations imply about side effects or require additional disclosure.

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

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

The description is front-loaded with a clear purpose statement, followed by the detailed field list and input requirements. The list of fields is somewhat verbose but provides transparency and the structure is logical.

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?

Since an output schema exists, the description need not explain return values. The tool is a simple read-only list operation, and the description covers the scope and required parameters sufficiently. Without an explicit note on pagination, it is still complete for most 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 coverage is 100% and every parameter has a description, so the structured schema already supplies the meaning. The description repeats that project, zone, and name are required, adding no extra semantics beyond the schema.

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

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

The description uses the specific verb 'Lists' and clearly identifies the resource as disks attached to a specific Compute Engine VM instance. This naturally distinguishes it from sibling tools like list_disks (which likely lists project-level disks) and list_instances (which lists 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 states that project, zone, and instance name are required as input, which clarifies the context for use. However, it does not explicitly mention when to prefer this over list_disks or other alternatives, but the scoped purpose is clear enough.

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

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

Annotations already disclose readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the return fields and required inputs, but does not disclose additional behavioral aspects like pagination limits or error cases. No contradiction with annotations exists.

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 composed of two tight sentences, front-loaded with the main action, and contains no redundant information. Every sentence contributes to understanding the tool's function and inputs.

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 and strong annotations, the description provides adequate context for a straightforward list operation. It identifies the resource, return fields, and required inputs, though it omits discussion of pagination or cross-zone limitations. These are minor gaps for a simple 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 100% for all four parameters, so the description does not need to elaborate on them. The description only repeats that project and zone are required, adding no further semantic nuance 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 the tool lists Compute Engine managed instance groups (MIGs) and enumerates the details returned, such as name, ID, and status. It is specific about the resource and action, but does not explicitly differentiate from sibling tools like list_managed_instances, which lists instances within a group.

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 its usage for listing MIGs and mentions required project and zone inputs. However, it offers no guidance on when to prefer this tool over alternatives, such as list_managed_instances for individual instances, nor does it specify limitations like zone-scoped listings.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the returned fields and notes the requirement for project and zone, but these are largely redundant with the schema. It hints at the tool's limited scope without explicit behavioral nuance.

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, front-loaded with the core purpose, and every sentence provides value: what the tool does, what fields are returned, and how to use it. There is no fluff or repetitive text.

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

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

Given the output schema and strong annotations, the description covers the essential purpose, returned fields, and required inputs. It does not explicitly differentiate from list_managed_instances or mention pagination, but those are largely addressed by the schema and tool naming. A minor gap exists in not clarifying zone-scoped listing beyond the required parameter.

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

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

Schema coverage is 100% with descriptive entries for all four parameters. The description only restates that project and zone are required, adding no new meaning beyond what the schema already provides. Baseline 3 is appropriate given 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 'Lists Compute Engine virtual machine (VM) instances' and enumerates the exact fields returned, which distinguishes it from sibling list tools for disks, images, machine types, etc. The verb-resource pairing is immediate and 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?

'Use other tools to get more details about each instance' explicitly signals that this tool provides basic info and is not for deep investigation. However, it does not name specific alternative tools like get_instance_basic_info or list_managed_instances, so the guidance is useful but not exhaustive.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by specifying the output fields (name, ID, description, machine type, region, creation timestamp) and the required project input, going beyond what annotations provide.

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, with three short sentences that front-load the main action, list returned details, and state the required input. Every sentence 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?

Given the tool's simplicity, the existing annotations, and the presence of an output schema, the description is sufficiently complete. It covers the tool's purpose, output contents, and required input, leaving no major gaps for an agent to misunderstand.

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 fully documents project, pageSize, and pageToken. The description only repeats that project is required, adding no new meaning beyond the schema. Therefore, 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 verb 'Lists' and the resource 'Compute Engine instance templates', and mentions the details returned. It distinguishes from sibling tools like get_instance_template_basic_info by indicating a list operation rather than a single-resource fetch.

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: this tool lists instance templates and requires a project. However, it does not explicitly mention when to use this tool versus alternatives like get_instance_template_basic_info, so it misses explicit 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the scope qualifier 'available' and enumerates returned fields, but does not disclose deeper behavioral traits such as pagination, result limits, or ordering. This is consistent with the calibration example where annotations cover safety and description adds modest value.

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 its purpose in the first sentence and remains compact overall. However, the exhaustive field enumeration ('id, creationTimestamp, name, description, guest cpus, memory...') is somewhat redundant given the output schema exists, and it contains a minor typo ('persisten'). Still, every sentence earns its place.

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

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

For a simple read-only list tool, the description is adequate: it covers purpose, prerequisites, and return content. The output schema handles return value structure, and annotations cover the safety profile. Minor gaps include no mention of pagination or result size, but these are not critical given the tool's simplicity.

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

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

Schema description coverage is 100%, with both project and zone already described in the schema. The description only restates 'Requires project and zone as input' and does not add meaning beyond the schema. Baseline 3 applies because the schema carries the full parameter documentation burden.

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

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

The description opens with 'Lists the available Google Compute Engine machine types,' which is a specific verb+resource statement. It clearly distinguishes this tool from sibling list tools (list_disks, list_images, list_instances) by naming the exact GCE resource being listed.

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 states the required inputs ('Requires project and zone as input'), which provides some invocation context. However, it offers no explicit when-to-use vs when-not-to-use guidance or references to alternatives among the many sibling list_* tools, so usage is only implied by the purpose statement.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description's job is lighter. It adds valuable behavioral context by enumerating the details returned (id, instance URL, status, current action) and confirming the MIG scope.

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 verb and resource, with no wasted words. It states scope, returned details, and required inputs efficiently.

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 annotations, full schema coverage, and an existing output schema, the description is mostly complete. It could mention pagination behavior, but the pageSize/pageToken schema descriptions already hint at that, and the core purpose is clear.

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

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

The schema descriptions cover 100% of parameters, so the baseline is 3. The description repeats the required inputs but adds no semantics beyond the schema, such as pagination behavior or parameter value formats.

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 'Lists' with a clear resource: 'managed instances for a given managed instance group (MIG)'. It distinguishes this from siblings like list_instances by scoping to a MIG, and even notes the key fields returned.

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 states the required inputs (project, zone, MIG name), which implies the context of use. However, it does not explicitly contrast with alternatives like list_instances or list_instance_group_managers, so guidance on when to choose this tool over siblings is only implicit.

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, idempotentHint, and destructiveHint false, covering the safety profile. The description adds the required inputs and the fields returned, but does not disclose additional behavioral traits like pagination, rate limits, or permissions. It does not contradict 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 brief and front-loaded with the main action. The final sentence about requiring project and zone is redundant with the schema, but the overall structure is clean and efficient.

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

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

For a read-only list operation with a rich output schema, the description adequately explains what the tool does and the scope. It could better distinguish itself from sibling tools like get_reservation_details, but the core functionality is sufficiently covered.

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 provides full descriptions for all four parameters, including required project and zone. The description only repeats that project and zone are required, adding no new semantic meaning. Baseline of 3 is appropriate given 100% 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 'Lists Compute Engine reservations' with a specific verb and resource. It further enumerates the details included, distinguishing it from a generic list operation. This is unambiguous and differentiates from sibling tools like get_reservation_basic_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 when you need to list reservations in a given project and zone, but it does not mention alternatives or when to prefer other tools such as get_reservation_basic_info or list_commitment_reservations. No explicit exclusions or conditions 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 already establish readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds which fields are returned but does not disclose pagination behavior or other edge cases. With annotations covering the safety profile, a 3 is appropriate.

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

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

The description is a single sentence that efficiently conveys scope and output fields without unnecessary words. It is well-structured and front-loaded.

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

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

The tool is a straightforward list operation with pagination parameters already described in the schema, and an output schema is present. The description covers the essential purpose and required input, but it does not mention pagination behavior; however, that is adequately covered by the schema and output schema. Thus it is complete enough for the complexity, scoring a 4.

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

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

Schema coverage is 100%, with descriptions for project, pageSize, and pageToken. The description only reiterates the project requirement redundantly and does not add extra meaning to the parameters. 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?

The description clearly states the action (Lists snapshots) and the resource (in a project), and it enumerates the specific fields returned, distinguishing it from sibling list tools like list_disks or list_images. It uses a specific verb and resource, so it scores 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 implies usage when snapshot listing is needed, and it mentions the required project input. However, it does not explicitly state alternatives or exclusion criteria, though the context is clear from the sibling tools and name. The context is clear and no exclusions are stated, 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?

The description adds behavioral context beyond the annotations by explaining that the operation response must be checked for errors and `DONE` status, and it references get_zone_operation for details. This reveals the asynchronous nature of the operation, which is not apparent from the annotations alone.

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 relatively concise and front-loads the primary purpose. The second and third sentences are somewhat redundant or verbose, but overall it is well-structured and not overly long.

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 reset operation with a full output schema and annotations, the description covers the core action and the important caveat about checking the operation status. It does not mention prerequisites or detailed effects, but these are adequately handled by the schema/annotations and the tool's simplicity.

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

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

The input schema already covers all three parameters with 100% description coverage, so the baseline is 3. The description simply repeats that project, zone, and instance name are required without adding any new parameter-specific 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 states the specific action ('Resets a Google Compute Engine virtual machine (VM) instance') and clearly identifies the resource. This distinguishes it from sibling tools like start_instance, stop_instance, and delete_instance.

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

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

The description implies the tool is used to reset a VM and provides a caution about checking operation status, but it does not explicitly state when to use this tool versus alternatives like start/stop/delete. It offers a complementary pointer to get_zone_operation but no exclusionary 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?

The description adds behavioral context beyond the annotations: it requires a stopped instance, and it emphasizes waiting for a successful operation status before proceeding. It also points to get_zone_operation for operation details, which helps manage expectations. The destructiveHint annotation is consistent with the mutation described.

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 and front-loads the core purpose. The second sentence, though a bit wordy, is still under control and provides necessary operational guidance. It is concise and without 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 tool's mutation nature, an output schema exists, and annotations are present, the description provides enough context. It includes the key precondition (stopped instance), the operation status check, and a pointer to get_zone_operation. It doesn't describe return values (not needed since output schema exists), but it covers the critical operation flow.

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 describes all four parameters with 100% coverage. The description merely lists the parameter names without adding new semantic meaning (e.g., format, value constraints, or how to specify the machine type). Thus the baseline 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 clearly states that the tool sets the machine type for a stopped Google Compute Engine instance. It uses a specific verb (sets) and resource (machine type for instance), and distinguishes itself from sibling tools by focusing on machine type modification, while other tools handle creation, deletion, start/stop, or listing.

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 how to verify operation completion: proceed only when the operation status is DONE and there are no errors, and it directs the user to the get_zone_operation tool for details. It also implies the instance must be stopped, providing a precondition. However, it does not explicitly mention when not to use the tool or alternative tools for similar operations.

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 already declare destructiveHint=true and readOnlyHint=false, so the mutation safety profile is known. The description adds useful behavioral context by instructing to check for errors and the operation status being DONE, and directing to get_zone_operation for details. This goes beyond the annotations but does not deeply describe side effects or permissions.

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 concise sentences with no unnecessary fluff. The first sentence states the purpose, the second lists required inputs, and the third provides operational guidance. While the input requirement sentence slightly duplicates the schema, it is brief and does not detract from the overall clarity.

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 that this is a straightforward start operation with an output schema present, the description adequately covers the invocation flow: call the tool, check for errors and DONE status, and use get_zone_operation for details. It does not explain what happens to the instance (e.g., transitions to RUNNING), but that is not essential for this tool's use.

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 baseline is 3. The description merely states that project, zone, and instance name are required, which restates the schema without adding any new meaning or parameter-level detail. No extra context is provided for these 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 action: 'Starts a Google Compute Engine virtual machine (VM) instance.' This specific verb+resource combination distinguishes it from sibling tools like create_instance, delete_instance, stop_instance, and reset_instance. It also notes the required inputs, further clarifying the intended 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?

The description implies the tool is for starting an existing stopped VM but does not explicitly state when to use it versus alternatives like reset_instance. It provides guidance on proceeding only after verifying the operation status is DONE, which is more about post-invocation handling than usage context. No explicit exclusions or alternative-tool references are given.

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

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

Beyond the annotations (destructiveHint=true, readOnly=false), the description discloses that the operation returns an operation object whose status must be DONE, and directs the agent to get_zone_operation for details. This adds meaningful context about asynchronous behavior and error handling without contradicting 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, front-loading the purpose and then adding operation-status guidance. The second sentence duplicates schema information somewhat, but the whole is compact and 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?

Given the low complexity, complete schema, and presence of an output schema, the description sufficiently covers the workflow by mentioning the DONE status requirement and pointing to get_zone_operation for follow-up. It does not need to describe return values because an output schema exists.

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 three parameters are already fully documented. The description only repeats their names ('project, zone, and instance name') without adding value such as format, defaults, or interactions.

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

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

The description opens with a specific verb 'Stops' and explicitly names the resource ('Google Compute Engine virtual machine instance'), clearly distinguishing this from sibling tools like start_instance, reset_instance, and delete_instance.

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

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

The description implies the use case (stopping a VM) and provides an operational guardrail (wait for DONE status, use get_zone_operation for details), but it does not explicitly state when to choose this over alternatives (e.g., reset vs stop) or include exclusions.

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