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, which cover the safety profile. The description adds value by listing the exact fields returned, but does not disclose further behavioral aspects like auth requirements or error conditions. Given annotation coverage, the description contributes appropriately but not extensively.

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 short and front-loaded with the verb and resource. However, the second sentence ('Requires project, region, and commitment name as input.') is redundant with the schema. Removing it would improve conciseness without losing any unique 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 tool with an output schema, the description covers the resource, specific fields, and required inputs. It does not mention error handling or prerequisites, but these are not critical given the tool's simplicity and the presence of an output schema. Minor gaps exist, but overall sufficient 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?

Input schema coverage is 100%, so each parameter already has a description. The tool description only restates the required parameters ('Requires project, region, and commitment name as input.') without adding new semantic details. Thus, it does not extend beyond the schema information, earning a baseline score 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 'Get basic information about a Compute Engine Commitment' with a specific verb and resource. It lists the fields returned (name, ID, status, plan, type, resources, timestamps), differentiating it from siblings like list_commitments (which lists all commitments) and other get_*_basic_info tools (different resource types).

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

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

The description implies usage by specifying the resource and data returned, but it does not provide explicit guidance on when to use this tool versus alternatives like list_commitments or get_reservation_basic_info. No when-not-to-use conditions are mentioned, 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 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying exactly what aspects of performance configuration will be returned, giving the agent a clear expectation of 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 two compact sentences with no filler. The primary purpose and output fields are front-loaded, followed by the required input summary, making it easy to scan and act on.

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

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

With a rich output schema, complete parameter schema coverage, and annotations establishing read-only/idempotent behavior, the description covers everything needed to invoke the tool correctly. The listed fields and required inputs make the call unambiguous.

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 each parameter is already documented. The description restates that project, zone, and disk name are required but does not add deeper meaning about formats, defaults, or constraints 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 a specific verb ('Get') and names a precise resource: the performance configuration of a Compute Engine disk. It enumerates the included fields (type, size, IOPS, throughput, block size, storage pool, access mode), which clearly distinguishes it from broader sibling tools like get_disk_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 clearly states the necessary inputs—project, zone, and disk name—so an agent knows what must be supplied. It does not explicitly compare itself to sibling getters or state when not to use it, but the configuration-specific scope provides adequate context for selection.

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, destructiveHint=false, and idempotentHint=true, covering the safety and side-effect profile. The description adds the return content (list of properties) but does not disclose additional behavioral traits such as authentication requirements, rate limits, or any potential error conditions. While informative, it does not go beyond what annotations imply.

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, with the action and resource front-loaded. The list of properties is useful and not overly verbose; it is directly relevant to the tool's purpose. It avoids unnecessary detail while providing a clear overview, making it efficient and 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 presence of an output schema (per context signals), the description does not need to explain return formats. It covers the tool's scope, inputs, and output types, making it functionally complete for an agent to call correctly. The only missing element is explicit guidance on when to prefer this over get_instance_template_basic_info, which is a minor gap.

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

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

Schema coverage is 100%—both parameters (project and name) have descriptions. The description repeats this requirement without adding new semantic details, such as format constraints or special values. Since the schema already documents the parameters, the baseline is 3, and the description does not enhance 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 retrieves instance properties of a Compute Engine instance template and enumerates the specific properties covered (description, tags, machine type, network interfaces, etc.). This makes its purpose precise and distinct from the sibling get_instance_template_basic_info, which implies a subset of these properties. The verb and resource are explicit.

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

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

The description provides context by stating the required inputs (project and instance template name) and enumerates the returned properties, implying when to use it (when comprehensive properties are needed). However, it does not explicitly contrast with the alternative get_instance_template_basic_info or state when not to use this tool, leaving usage guidance mostly 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, 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 declare readOnlyHint, idempotentHint, and destructiveHint false, so the description only needs to add contextual behavior. It adds value by detailing exactly what properties are returned and by requiring a specific set of identifiers, giving the agent a richer behavioral picture beyond the annotation flags. No contradictions exist.

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

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

The description opens with a concise action statement and then provides a structured enumeration of returned fields, which is useful for an agent deciding whether this tool fits. The field list is lengthy but justified for a 'details' tool; the final sentence about required inputs is somewhat redundant with the schema but still serves as a quick confirmation. Overall, it is well-organized and free of 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?

The description fully covers what the tool does, what it returns, and what inputs are required. Since an output schema exists, return-value details do not need to be repeated, and the annotations already cover the safety/idempotency profile. For a read-only, single-resource detail tool, the description is complete enough for correct invocation.

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

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

The input schema descriptions fully document the three required parameters (project, zone, name) with 100% coverage, so the schema carries the semantic burden. The description merely restates that these inputs are required without adding additional parameter-level meaning, such as formats, constraints, or relationship between the 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 uses a specific verb ('Get') with a clear resource ('Compute Engine reservation details') and then enumerates the distinct types of data returned, such as name, ID, status, machine type, and sharing settings. This detailed property list distinguishes it from sibling tools like get_reservation_basic_info and list_reservations without requiring the agent to compare schemas.

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 the tool to use when full reservation details are needed, and the 'Requires project, zone, and reservation name' line signals when it applies. However, it does not explicitly state when to prefer get_reservation_basic_info for a summary or list_reservations for enumeration, so the guidance is more implied than clearly 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, 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only safety profile is covered. The description adds transparency by enumerating the reservation properties returned and explicitly requiring project, region, and commitment name, without introducing contradictions.

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 purpose is front-loaded in the first sentence, followed by useful return-field context and required inputs. The enumeration is somewhat lengthy and overlaps with what the output schema likely provides, but it remains readable and relevant.

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?

All required inputs are identified, the output is characterized, and annotations cover the safety profile, so an agent can invoke this read-only list operation correctly. Still, it does not mention pagination or scale behavior, which would be useful for a list operation, and the return-field list partially duplicates the output schema.

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

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

The input schema has 100% description coverage for all three required parameters, including the semantic role of 'name' as the commitment identifier. The description merely restates that project, region, and commitment name are required and adds no new parameter-level 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 states a specific verb and resource: 'Lists reservations for a Compute Engine Commitment.' The commitment scoping clearly distinguishes it from sibling tools like list_reservations and list_commitments, and the mention of returning reservation details clarifies its role.

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 intended use case is implied: call this when you need reservations belonging to a specific commitment. However, it does not explicitly say when not to use it or point to alternatives such as list_reservations or get_reservation_details, leaving some selection to inference.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, idempotent read operation. The description adds no new behavioral traits beyond confirming it lists commitments. It does not discuss rate limits, permissions, or response format (though output schema exists). The description meets the baseline given annotation coverage but adds minimal extra 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 extremely concise: two sentences, no fluff. The first sentence states the action and expected output, the second states requirements. Every word adds value. It is front-loaded with the core purpose.

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 presence of a full output schema, and annotations covering safety, the description is complete. It explains what the tool does, what it returns (details), and what inputs are required. Pagination parameters are in the schema. There is no missing information that would hinder correct invocation.

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

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

Schema coverage is 100% with descriptions for all four parameters (project, region, pageSize, pageToken). The description merely restates that project and region are required, which is already in the schema. No additional semantics or clarification about parameter values (e.g., region format, pageToken usage) are provided. The baseline score of 3 is appropriate since 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?

The description clearly states the tool lists Compute Engine Commitments in a region, specifying the exact resource type (commitments) and the context (region). It enumerates the details returned (name, ID, status, etc.), which unambiguously identifies the tool's purpose. This distinguishes it from sibling tools like list_commitment_reservations, which list a different sub-resource.

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 the tool requires project and region as input, which implies it should be used when the agent needs to list commitments within a specific project and region. However, it does not explicitly mention when not to use it or provide alternative tools for different scopes (e.g., list_disks for disks). Still, the context is sufficient for an informed agent.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds detail about the response fields (e.g., kind, type, mode) which is useful context beyond the annotations. However, it does not disclose any additional behavioral traits such as pagination, rate limits, or authentication requirements. No contradiction exists. With annotations present, the description provides moderate added 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 informative but somewhat verbose. It front-loads the main purpose and then lists many response fields, which is useful. However, the closing sentence 'Requires project, zone, and instance name as input.' is redundant given the schema's required fields and could be trimmed. Overall, it is structured in a single sentence but includes a lengthy enumeration that could be more concise.

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 tool with an output schema available, the description is fairly complete. It clearly states the operation, the required inputs, and the nature of the response (listing attached disks with many fields). It does not mention pagination or filtering, but the presence of an output schema likely covers return structure. Given the tool's simplicity and annotation support, no critical information is missing.

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

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

The input schema has 100% description coverage for all three required parameters (project, zone, name). The description only restates that these are required, without adding meaning beyond what the schema already provides. Since the schema fully documents each parameter, a 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 the specific verb 'Lists' and the resource 'disks attached to a Compute Engine virtual machine (VM) instance'. It distinguishes itself from sibling tools like list_disks and list_instances by focusing on attached disks of a specific instance, making the purpose unambiguous.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. It only states what it does and mentions required inputs. No exclusions or routing to sibling tools like list_disks or get_instance_basic_info are given, leaving the agent to infer the appropriate context.

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 establish the tool as read-only, idempotent, and non-destructive. The description adds useful context by listing what information is returned for each instance (id, instance URL, status, current action) and reiterating required inputs. 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 two concise sentences with no filler. The primary action and resource are front-loaded, followed by the key output details and required inputs. 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?

Given the read-only annotations, a complete input schema, and an output schema, the description covers what the tool does, what it returns, and what it requires. Nothing essential is missing for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the input schema already documents all five parameters, including the optional pageSize and pageToken. The description only restates that project, zone, and MIG name are required, which adds little beyond the schema. The baseline 3 is appropriate because 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?

The description uses a specific verb ('Lists') and identifies the exact resource being acted on ('managed instances for a given managed instance group (MIG)'). It also states the kind of details returned, which makes the tool's purpose unambiguous and distinguishes it from siblings like list_instances or list_instance_group_managers.

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

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

The description makes the usage context clear by specifying that this is for a given MIG and explicitly stating the required inputs: project, zone, and MIG name. It does not explicitly name alternatives or exclusion cases, but the 'for a given MIG' framing is enough to guide correct selection in most situations.

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

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

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.