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

Adds genuine behavior beyond the annotations: a free window while searching and for two minutes after a driver accepts, then a fee, plus the precondition that the ride must not have started. What remains unstated is whether cancellation is reversible and what happens to the fee if a ride is mid-acceptance; the destructiveHint=true annotation already signals the mutation.

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

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

Three short sentences, front-loaded with the precondition, then the cost model, then the invocation rule. Every sentence carries information an agent needs.

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, output-schema-less tool this covers preconditions, cost consequences, and the trigger condition. The only real gap is the undocumented reason parameter and, secondarily, the ambiguity against cancel_scheduled_ride.

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 only 50%: ride_id is documented in the schema as omittable to target the active ride, but reason is documented nowhere. The description does not compensate, saying nothing about whether reason is surfaced to the driver or required in any case.

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

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

Uses a specific verb and resource ("Cancels a ride") plus a decisive precondition ("that hasn't started"). It implicitly separates this tool from cancel_scheduled_ride, but never names that sibling explicitly, so an agent has to infer the boundary.

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

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

Gives an explicit when-to-use rule, "Only call when the user asks to cancel", which is a real guard against proactive cancellation. It omits the when-not case that matters most here, namely that pre-scheduled rides belong to cancel_scheduled_ride.

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 openWorldHint=true, so the description's job is to add consequence detail — irreversibility, cancellation windows, fees, or whether the schedule_id is validated. It supplies none of that. The only added behavioral element is the vague "only call when the user asks" guard, which does not explain what destruction actually means here.

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

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

Two short sentences with the action stated first and the usage guard second — appropriately sized for a one-parameter tool. The second sentence is slightly wasteful because it restates an obvious safety norm rather than specifying it.

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 destructive mutation with no output schema, an undocumented parameter, and an adjacent sibling that cancels non-scheduled rides. Given that complexity, the description should cover the identifier source, the destructive consequence, and the cancel_ride boundary; it covers none of these.

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 is one required parameter, schedule_id, at 0% schema description coverage, and the description never mentions it. An agent gets no signal on where the identifier comes from (presumably list_scheduled_rides) or what format it takes, so the description fails to compensate for the coverage gap.

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?

"Cancels a ride booked for later" gives a specific verb plus a qualified resource, and the phrase "booked for later" implicitly separates it from the immediate-cancel sibling. It stops short of naming cancel_ride, which is the one sibling an agent could confuse it with.

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?

"Only call when the user asks" is a genuine usage gate, but it is thin and ambiguous — does an agent-initiated suggestion count as the user asking? There is no guidance on choosing this over cancel_ride, which is the primary routing decision for this tool.

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

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

Annotations already flag destructiveHint=true and openWorldHint=true, so the safety profile is partly covered; the description adds real value by disclosing the mandatory two-step confirmation flow and the requirement that the passed price match the current preview. It stops short of saying whether the previous destination is recoverable or what happens if the price no longer matches the preview.

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

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

Two short sentences, front-loaded with the action and followed by the gating condition. Every clause carries operational weight; nothing is padding.

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 mutation with no output schema, the description covers the essential safety-critical flow (preview first, user consent, matching price). It leaves out the outcome of a successful call and the failure behavior on a price mismatch, which are the remaining gaps an agent would want.

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 67%, and the description largely restates what the schema already documents about confirmed_price_toman ("Must match the current preview"). It does implicitly explain why ride_id is optional by scoping the operation to "the active ride," but adds no format or validation detail beyond the structured fields.

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

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

States a specific verb and resource ("Changes the active ride's destination") and immediately names the sibling that must precede it (preview_destination_change), so an agent can distinguish it from the preview tool without opening either schema.

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

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

Gives an explicit precondition ("Only call after preview_destination_change") plus a second condition ("the user agreeing to the new price"), which effectively names the alternative to use when that condition is unmet. Nothing about when to invoke it is left 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?

readOnlyHint=true already covers the safety profile, but the description adds genuinely useful provenance: the value is the last one set via set_current_location, not a live GPS fix, so an agent can reason about staleness. It omits what happens when no location has ever been set (null? error?), which keeps this below a 5.

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

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

A single front-loaded sentence with no filler; the return semantics lead and the provenance caveat follows immediately. Every clause carries 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?

With no output schema, the description should say what shape the answer takes (coordinates, place object, place name) and what is returned when no location is set. It covers only the conceptual return value, leaving the agent to discover the payload structure at call time.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter meaning the description could add. Nothing in the schema is left unexplained.

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?

"Returns where the user currently is" gives a specific verb plus resource, and the parenthetical ties it to set_current_location, so the agent can tell it apart from the write-side sibling. It stops short of distinguishing it from read siblings like list_places or search_address, which also surface location data.

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

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

Usage is only implied: fetch the user's present position when needed. There is no explicit when-to-use or when-not-to-use guidance, and no mention of preferring list_places for saved locations or search_address for lookups.

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

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds genuinely new behavior beyond that — non-booking semantics and a 5-minute expiry that forces re-quoting. It stops short of describing result shape or how many services typically return, but the critical operational trait 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?

Four short sentences, front-loaded with purpose and the negative boundary, followed by the workflow step and the expiry caveat. No redundant restatement of the schema.

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 quoting tool with a fully documented schema and no output schema, the description covers purpose, the do-not-book boundary, the handoff to request_ride, and quote lifetime. Only the shape of the returned options is unstated, a minor gap given the 'one per service type' phrasing.

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 origin, destination, second_destination and services are already fully documented, including accepted formats. The description adds only the framing that quotes are per service type, which the schema's parameter docs already imply.

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

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

States a specific verb and resource ('Gets price and ETA quotes for a ride') and immediately scopes the return ('one per service type'). The negative clause 'Does NOT book anything' cleanly separates it from the sibling request_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?

Explicit sequencing: show the user the options, then call request_ride with the chosen quote. It names the alternative tool and the condition that selects it, leaving nothing 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?

readOnlyHint=true already establishes this as a safe read, so the description's main job is to add context — and it does, enumerating exactly what comes back (driver, car, plate, driver location, ETAs) and disclosing the default-to-active-ride fallback. It stops short of describing staleness, polling behavior, or the error case when no ride is active, which is why it is not a 5.

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

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

Two short sentences, zero filler, with the returned payload front-loaded and the defaulting behavior second. Every clause carries information an agent can 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 no output schema, the description's enumeration of returned fields is doing real work and covers the essentials for a single-ride read. The remaining gap is that it doesn't route the agent to wait_for_ride_update for repeated polling, a minor omission 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 coverage is 100% and the single ride_id parameter is fully documented in-schema as "Omit to use the current active ride." The description's default statement simply restates that, adding no new semantics such as accepted ID formats.

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

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

The description uses a specific verb ("Shows") and names the resource plus the exact payload: status, driver, car, plate, location and ETAs. That clearly separates it from list_rides or request_ride, but it never names a sibling such as wait_for_ride_update or list_scheduled_rides, so the differentiation is implicit rather than stated.

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?

"Defaults to the active ride" implies the common case (a one-shot status check without an ID), which is useful context. However, it gives no explicit when-to-use versus wait_for_ride_update for polling, nor any exclusion for historical or scheduled rides, leaving the agent to infer the boundary.

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, so the safety profile is covered; the description adds genuinely new behavioral facts — the returned price is a range, a scheduling fee may be added, and no booking is created. It does not cover failure behavior (e.g. what happens when the requested time falls outside the allowed window), which keeps it off a 5.

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

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

Two sentences, front-loaded with the purpose, then the constraint, then the routing to schedule_ride. Every clause carries information an agent needs; nothing is padding or restatement of the 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?

With no output schema, the description usefully characterizes the return value as a price range plus a possible fee, and it warns that nothing is booked. For a read-only four-parameter quoting tool that is close to complete; only error/edge-case behavior for invalid times is unaddressed.

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 all four parameters are already documented in the schema, and the description adds no per-parameter detail beyond that baseline. Its only added semantic value is the constraint that `time` must be a today/tomorrow 5-minute slot, which meaningfully narrows a free-form ISO string.

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

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

States a specific verb and resource — "Prices a ride booked ahead for a given time" — which unambiguously separates it from get_ride_quotes (immediate pricing) and schedule_ride (actual booking) among the siblings. The scope (ahead-of-time pricing only) is clear from the first clause alone.

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

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

Gives an explicit next step and boundary: "Books nothing; call schedule_ride after the user agrees," which tells the agent this is a pre-commitment quote step. It also encodes a hard domain constraint (today/tomorrow, 5-minute slots). It stops short of naming get_ride_quotes as the alternative for an immediate ride, so the when-not 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?

The readOnlyHint annotation already signals this is a safe read. The description adds only the notion that the result is the user's saved set of labeled places, without covering return shape, ordering, or limits, so it contributes modest value beyond the annotation.

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 with no filler. The trailing ellipsis is slightly informal but the 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 zero-argument read tool with annotations covering safety, most needs are met, but with no output schema the description should say what a place entry contains and whether results are paginated or limited. The gap to suggest_places and search_address is also unaddressed.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline applies. The parenthetical hint about home/work categories does mildly foreshadow the shape of returned entries.

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?

Names a specific verb and resource ('Lists the user's saved places') and clarifies the concept with examples (home, work). It does not distinguish itself from nearby siblings such as suggest_places or search_address, but the core operation is 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?

There is no guidance on when to call this versus alternatives like suggest_places (recommendations) or search_address (lookup by query). The agent must infer the distinction from tool names alone.

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

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

The readOnlyHint=true annotation already establishes this is a safe read, so the description only needs to add context. "Newest first" is a useful ordering disclosure, but nothing is said about pagination, the default cap of 10 results, or whether only completed rides appear.

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 with zero filler and the ordering constraint surfaced immediately. It is efficient, though its brevity shades into under-specification for a tool with an undocumented parameter.

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?

There is no output schema and only one parameter, which lowers the bar, and the annotations cover the safety profile. Still, an agent cannot tell from this definition how many rides come back by default or how this differs from list_scheduled_rides.

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 0% for the single `limit` parameter, so the description carries the burden and mentions nothing about it — no default, no maximum of 50, no note that omitting it returns 10. The schema keywords convey the bounds but not the meaning of the cap.

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 ... rides") plus an ordering guarantee ("newest first"), so the agent knows exactly what the tool returns. It does not, however, distinguish it from the close sibling list_scheduled_rides, which is a plausible source of mis-selection.

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?

"Recent rides" weakly implies past/historical rides rather than scheduled ones, but there is no explicit when-to-use statement, no exclusions, and no mention of list_scheduled_rides or get_ride_status as alternatives. The agent must infer routing from the tool name alone.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered and the description's bar is lower. Beyond that, it discloses nothing: not whether results are ordered by pickup time, whether past-but-unstarted rides appear, whether results are paginated or capped, or how empty results are signaled.

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 five-word sentence with no filler, and the resource is front-loaded after the verb. It is efficient, though its brevity edges toward under-specification rather than crispness.

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 zero parameters, no output schema, and a read-only annotation, the definition is minimally adequate for an agent to call the tool. It leaves open what "later" covers and what the returned ride records contain, which matters since no output schema documents the return 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 tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description adds nothing about filtering because no filtering is possible.

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?

"Lists rides booked for later" gives a specific verb (Lists) and a scoped resource (rides booked for later), which separates it in spirit from list_rides (existing/current rides) and schedule_ride (creating one). However, it never names those siblings, so the agent must infer the boundary between this and list_rides from the word "later" alone.

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?

There is no explicit when-to-use guidance, no exclusion, and no mention of the natural alternative list_rides or of cancel_scheduled_ride for follow-up actions. Usage is only implied by the tool name and the phrase "booked for later".

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; the description reinforces the read-only contract with 'Changes nothing' and adds a confirmation workflow that annotations cannot express. It stops short of covering failure modes such as an unresolvable address or what the preview contains beyond price.

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

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

Three tight sentences with no wasted words, and the non-mutating guarantee is front-loaded right after the purpose. The trailing workflow instruction is slightly imperative in tone but still 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 two-parameter, non-destructive preview with no output schema, the description conveys what the agent gets back (a new price) and how to act on it. A brief note on what happens when the destination cannot be geocoded would make it fully complete.

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

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

Schema description coverage is 100%, and the schema itself documents the ride_id omission default and the four accepted destination forms including coordinate and landmark lookup. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource — pricing the active ride against a different destination — and implicitly contrasts with change_destination by framing this as a preview that 'changes nothing'. An agent can distinguish it from the sibling mutation tool without opening any schema.

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

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

Explicitly names the alternative ('call change_destination only if they agree') and the condition that selects it, plus an ordering rule (show the user the new price first). This is the when/when-not pattern at its clearest.

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 destructiveHint=true annotation already tells the agent this removes data, so the description's 'Deletes' adds no new safety information. It omits the behaviors that actually matter for a destructive call: whether deletion is reversible, what happens if the name does not match anything, and whether ambiguity or exact-match rules apply.

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 short sentence with the action front-loaded and no filler. It is efficient, though its brevity reflects missing content rather than disciplined editing.

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 one-parameter mutation with no output schema and zero schema description coverage, the definition should explain failure modes and result behavior. As written, the agent knows what the tool nominally does but not how to invoke it safely or what to expect on error.

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 0%, so the single 'name' parameter has no documentation beyond its type. The phrase 'by name' weakly links the param to a place name, but nothing states whether matching is exact, case-sensitive, or how duplicate or partial names are handled.

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 verb ('Deletes') and resource ('a saved place') and adds the lookup key ('by name'), so an agent can distinguish it from list_places or save_place at a glance. It stops short of an explicit contrast with the sibling save_place, but the purpose is 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?

There is no guidance on when to call this versus alternatives, no prerequisite that the place must already be saved, and no note that save_place is the inverse operation for re-adding. The agent must infer all selection logic from the name alone.

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

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

Annotations already flag destructiveHint=true, idempotentHint=false, and openWorldHint=true; the description adds real-world meaning beyond those flags by stating it dispatches an actual driver and charges the user, plus that calling prematurely is the risk. It does not explain idempotency in practice or what a partially failed booking leaves behind.

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

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

Two sentences, no filler, with the mechanism first and the safety gate second. Nothing could be removed without losing information the agent needs.

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?

Covered well for a two-parameter, fully documented mutation, and the money/spawn consequences are stated. However, with no output schema, the agent is never told what a successful booking returns (ride identifier, status, next step), which matters for a tool the agent must follow up on with get_ride_status.

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 both parameters are already documented, including the price-mismatch behavior. The description adds only the provenance of quote_id (it must come from get_ride_quotes), which is useful but marginal over the schema's own text.

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

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

States a specific verb and resource ('Books a ride') and names the prerequisite input source ('quote_id from get_ride_quotes'), which tells the agent where to get the required value. It stops short of distinguishing itself from the sibling schedule_ride, which also books future rides, so an agent must infer the split.

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

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

Gives an explicit precondition: 'only call it after the user has explicitly confirmed the service and price,' which is exactly the gating rule an agent needs for a booking action. It does not state the negative case (e.g., use schedule_ride for future times, or get_ride_quotes first if no quote exists), so the routing is clear 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?

No annotations are supplied, so the description bears the full behavioral burden. "Saves or updates" hints at upsert behavior, but it never states what key determines identity (name?), whether an existing place is overwritten, whether saving requires the place to already exist in some address index, or whether there is a cap on saved places. For a mutation tool with zero annotation coverage this is a meaningful gap.

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

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

A single sentence with no filler, front-loaded with the verb and resource, and the qualifying purpose sits at the end where it reads naturally. It is efficient; it is just thin rather than padded.

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

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

The tool is simple (4 flat parameters, no nested objects, no output schema), so expectations are modest, but the two things an agent most needs — the identity/upsert key and the relationship between address and lat/lng — are absent, and there are no annotations to fall back on. The definition is under-specified for a write operation that silently updates existing data.

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 50%: name and address carry descriptions, but lat and lng have only numeric bounds and no explanation in either schema or description. The description adds nothing about how address relates to coordinates, which one wins when they disagree, or that name is the identity key for the update path. It does not compensate for the coverage gap.

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?

"Saves or updates a named place" gives a specific verb pair and resource, and the trailing purpose clause ("used as a pickup or destination") tells the agent what the stored entity is for, which implicitly separates it from list_places, remove_place and suggest_places. It stops short of naming any sibling explicitly, so an agent still has to infer the boundary itself.

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?

There is no when-to-use or when-not-to-use guidance: nothing says whether to call this versus suggest_places when the user names a place loosely, versus set_current_location, or whether an existing place with the same name should be saved again. The purpose clause implies a usage context but states no conditions or 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 flag openWorldHint and destructiveHint; the description adds the crucial behavioral rule that this commits the user to a price and must not fire before agreement. It stops short of saying the booking is a real, cancellable commitment or pointing to cancel_scheduled_ride as the undo path.

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

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

One sentence with the precondition front-loaded and the conditional parameter choice after the colon; no filler.

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

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

No output schema exists, yet the description never says what a successful booking returns or how it relates to list_scheduled_rides. That is the only material gap for a mutation 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 coverage is 67%, and the description adds real decision logic: use confirmed_max_price_toman when a range exists, otherwise accept_price_set_later: true when Snapp gave no estimate. schedule_quote_id's role is only implied by the name.

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

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

States a specific verb+resource ("Books the ride") and anchors it to the sibling that produces its input ("from get_schedule_quote"), so an agent can place it in a multi-step flow without opening the schema.

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

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

Gives an explicit precondition ("Only call after the user agreed to the time and price") plus branch-specific guidance on which parameter to pass depending on whether a price estimate existed.

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 readOnlyHint and openWorldHint, the description discloses the result content (places with coordinates) and the ranking rule (nearest to the user's current location first), which is real behavioral information an agent needs. It leaves unstated what happens when the user's location is unset or when nothing matches, which matters for an open-world search.

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 tight sentences: capability and return ordering first, usage and next step second. No filler and nothing redundant with the annotations.

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 two-parameter, no-output-schema search tool with safety already covered by annotations, the description supplies the essentials: source, scope, ordering, and workflow handoff. The only meaningful omissions are the semantics of 'limit' and the failure behavior when location is unavailable or no results are found.

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 50%: the query parameter is well documented in the schema (Persian or English, with an example), but 'limit' is not described anywhere. The phrase 'returns matching places' only weakly implies a bounded result set, so the description does not fully compensate for the gap, but the schema plus that phrasing keeps it at 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?

States a specific verb ('looks up'), resource ('an address or landmark'), geographic scope ('in Iran'), and data source ('on OpenStreetMap'), plus the ordering of results. It is clearly not a save/list tool, though it never names the closest sibling (suggest_places / list_places) to sharpen the boundary.

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

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

Gives an explicit trigger ('Use it when a place name is ambiguous') and an explicit follow-up path ('pass the chosen lat,lng to other tools or save it with save_place'). It stops short of stating when NOT to use it, e.g. when the place is already known and should go straight to preview_destination_change.

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

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

With no annotations, "Records" at least signals a state-changing operation, while the default-pickup statement discloses a meaningful downstream effect. It remains unclear whether the previous value is overwritten, whether existing quotes or rides are affected, how long the setting persists, or how lookup failures are handled.

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 short sentence communicates both the action and its consequence without filler. The core purpose is front-loaded, and the wording is efficient and easy to scan.

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

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

For a simple two-parameter setter with fully documented inputs, the description and schema together provide most of what is needed for basic selection and invocation. Missing sibling routing and mutation-scope details prevent full completeness, particularly because there are no annotations or output schema to supply additional 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?

Schema description coverage is 100%, so the baseline of 3 applies. The schema rather than the description documents saved place names, "here", coordinates, address lookup, and the optional label; the description adds no parameter-specific detail.

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

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

The description gives a specific action ("Records"), resource (the user's current location), and concrete effect ("used as the default pickup point"), so it adds value beyond the title. It does not explicitly differentiate the tool from get_current_location or save_place, and "right now" is narrower than the schema's support for arbitrary saved places, addresses, and coordinates.

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 default-pickup purpose provides ride-related context and implies setting the location before requesting or scheduling a ride. However, there is no explicit workflow guidance, prerequisite, exclusion, or direction to alternatives such as get_current_location, save_place, or search_address.

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

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

readOnlyHint=true is consistent with a read-only 'finds' operation, and the description adds value beyond the annotation by disclosing the data source (recent ride history) and the required post-call behavior (confirm with the user before saving). It does not say how many results come back or what an empty result means, which is the remaining gap.

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

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

Two tight sentences: the first defines the result and its source, the second defines the required follow-up action. Front-loaded with the outcome, zero filler, nothing redundant with structured fields.

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-required, read-only lookup with no output schema, the description conveys enough: what is returned conceptually (frequent to/from addresses from recent rides) and what to do next. The only omission is the meaning and expected range of the limit 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?

The single parameter 'limit' has 0% schema description coverage (only type/default/min/max are present) and is never mentioned in the description, so an agent gets no explanation of what it controls beyond the constraints. The description should say it caps the number of suggested addresses returned.

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

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

States a specific verb and resource: 'finds the addresses the user rides to and from most often (from their recent rides)'. This distinguishes it in substance from list_places and search_address by making clear it derives unsaved frequent addresses from ride history rather than reading stored places or searching an address book, though the contrast with those siblings is implied rather than named.

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

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

Gives a clear usage context ('so they can be saved with save_place, e.g. as home or work') and even prescribes the workflow step of asking the user which address is home vs work before saving. It does not state when NOT to use it or name a competing sibling, so it stops short of full routing 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?

With readOnlyHint=true already covering safety, the description contributes real behavioral detail: the call blocks until a state change, and it returns the current state rather than an error when the wait times out. What is not disclosed is whether the call holds a connection, any rate limiting on repeated loops, or behavior for an invalid or unknown ride_id.

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

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

Two sentences, both earning their place: the first defines the blocking behavior and return semantics, the second defines the calling pattern. The blocking behavior is front-loaded, and there is no filler or repetition of the 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 two-parameter read-only long-poll tool with no output schema, the description covers the timing and retry model well. The remaining gap is that 'returns the new state' does not hint at what the state object contains (status, driver details), which the agent would need in order to relay changes to the user without an output schema to consult.

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 ride_id parameter is documented in the schema ('omit to follow the current active ride'), but timeout_seconds has no prose at all - only a default and 5-240 bounds - and the description never mentions it. The phrase 'returns the current state when the wait times out' only indirectly conveys what the timeout controls, so the description adds little beyond the schema's 50% 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 names a specific verb and resource ('waits until the ride changes') and enumerates the exact state transitions it watches for (driver found, arrived, trip started, finished, cancelled). It implicitly separates itself from the snapshot-style sibling get_ride_status by emphasizing that it blocks until a change, though it never names that sibling explicitly.

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?

'Call it in a loop to follow a ride and tell the user each change as it happens' gives a clear operating pattern and context for use. It stops short of explicit exclusions, e.g. whether to prefer get_ride_status for a one-off check or when to stop looping (for example after finished/cancelled), so there is room left to inference.

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