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

The description says 'Book', which implies a state-changing mutation, while annotations declare readOnlyHint=true. This is a direct contradiction. The description also does not disclose side effects such as creating a reservation or payment implications.

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, purposeful sentences. It front-loads the core action and then gives the key invocation rule without any 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 is minimally sufficient for tool selection: it identifies the booking action and when to call. However, it omits important behavioral context like side effects, and the contradictory readOnlyHint annotation undermines the overall reliability of the definition.

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 descriptions already cover proposal_token and payment_method_id, giving 67% coverage. The description adds little parameter-specific detail, though 'quoted ride' and the explicit-request condition provide indirect context for the confirmation field.

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

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

The description states a clear action ('Book') and resource ('a quoted ride'), making the tool's purpose obvious. It also separates this from siblings like waymo_get_quote and waymo_cancel_ride, though it does not explicitly name alternatives.

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 an explicit trigger condition: call only after the user explicitly requests booking. It does not describe exclusions or alternatives, but the sibling set makes the intended workflow reasonably clear.

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

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

Annotations already mark this as destructive (destructiveHint=true) and non-read-only. The description adds important behavioral guardrails: the cancellation must be preceded by a fresh fee preview and explicit user confirmation. This goes beyond the annotation flags, though it does not detail consequences such as cancellation fees.

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 concise sentence that front-loads the action and then states both prerequisites. Every word earns its place, with 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 one-parameter destructive tool with annotations and an output schema, the description covers the two critical preconditions: fresh fee preview and explicit user confirmation. Minor gaps include not naming the preview tool directly and not mentioning potential fees, but the destructive hint and title cover the general context.

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

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

The schema has one parameter with 0% description coverage, so the description must compensate. 'Explicit user confirmation' indicates the purpose of the confirmation parameter, and the schema's const 'CANCEL' defines the allowed value. However, the description does not explicitly state that the confirmation value must be 'CANCEL', leaving the mapping partially implicit.

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 a specific verb ('Cancel') and a specific resource ('the active Waymo ride'), and the phrase 'after a fresh fee preview' distinguishes it from the sibling waymo_preview_cancellation. However, it does not explicitly name the sibling, so the differentiation is implicit rather than 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 clear usage conditions: call only after a fresh fee preview and after explicit user confirmation. This gives the agent a concrete sense of when the tool should be invoked, but it does not mention alternatives or say when not to use it beyond these preconditions.

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 indicate readOnlyHint=false, openWorldHint=true, and idempotentHint=false, so the description is not required to restate those. It adds the behavioral distinction between an ASAP quote and a re-quote using a scheduling token. Still, it does not disclose whether quotes expire, whether they create a hold, or how live availability affects results.

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, tightly worded sentence that front-loads the primary action ('Quote an ASAP route') followed by the secondary re-quote mode. Every word contributes meaning, 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?

The tool has 8 parameters and depends on prior search results (via result indices) and prior quotes (via scheduled_option_token), but the description does not mention these prerequisites or how they relate to sibling tools. The output schema may cover return values, but an agent is left to infer the workflow from parameter names and schema descriptions alone.

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 63%, and the description adds the important context that scheduling options come from a prior quote and that omitting the token means ASAP. It does not clarify the result-index parameters or the passengers field, leaving those to schema names and defaults, but it does not mislead.

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 ('Quote') and resource ('a Waymo ride quote'), and clearly distinguishes two modes: ASAP quote versus re-quote with a scheduling option. It does not explicitly differentiate from sibling tools, but the action and modes are 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 gives two clear usage scenarios (ASAP route or re-quote using a returned scheduling option) and implies the re-quote depends on a prior quote. However, it does not state when to prefer this over alternatives like waymo_search_places or waymo_book_ride, and no exclusions are provided.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds useful context beyond those annotations by clarifying that only safe labels and IDs are returned, not full sensitive payment details, and that the results are scoped to what the booking tool accepts.

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, efficient sentence with no filler. The key qualifier ('safe') and scope ('accepted by the booking tool') are front-loaded, and every word adds meaning.

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

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

For a zero-parameter read-only list tool with an output schema and annotations covering safety, the description is complete. It states exactly what is listed, the scope, and the safe nature of the data, leaving no critical gap for an agent to call it.

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

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

The tool has zero parameters and the schema covers everything vacuously. With no parameters to document, the description does not need to add parameter detail; the baseline of 4 applies.

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

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

The description uses a specific verb ('List') and a specific resource ('safe payment-method labels and IDs accepted by the booking tool'). It clearly distinguishes this tool from ride-oriented siblings like waymo_ride_history and waymo_book_ride.

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

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

The phrase 'accepted by the booking tool' implies this should be used to retrieve usable payment methods before booking, but it does not explicitly state when to use it versus alternatives. No exclusions or alternative routing are mentioned, making the guidance only implicit.

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

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

The description adds a key behavioral guarantee beyond the annotations: it will not cancel the active ride. This addresses the main destructive risk, especially since readOnlyHint is false but destructiveHint is false. It does not detail other potential side effects, but for a 0-parameter preview tool this is reasonably transparent.

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

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

A single, front-loaded sentence that conveys purpose, target, and key non-effect with no wasted words. Every phrase 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 tool has no parameters, an output schema, and a straightforward purpose, the description provides enough context for correct selection and invocation. The active-ride scoping and the explicit 'without cancelling' clarification make the behavior complete for an agent.

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

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

The tool has no parameters and schema coverage is 100%. The description still adds useful meaning by identifying that the operation targets 'the active ride,' explaining why no explicit ride identifier parameter is needed.

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

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

The description clearly states the specific action: previewing the cancellation and its fee. It also explicitly distinguishes this from actually canceling by adding 'without cancelling the active ride,' which separates it from the sibling waymo_cancel_ride.

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: use this when the user wants to know the cancellation cost before deciding whether to cancel. However, it does not explicitly name alternatives or state when not to use it, though the contrast with canceling is implied.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds a useful behavioral detail by including cancelled and completed rides in the returned set. However, it does not disclose additional behavior such as ordering, recency bounds, or pagination, leaving some gaps.

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, concise sentence with no filler. The core behavior is front-loaded and every word contributes meaning.

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 tool with one optional parameter, an output schema, and clear annotations, the description is mostly sufficient. It could be improved by mentioning when to choose this over waymo_ride_status, but the essential invocation context is 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 schema has 0% description coverage and the description does not mention the 'limit' parameter at all. The parameter is relatively self-explanatory from its name and schema constraints, but the description provides no added semantic value to compensate for the lack of schema descriptions.

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 ('Return') and resource ('recent Waymo trips') and clarifies that cancelled and completed rides are included. It clearly identifies the tool's purpose, though it does not explicitly differentiate it from sibling tools like waymo_ride_status.

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 a listing/history use case through the phrase 'recent Waymo trips,' but it does not explicitly state when to use this tool over waymo_ride_status or other siblings. No alternatives or exclusions are mentioned.

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

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

The readOnlyHint annotation already signals safety, and the description adds useful behavioral context by noting that terminal trips remain cached and may still be returned. This clarifies state beyond what the annotation alone conveys.

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

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

The description is a single, front-loaded sentence with no filler. Every word adds meaning, and it is appropriately sized for such a simple tool.

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

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

For a zero-parameter, read-only tool with an output schema, the description fully conveys scope and caching nuance. Nothing essential is missing for an agent to select and invoke it correctly.

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

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

The tool has zero parameters, and schema description coverage is 100%. There is nothing for the description to add about parameters, so the baseline of 4 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 states a specific verb ('Return') and resource ('the active ride and any terminal trip still cached by Waymo'), making the tool's core function clear. It does not explicitly differentiate from siblings like waymo_ride_history, so it stops short of a top score.

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

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

The phrase 'active ride' implies use for current ride status, and mentioning 'terminal trip still cached' gives some context for post-ride behavior. However, there is no explicit guidance about when to choose this tool over waymo_ride_history or waymo_preview_cancellation.

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 openWorldHint=true, so the safe read-only nature is established. The description adds the normalization behavior ('canonical Waymo locations') but does not disclose potential ambiguous matches or response characteristics. This is adequate but not rich.

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

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

The description is a single focused sentence with no filler. It states the action and target upfront, making it easy for an agent to parse 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?

For a read-only search tool with documented parameters, annotations, and an output schema, the description covers the essential task. It does not mention default geolocation bias, but that information is already present in the input schema.

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

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

The schema already documents query, bias_latitude, and bias_longitude, and limit has clear constraints and a default. The description only restates the query concept and adds no extra parameter meaning, which is acceptable given schema coverage of 75%.

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

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

The description uses a specific verb, 'Resolve', and identifies the exact resource: a place name/address mapped to canonical Waymo locations. It is clearly distinct from sibling tools, which concern rides, quotes, payments, and cancellations.

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 correct use case: when a user provides a place name or address and needs a canonical Waymo location. No explicit exclusions are needed because no sibling tool offers place searching.

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