travel

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

The description adds significant behavioral context beyond annotations: it discloses the need for payment/identity verification on the web, the return of a deep-link, the automatic free trial trigger, the link expiry window, and the requirement to include passenger counts. Annotations (readOnlyHint=false, destructiveHint=false) are consistent and not contradicted.

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 long but well-organized with sections (WHEN TO CALL, INTENT TYPE GUIDE, USER-FACING REPLY REQUIREMENTS). It could be slightly more concise by trimming some redundant phrasing, but the structure helps readability. Every section adds value despite the length.

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 complexity and lack of output schema, the description is thorough: it covers deep-link generation, free trial, link expiry, data requirements, and user-facing reply formatting. It also addresses edge cases like activities/events and single vs. combined intents, leaving no critical gaps for an agent to misuse.

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 description coverage, the description fully compensates by explaining each intent type variant, detailing the offer_data structure for flight/hotel/trip, and specifying required fields like passengers, check_in/check_out, adults, rooms. It also implicitly addresses expires_minutes by mentioning link expiry (~30 minutes).

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 creates a booking intent returning a deep-link, distinguishing it from sibling tools like search tools by explicitly saying 'ALWAYS call this instead of trying to book directly through MCP'. It specifies the verb 'create booking intent' and the resource 'deep-link', making the purpose 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?

The description provides explicit when-to-call (after user picks concrete flight/hotel/trip) and when-not-to-call (for browsing, activities/events alone). It also gives an intent type guide with specific conditions for each type and warns against generating two intents for the same trip, offering clear alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds specifics on what is returned (version, mode, API base, tools), providing useful 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?

Two sentences, front-loaded with key information. Every sentence adds value: first states returns, second states purpose. No extraneous text.

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 introspection tool with no input schema and no output schema, the description fully explains what is returned and its utility. No gaps.

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?

No parameters exist; schema coverage is 100%. Description correctly focuses on the tool's return value without needing to add parameter details.

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?

Clearly states verb 'Return' and specific resources: version, mode, API base, and list of tools. Differentiates from sibling tools which are for searching or creating specific entities.

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 utility: 'confirm tool-schema compatibility before issuing a sequence of calls.' Provides clear context on when to use, though no explicit exclusions or alternatives are given.

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 idempotentHint, so the description adds value by specifying return fields (photos, ratings, durations, pricing) and the vast scope (200K+ activities). 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?

The description is three sentences, front-loaded with the primary action, followed by key features and use cases. No extraneous 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?

Given four parameters and no output schema, the description covers the tool's purpose, inputs, and outputs well. It could be slightly more precise on parameter details, but overall it is sufficiently complete.

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

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

Schema coverage is 0%, so the description must compensate. It explains filtering by city, date range, and category with examples, but doesn't detail date format or the distinction between required and optional parameters beyond mentioning 'date range'.

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 activities via Viator, listing specific categories and features. It distinguishes from sibling tools like search_dining and search_events 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?

The description explicitly advises using this tool for planning day activities, finding tours, or filling itineraries. While it doesn't explicitly state when not to use, the context is clear and differentiates from other search tools.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds 'partnerships in progress' which hints at data limitations, but no additional behavioral details like rate limits or auth needs. Adequate but not rich.

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

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

Two sentences, no fluff, lists all criteria concisely. Second sentence provides usage guidance. 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?

With 7 parameters, 2 required, no output schema, the description covers purpose and usage but lacks detailed parameter guidance. Partnerships note adds context. Adequate for a search tool but could be more 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 coverage is low (29%). Description lists all parameters but doesn't explain formats (except date/time via schema) or constraints (e.g., price_range enum, neighborhood format). Minimal value added over schema for most parameters.

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 restaurants, dining options, and reservation availability, distinguishing it from sibling tools like search_activities, search_events, etc. It uses specific verbs and resources.

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 lists when to use (find restaurant, book dinner, plan meal, get reservations, pick place to eat) and notes partnerships in progress, giving context. Doesn't explicitly exclude alternatives but sibling differentiation 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 indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value by disclosing the catalog sources (Ticketmaster + SeatGeek) and available filters. 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 concise sentences with no wasted words. First sentence states purpose and scope; second sentence details filters and usage. Information is 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?

While the description covers purpose and parameters, it lacks details about the output (e.g., format, pricing info, ticket links). Given no output schema, this is a minor gap but not critical 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?

With 0% schema coverage, the description compensates by explaining each parameter: city, date range, category (with examples like music/sports/theater), and keyword (artist/team/show). This adds meaning beyond the raw 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 specifies the verb 'Search' and the resource 'live events, concerts, sports games, theater, comedy, and shows' with a clear scope (city + Ticketmaster + SeatGeek catalog). It distinguishes from siblings like search_activities or search_dining.

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: 'when the user wants tickets to a concert, a sports game, a Broadway show, or any live event during their trip.' It does not mention when not to use or alternatives, but the sibling context implies correct usage.

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, idempotentHint, and destructiveHint. The description adds that results include 'real-time pricing, schedules, and stops' and uses IATA codes, which goes beyond the annotations. 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?

Description is three sentences, front-loaded with the core action and parameters, then details and use-case guidance. Every sentence is valuable and no redundant or extraneous text.

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 8 parameters and no output schema, the description covers the essential purpose and inputs. It mentions real-time pricing and 800+ airlines, which is helpful. However, it doesn't explain output format (e.g., list of flights with prices) or pagination. Still, it's mostly 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 100%, so the description adds minimal new information about parameters. It mentions 'by date, cabin class, and number of passengers' but these are already clear in schema. Thus, 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 searches flights/airfares with specific parameters (date, cabin, passengers) and covers 800+ airlines using IATA codes. It distinguishes itself from sibling tools like search_hotels and search_transport, so the agent knows exactly what it does.

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 to book a flight, fly somewhere, find airfare, or compare airlines.' This gives clear positive guidance. While it doesn't mention alternatives like create_booking_intent for booking, it adequately informs when to select 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?

Adds context beyond annotations by specifying returns (properties with rates, photos, availability) and data source (LiteAPI). Annotations already declare read-only, idempotent, non-destructive behavior.

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

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

Two well-structured sentences: first states purpose and filters, second describes returns and usage. No wasted words, information is 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?

For a search tool with 9 parameters (2 required) and no output schema, the description provides a solid overview of returns and data source. Sufficient to set expectations without covering every edge case.

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?

Description summarizes the filter parameters but does not add significant meaning beyond the input schema, which has 89% coverage. The listing of filter categories is helpful but not essential.

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 identifies the tool as searching for lodging accommodations, lists relevant filters, and is distinct from sibling tools like search_flights and search_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?

States explicit use cases ('when the user wants to book a hotel, find a place to stay, compare lodging options...'). Does not mention when not to use, but the context of sibling tools implies 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns 'indicative quotes for planning only' and that 'in-app booking is not yet live,' which aligns with readOnlyHint and idempotency. This additional context is valuable 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 concise: two sentences plus a NOTE. It front-loads the action ('Search ground transportation') and scope, immediately followed by specifics and usage guidance. No extraneous words.

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 has 8 parameters, no output schema, and low schema coverage. The description provides high-level purpose and limitations but does not explain parameter interactions, return format, or how to combine with flight arrival for timed planning. Given complexity, it is somewhat incomplete.

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 25% (2 of 8 parameters have descriptions). The description does not elaborate on parameters such as passengers, vehicle_type, pickup_datetime, or pickup_location. It mentions 'timed to a flight arrival' but does not explain how that maps to parameters. With low coverage, the description should compensate but does not.

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 starts with 'Search ground transportation', naming specific types (rideshare, car rental) and examples (Uber, Lyft, Hertz). This clearly distinguishes the tool from sibling tools like search_flights and search_hotels, which focus on other travel domains.

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: 'when the user wants to scope a rental car, an airport transfer, or rideshare to/from their hotel.' It also includes a NOTE about indicative quotes and incomplete booking, setting expectations. However, it does not mention when not to use it or suggest alternatives.

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