trip-logistics-assistant

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

The description states 'starts a claim', implying the tool modifies state (writes) by initiating a claim process. However, annotations include readOnlyHint: true, indicating the tool is read-only and does not mutate state. This is a clear contradiction.

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; the first states purpose and key benefit, the second lists usage conditions. No redundant information. Front-loaded with critical details.

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

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

While the description covers purpose and conditions, it lacks details on output/return values (no output schema). The contradiction with annotations undermines trust. Some expected details (e.g., compensation amount limits) are mentioned but overall incomplete for agent decision-making.

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

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

Schema coverage is 100% (both parameters documented). The description adds context by listing example disruptions mapping to the 'issue' enum, but does not provide significant new detail beyond the schema.

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

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

The description clearly states the tool checks flight compensation eligibility and starts a claim, with specific verb 'checks' and resource 'flight compensation'. It distinguishes from sibling tools (travel booking tools) by listing specific disruption types.

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

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

The description explicitly lists when to use: delays (3+ hours), cancellations, denied boarding, missed connections, luggage issues, and flights up to 3 years ago. It also notes 'Free eligibility check, no-win-no-fee claim handling'.

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

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

Annotations indicate readOnlyHint and openWorldHint. The description adds value by explaining that results include typical price ranges and a link to live offers with free cancellation, providing behavioral context beyond the annotations. It does not contradict annotations.

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

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

The description is two sentences long, front-loaded with the main purpose, and every sentence provides essential information without redundancy. It is efficiently structured.

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

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

Given no output schema, the description explains return value (price ranges, link to offers) and mentions free cancellation. It covers the core functionality but could mention potential limitations (e.g., region-specific availability). Still, it is fairly complete for a search tool.

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

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

Schema coverage is 75% (3 of 4 parameters have descriptions). The description adds meaning by linking 'location' to airport or city and dates to pickup/dropoff, but does not address the undocumented 'driver_age' parameter. The description partially compensates for the gap but not fully.

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

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

The description clearly states the verb ('Finds') and resource ('rental car options at an airport or city for specific dates'), and mentions typical price ranges and a direct link to live offers. It distinguishes from siblings which cover different types of travel services (e.g., tours, transfers).

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 'Use for any car rental / rent a car / car hire request, including when the user asks to book a rental car', providing clear context. It does not specify when not to use or mention alternatives, but the sibling tools are distinct, making misinterpretation unlikely.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so description does not need to restate safety. It adds value by mentioning real catalog prices, instant delivery, and types of plans (unlimited, combo). No contradictions.

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

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

Two sentences are efficient and front-loaded with the main action. The second sentence lists use cases without excessive detail. Could be slightly more structured, but overall concise and clear.

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, so description explains return content: data packages by GB, validity days, unlimited/data+calls+texts options, and pricing in USD. This gives a solid understanding of what the tool returns. Annotations cover read-only and open-world aspects, making it fairly 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?

Input schema covers 100% of parameters with descriptions (destination, days). The description reinforces that destination is a country/region in English and that days is optional for filtering. It provides usage context but does not add significant new 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?

Description clearly states the tool finds prepaid travel eSIM data plans for a destination, listing key attributes (prices, data packages, validity, options). It distinguishes from siblings (e.g., car rentals, tours) by focusing exclusively on eSIM 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?

Explicitly states when to use: for buying eSIM/SIM, getting mobile data abroad, avoiding roaming charges. Examples like 'eSIM for Italy' clarify typical queries. Does not explicitly state when not to use, but sibling tools cover different domains, so confusion is unlikely.

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

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

Annotations already indicate readOnlyHint=true (safe read) and openWorldHint=true. The description adds value by disclosing that results have a flat daily rate per bag and include insurance. This goes beyond annotations, though it could mention pagination or result 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?

Two sentences, front-loaded with core functionality in the first sentence, usage guidance in the second. No redundant or unnecessary words. Highly efficient.

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

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

For a simple search tool with two parameters and no output schema, the description covers purpose and usage well. It misses details on output format or result behavior, but annotations (openWorldHint) and the tool's simplicity make this acceptable.

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

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

Input schema covers both parameters with descriptions (100% coverage). The tool description adds little new information about parameter semantics beyond the schema; it mainly reinforces the 'near' parameter as optional landmark. Baseline 3 is appropriate.

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

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

The description clearly states the tool finds bookable luggage storage near the user's location, listing examples of locations (shops, cafes, hotels) and specific use cases (before check-in, after check-out, layover, day trip). This distinguishes it from sibling tools which cover flights, car rentals, eSIM, tours, and transfers.

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 'Use for any request to store / drop off / leave bags or luggage in a city' and provides example scenarios. While it does not state when not to use or name alternatives, the sibling tools are clearly different domains, so the context is sufficient for correct tool selection.

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

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

Annotations already declare readOnlyHint and openWorldHint. Description adds that it returns indicative prices, ratings, and booking links, and clarifies it is not for live-guided tours, providing additional 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?

Two sentences: first sentence defines scope and outputs, second sentence clarifies limitations. No unnecessary words, well front-loaded.

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

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

Moderate complexity with 3 simple params and no output schema. Description adds clarity on what is returned and exclusions, complementing annotations and schema well.

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

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

Schema coverage is 100% with descriptions for each parameter. Description adds minimal context beyond schema (e.g., location is city, interest is optional). Baseline 3 is appropriate as description does not significantly enhance parameter understanding.

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 explicitly states it finds bookable attraction tickets and self-guided audio tours, with specific verb 'Finds' and resource. It distinguishes from live-guided tours, clarifying scope.

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 says when to use (for tickets/audio tours) and when not (live-guided tours), providing clear context and exclusion.

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 (readOnlyHint=true) already indicate no state change. Description adds that no instant quotes are given and returns a link and description of the marketplace. This provides some behavioral context beyond 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?

Three sentences, front-loaded with key action. No redundant phrasing. Efficiently packs purpose, usage, and limitation.

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, so description explains return value (marketplace description and link). Covers main flow for a simple informational tool. Lacks error handling or edge cases, but acceptable for its 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 has 3 params with 67% description coverage. Description adds context for 'from' and 'to' by mentioning pickup and optional destination, but 'passengers' is not elaborated. Adequate but not compensatory.

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 it 'Books private transfers' and lists specific types like airport transfer, taxi, chauffeur, city-to-city, and minibuses. It differentiates from siblings such as search_car_rentals and search_tours by specifying private ground transportation.

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 mentions 'Use for any request to book a transfer, taxi or driver pickup.' Also clarifies limitation: 'No instant quotes — carriers send offers after the route is entered on the page.' Lacks explicit when-not-to-use, but coverage is clear.

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