travel

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

Annotations only cover the safety profile (readOnly=false, idempotent=false, openWorld=true). The description goes well beyond that, disclosing that payment and identity verification must occur on the web, the free/no-trial/no-subscription account model, and a link expiry window (~30 minutes). These are behavioral facts an agent could not derive from 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?

It is long, but the length is justified by nested object semantics and multiple intent branches, and it is front-loaded with purpose and when-to-call before the per-type detail. Headers make it scannable, though the repeated 'CRITICAL' emphasis and restated passenger-count warning add some redundancy.

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

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

For a mutation tool with a nested object parameter, 0% schema coverage, and no output schema, the description supplies everything needed: the return value (deep_link), the per-intent payload contract, the reply-format requirements, and the expiry behavior. Nothing an agent needs to call this 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?

With 0% schema coverage the description carries the full burden, and it does so thoroughly: it enumerates the intended intent_type values, dictates exactly-one selection, and specifies the nested offer_data shape per type including passengers/adults/rooms/check_in/check_out. The one gap is that the schema enum still lists 'activity', 'event', and 'experiences' while the description forbids calling for those, leaving an unresolved mismatch.

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 opening sentence names a specific verb+resource ('Create a booking intent') and states the concrete output ('returns a deep-link the user clicks to complete the booking on autonomad.ai'). It explicitly separates itself from the sibling search_* tools by declaring it is the only booking path and that direct MCP booking is not permitted.

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 'WHEN TO CALL' section gives explicit preconditions (only after the user picked a concrete flight/hotel/trip) and explicit exclusions (do not call for browsing, or for activities/events alone). It also names alternatives and the correct moment to route users to the add-ons page, so nothing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by specifying exactly what data is returned (version, mode, API base, tool list), which helps the agent understand the scope of the read operation.

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 concise: two sentences with no extraneous information. The first sentence states the action and outputs, the second provides usage context. Front-loaded and 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?

Given no output schema, the description adequately explains what the tool returns (version, mode, API base, tool list). The sibling tools are all search/create, so this metadata tool's role is clear and complete for the agent's needs.

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 zero parameters, so schema coverage is 100%. The description does not need to add parameter details. Baseline for 0 parameters is 4, and the description fulfills that.

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 returns specific data: server version, mode, API base, and tool list. It uses a specific verb ('Return') and resource, and it is well-differentiated from sibling tools which are all search/create operations.

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 states when to use the tool: 'to confirm tool-schema compatibility before issuing a sequence of calls.' While it does not mention when not to use or alternatives, the context makes it clear this is a setup/info tool distinct from others.

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, openWorldHint, etc. Description adds return types (photos, ratings, durations, pricing) but not deeper behavioral context like 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 with zero wasted words, front-loaded with core purpose, followed by usage guidance.

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?

Covers purpose, source, and output sufficiently for a search tool with annotations and sibling context. Missing output schema but description compensates with result content details.

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%, but description maps all parameters (city, date range, category) and gives category examples. Lacks date format or allowed category enumeration.

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 searches for tours, experiences, and attractions via Viator, with filtering and example categories. It distinguishes from sibling search tools (dining, events, flights, etc.) by focusing on activities.

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?

Provides explicit when-to-use scenarios (plan day activities, book experiences, etc.). Does not explicitly mention when not to use, but implicit from sibling context.

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 signal read-only and idempotent behavior, so the bar for extra value is lower. The description adds meaningful context: 'indicative availability' (not guaranteed), no reservation placement, and direct user booking. This goes beyond the annotation flags to clarify actual limitations.

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 deliver full scope, behavior, and usage guidance with zero redundancy. The most important constraint (PLANNING ONLY) is front-loaded in the second sentence.

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 planning-only search tool with 7 parameters and no output schema, the description adequately conveys what the tool does, what it returns ('restaurant details and indicative availability'), and how it should be used. Minor missing details like result pagination or ordering 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 description coverage is only 29%, so the description must compensate. It lists all seven parameters, which is helpful, but it does not explain their semantic meaning beyond the names. The schema already covers date/time format and price range enum, but party_size and cuisine are left implicit.

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

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

The description specifies a clear verb-resource pair ('Search restaurants and dining options') and enumerates searchable criteria, making it distinct from sibling tools like search_hotels or search_events. The scope is precise and immediately understood.

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?

It explicitly states when to use ('when the user wants to find, compare, or shortlist somewhere to eat') and provides a strong exclusion ('PLANNING ONLY', 'does not place reservations', 'user completes any booking directly'). It does not name an alternative tool, but the contrast between planning and booking is implicit and sufficient.

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 read-only, idempotent, and non-destructive behavior. The description adds value by revealing data sources (Ticketmaster + SeatGeek) and filter dimensions, going beyond 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?

Two sentences: first defines the action and scope, second lists filters and usage case. Every phrase earns its place, no redundancy.

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

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

For a 5-parameter search tool with no output schema, the description covers purpose, filters, and when to use. It could mention output behavior (e.g., returns event listings) but likely sufficient for an agent.

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

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

With 0% schema coverage, the description effectively compensates by explaining each parameter: city, date range, category (with examples), and keyword (with examples). However, it does not clarify date format or whether category values are case-sensitive/enum-specific.

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 searches for live events like concerts, sports, theater, etc., and specifies data sources (Ticketmaster + SeatGeek). It distinguishes from sibling tools focused on other activities (dining, flights, etc.).

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 this when the user wants tickets to a concert... or any live event during their trip,' providing clear context. It does not include exclusions or alternatives, 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 readOnly and idempotent. Description adds context: real-time pricing from 800+ airlines (Duffel), schedules, stops. No contradiction with 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 sentences with maximum information density. First sentence lists core parameters, second adds source and data richness. No fluff.

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?

Describes return content (flights, pricing, schedules, stops). No output schema exists, but the description gives a reasonable picture of what the agent will receive. Could mention pagination or limits.

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 the schema fully documents parameters. The description only summarizes key parameters without adding new semantic meaning 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 it searches airline flights/airfares between two cities with specific parameters. It distinguishes from sibling tools (e.g., search_hotels, search_transport) by focusing on flights.

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 'Use this when the user wants to book a flight, fly somewhere, find airfare, or compare airlines.' Lacks negative guidance, but given sibling diversity, it's clear enough.

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 declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint false. Description adds that it returns matching properties with rates, photos, and availability across 2M+ properties (LiteAPI), disclosing the data source and result contents. 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?

Three well-organized sentences: first states purpose and filters, second describes returns, third gives usage guidance. Every sentence adds value, no fluff. Front-loaded with key 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 search tool with 9 parameters, high schema coverage, no output schema, the description adequately explains return content (rates, photos, availability) and data source. It covers all necessary context for an agent to use correctly.

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

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

Input schema covers 89% of parameters with descriptions. Description lists filters, echoing schema, and provides examples for amenities (e.g., 'wifi, gym, pool'). While not adding deep semantics, it groups and clarifies. Schema coverage is high, so 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?

Description clearly states the tool searches hotels, lodging, accommodations, resorts, etc. It lists specific filters (city, country, dates, room type, price, star, amenities) and indicates returns include rates, photos, availability. This differentiates it from sibling tools like search_flights.

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 guidance: 'Use this when the user wants to book a hotel, find a place to stay, compare lodging options, or pick a resort.' This provides clear context, though no explicit when-not-to-use statements (but implications from sibling names are clear).

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