Sail

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context via 'current' (indicating live, time-sensitive pricing) and 'through Sail' (provider scope), but does not disclose ordering, currency, or failure handling. With annotations this is an acceptable level of transparency.

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 action and includes the resource, scope, and time-sensitivity. 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 read-only comparison tool with rich input schema, annotations, and an output schema, the description provides sufficient context about what the tool does and what data it returns. Minor gaps remain around when to use it versus plan_trip and how the resolved places should be obtained, but these are largely inferable from sibling names and schema descriptions.

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

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

The input schema has 100% description coverage, documenting lat/lng ranges, placeId provenance, and the required pickup/destination objects. The description adds no additional parameter-level detail, but none is needed given the thorough schema.

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

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

The description states a clear action ('Compare'), a specific resource ('current ride-hailing prices and pickup times'), and a scope ('providers available through Sail'). It does not explicitly contrast itself with sibling tools like plan_trip or plan_trotro_route, so it stops short of full sibling differentiation.

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

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

The description implies when to use the tool—when comparing ride-hailing options—but gives no explicit guidance on when to choose it over siblings, nor does it mention exclusions or prerequisites. An agent must infer the appropriate usage from the name and the sibling list.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context such as output structure, data sources, or side effects; it mostly restates the tool's purpose without contradicting the annotations.

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

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

Two concise sentences with no filler: the first states the core function, and the second adds important selection guidance by labeling the tool as the default multimodal option. Frontal loading is effective.

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 schema is detailed, output schema exists, and annotations cover the safety profile, so the description does not need to explain return values or side effects. The only minor gap is that it does not explicitly route the agent to single-mode siblings, but the sibling list and 'multimodal' language make that omission non-critical.

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

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

Schema description coverage is 100%, with pickup and destination documented as 'Resolved pickup place' and 'Resolved destination place' and lat/lng ranges explained. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description uses a specific verb plus resource: 'Compare ride-hailing and trotro options together.' It clearly identifies the tool as the multimodal trip planner and distinguishes it from siblings like compare_rides and plan_trotro_route, which are single-mode 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 phrase 'This is the default tool for multimodal trip planning' gives clear context for when to choose it, especially relative to single-mode siblings. However, it does not explicitly state when not to use it or name the alternatives for ride-hailing-only or trotro-only requests.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe/read-only behavior is covered. The description adds value by disclosing what the returned plan includes—fares, walking legs, transfers, and boarding instructions—which gives the agent useful expectations beyond the annotations.

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

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

The description is a single well-structured sentence that front-loads the action and resource, then packs in relevant specifics without any filler. 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 rich annotations, full schema coverage, and the presence of an output schema, the description is largely complete for correct invocation. It could be slightly stronger with an explicit distinction from plan_trip or mention of trotro-specific limitations, but nothing essential is missing.

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

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

Schema description coverage is 100%, with pickup and destination both fully documented as lat/lng coordinate objects. The description does not add parameter-level detail, but it does not need to because the schema already carries the semantic weight.

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 ('Plan') and resource ('public transport journeys by trotro'), and adds concrete detail about what the plan includes: fares, walking legs, transfers, and boarding instructions. This clearly distinguishes it from siblings like plan_trip and compare_rides by specifying the trotro mode.

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 it should be used when the user wants trotro-based public transport planning, but it does not explicitly state when to choose this over plan_trip or when not to use it. No alternatives or exclusions are named, leaving some 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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the resolution output contents but does not disclose error handling or behavior for invalid IDs; this is minor given the concise scope and strong annotations.

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

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

A single sentence that front-loads the action and input, then immediately states the output fields. There is no filler, redundancy, or unnecessary detail.

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

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

With only one parameter, an output schema available, and annotations covering side effects, the description fully covers the input origin, purpose, and output shape. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%: the placeId property is already documented as 'Place ID returned by search_places'. The description repeats this origin without adding additional parameter semantics beyond the schema.

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

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

The description uses a specific verb ('Resolve') with a clear resource ('place ID from search_places') and enumerates the output (exact name, address, coordinates). It clearly differentiates this from sibling tools like search_places, which finds candidates, and trip-planning tools.

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

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

The phrase 'from search_places' explicitly establishes the input source and implies the intended workflow: call search_places first, then resolve a selected ID. It does not explicitly state when not to use it or name alternatives, but the contextual chain is 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 declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the description does not need to repeat those. The description adds no extra behavioral detail, such as result limits or ordering, but it also does not contradict the annotations. This is adequate given the annotation coverage.

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

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

The description is two short sentences with no filler. It front-loads the core action and then adds a necessary workflow pointer, making every word earn 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 output schema and annotations, the description covers the essential workflow purpose and next step. Minor gaps remain around default country filtering and radius meaning, but these are partially inferable from the schema defaults and are not critical for correct invocation.

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

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

Schema coverage is only 50%, with query and near's lat/lng described but countryCode and radiusMeters left undocumented. The description does not compensate for these gaps by explaining defaults, radius meaning, or country filtering behavior. An agent would need to infer the semantics of countryCode='gh' and radiusMeters without additional guidance.

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 ('Search') and a clear resource ('pickup or destination places'). It also references the downstream workflow step, which distinguishes it from sibling tools like resolve_place and plan_trip.

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 explicitly says to use resolve_place on the selected result before planning a trip, giving clear sequential context. It does not enumerate when to avoid this tool, but the workflow guidance is meaningful and sufficient for basic routing.

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