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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds a useful consent guardrail ('only after the user explicitly requests it'), but it does not disclose further behavioral details such as charging the payment method, consuming the quote, or irreversibility beyond what annotations already convey.

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. The key condition is front-loaded and every word contributes to the tool's safe invocation.

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

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

For a destructive booking action, the description captures the critical gating condition: explicit user request. The input schema covers parameter provenance and the confirmation constant, and the output schema exists. It could still explicitly warn about charges or quote consumption, but overall it is sufficiently complete.

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

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

Two of the three parameters already have schema descriptions identifying their sources (proposal_token from robotaxi_get_quote, payment_method_id from robotaxi_list_payment_methods), and confirmation is self-documenting via const 'BOOK'. The description adds no parameter-level meaning, but the schema coverage is adequate.

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 and resource: 'Book a quoted ride'. The phrase 'quoted ride' distinguishes this tool from robotaxi_get_quote and other ride-related siblings, and the explicit-request qualifier makes the action's scope clear.

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 when to invoke the tool: only after the user explicitly requests the booking. It implies the should-not-call condition (before explicit user request), though it does not explicitly name related tools or provide a detailed workflow with alternatives.

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

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

Annotations already declare destructiveHint=true, and the description adds meaningful behavioral context: a fresh preview and explicit user confirmation are required before the destructive cancellation occurs. This goes beyond the structured annotations without contradicting them.

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, front-loaded, and contains no filler. Every word earns its place by communicating a necessary precondition.

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

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

For a simple one-parameter destructive tool with a rich output schema and annotations, the description is largely complete. It covers the safety-critical prerequisites and clearly distinguishes this cancellation action from the preview sibling. Minor details about cancellation effects are not stated, but the destructive annotation and output schema cover much of that burden.

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 the single parameter with a required const of 'CANCEL'. The description adds the notion of 'explicit user confirmation,' which gives some semantic context, but with 0% schema description coverage it does little to independently document the parameter beyond what the schema's const and title already convey.

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 title clearly identifies the action ('Cancel the active Tesla Robotaxi ride'), and the description reinforces it with a specific verb and the required preconditions. It differentiates from robotaxi_preview_cancellation by making clear this tool performs the actual cancellation after a preview.

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 usage condition: only cancel after a fresh preview and explicit user confirmation. This effectively tells the agent when it is appropriate to invoke the tool, though it does not explicitly name alternatives or edge cases.

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 says 'Get a live fare,' which presents the operation as a read-only retrieval, yet the annotations declare readOnlyHint=false. This is an annotation contradiction; the description also fails to clarify whether the quote request has side effects or validity 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 a single front-loaded sentence with no wasted words. It is concise, though 'for two Robotaxi locations' is slightly vague compared to saying 'between pickup and dropoff.'

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 4-parameter tool with a place-search sibling, the description omits the workflow (search places, then choose result indexes) and the relationship to book_ride. The output schema may cover returns, but the description is not complete enough for correct invocation in ambiguous-location cases.

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

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

Only pickup and dropoff have schema descriptions; pickup_result_index and dropoff_result_index are undocumented. The description adds no meaning for the index parameters, so an agent cannot tell that they select among place-search results or how to use them.

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

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

The description names a specific operation—get a live fare and route preview—for two robotaxi locations, which clearly distinguishes it from sibling tools like search_places, book_ride, and ride_status. The verb 'Get' plus 'fare and route preview' makes the tool's outcome unmistakable.

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 purpose implies this is a pre-booking fare/route check, but the description never explicitly says to use it before book_ride or explains when not to use it. There are no stated alternatives or exclusions, so the agent is left to infer usage from the sibling names.

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

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

Annotations already declare readOnlyHint=true, and the description adds that only 'safe labels and IDs' are returned, implying no sensitive payment details are exposed. This adds some context beyond the annotations, but does not cover data freshness, availability, or external dependencies.

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 wasted words. It front-loads the action and clearly specifies the returned 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 parameterless, read-only listing tool with an output schema, the description is complete. It specifies the domain (Robotaxi-compatible payment methods) and the nature of the returned data (safe labels and IDs), which is sufficient for 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?

With zero parameters, the description does not need to explain parameters. The baseline for a parameterless tool is 4, and the description provides enough context about what is being listed.

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 labels and IDs for Robotaxi-compatible saved payment methods'). It clearly distinguishes this tool from the sibling ride-related and search tools by focusing on payment methods.

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 any guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Usage is implied only by the tool name and resource.

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

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

The description adds the guarantee 'without cancelling it,' but it does not clarify the tool's broader side-effect profile. Since readOnlyHint is false and openWorldHint is true, the agent needs more transparency about whether a preview may alter state; the description leaves this ambiguous.

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

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

One tightly worded sentence communicates the action, the target, and the critical non-destructive guarantee. No filler or redundant restatement of the tool name or title.

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

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

For a zero-parameter tool with an output schema, this description is sufficiently complete. The only real gap is side-effect clarity, which is already partly covered by the annotations and is separate from contextual completeness.

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

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

There are no parameters, so the schema already provides full coverage. The description does not need to add parameter details, and the baseline of 4 for zero-parameter tools 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 states a specific action (Preview), a specific resource (the active ride before cancellation), and the key differentiator from cancel_ride: it does not cancel. This clearly distinguishes it from sibling tools like robotaxi_cancel_ride and robotaxi_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 phrase 'before cancellation' supplies a clear usage context, and 'without cancelling it' tells the agent this is a safe precursor to cancellation. However, it does not explicitly name the alternative tool (robotaxi_cancel_ride) 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?

The annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds a 'recent' scoping constraint but does not disclose ordering, result limits, pagination, or what counts as recent, which would be useful behavioral context.

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 the verb and resource front-loaded. Every word adds relevant context, and there is no redundant or filler content.

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

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

For a simple read-only list tool with one optional param and an output schema, the description is mostly sufficient. It does not explain the relationship to robotaxi_ride_status or clarify the meaning of 'recent,' but the annotations and schema cover safety and the parameter shape.

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 description does not mention the only parameter, `limit`, and schema description coverage is 0%, so the description carries the burden per the rubric. The schema itself is self-explanatory for this single optional integer, but the description adds no semantic value beyond 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 action ('Return') and the resource ('recent Robotaxi rides'), and identifies the source as Tesla's ownership service. It does not explicitly distinguish itself from siblings like robotaxi_ride_status, but the word 'history' makes the list-oriented purpose reasonably clear.

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

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

The description gives no guidance about when to use this tool versus alternatives such as robotaxi_ride_status or robotaxi_book_ride. There is no mention of when not to use it, no prerequisites, and no comparison to sibling tools.

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

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

Annotations already provide readOnlyHint and openWorldHint, so the description is not burdened with basic safety disclosure. It adds useful scoping ('active' vs 'most recent terminal') but does not explain what happens if no ride exists or whether status can change between calls. This is acceptable 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 sentence with no filler. It front-loads the action and the key semantic distinction between active and most recent terminal sessions.

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 status tool with an output schema and helpful annotations, the description covers the essential behavior. The main gaps are the unexplained 'TripX session' terminology and a lack of explicit connection to sibling tools like ride_history.

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

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

The tool has zero parameters, so there is no parameter documentation burden on the description. The schema fully covers this area, and the baseline for zero parameters is 4.

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

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

The description states a specific action ('Return') and a precise resource ('active ride or most recent terminal TripX session'), which goes beyond the title. It is reasonably distinguishable from siblings like robotaxi_ride_history, though it does not explicitly name the alternative.

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

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

The phrase 'active ride or most recent terminal' implies when the tool is appropriate: for current or last-completed ride status. However, it does not explicitly contrast with robotaxi_ride_history or state when not to use this tool, leaving some selection inference to the 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds little behavioral context beyond the core transformation; it does not mention ambiguity handling, result ordering, or external geocoding behavior.

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

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

The description is a single efficient sentence with no filler. The action and object are front-loaded, making the tool's purpose immediately scannable.

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 search tool with an output schema, annotations, and reasonably descriptive parameters, the one-line description is nearly sufficient. It is slightly thin on how the resolved locations relate to downstream ride operations, but that is inferable from sibling tool names.

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 75%, with query, bias_latitude, and bias_longitude already documented. The description's phrase 'place name or address' largely duplicates the query schema description, and it does not clarify the 'limit' parameter beyond its name and default.

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 clearly identifies the input ('a place name or address') and output ('Robotaxi locations'). It is easy to distinguish from the ride-status, booking, and payment sibling tools, none of which perform location search.

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 this tool — when you have a place name or address to convert into Robotaxi locations — but it gives no explicit when-to-use or when-not-to-use guidance and does not name alternatives. An agent must infer its role in the ride-booking flow.

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