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

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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 provided, so the description carries the full burden. It reveals critical behavior: no fetch mode, no currency conversion (and allows the agent to convert), optional country as Google gl, and a default baggage_buffer of 0. It also warns about blocking and what not to do afterward. The main gap is absence of side-effect or error details, but it covers the key operational quirks well.

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 several sentences long but each sentence adds value, covering purpose, usage, and key parameter details. It is front-loaded with the purpose and routing, and the structure separates concerns (usage, parameters, currency). It is not overly verbose given the 36 parameters, though it could be tightened by removing redundancies like 'currency is currency'.

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 36 parameters, no output schema, and no annotations, the description provides a solid foundation for the core use case (cheapest week) but omits many parameter semantics and does not describe the output format, pagination, or return behavior. It is complete enough for a basic call but not fully comprehensive for all configurable options.

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%, so the description must compensate. It explains route, start/end, currency, country, and baggage_buffer, but the other 31 parameters (sort, trip, cabin, proxy, adults, nearby, nights, airlines, alliance, carry_on, max_stops, price_cap, etc.) receive no semantic explanation. This leaves many parameters ambiguous for an agent, especially without an output 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 purpose: 'Cheapest-per-day calendar for a named route (up to 31 days).' It uses a specific verb (search/calendar) and a resource (route), and explicitly contrasts with search_flex ('Use search_flex for ±N around one date'), making it distinguishable from siblings.

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 gives explicit when-to-use guidance: 'Use this for the cheapest week. Use search_flex for ±N around one date.' It also provides strong negative guidance, telling the agent to stop after this tool and not follow with flex or search_flights, and warns against using a separate browser as MCP recovery. This is exemplary routing.

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, the description carries the behavioral burden. It discloses meaningful quirks: Viajante does not convert currency, baggage_buffer defaults to 0 when unnamed, and country acts as Google gl (origin market). However, it does not disclose broader behaviors such as result limits, error handling, or whether the operation is read-only, leaving important gaps.

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 compact and front-loads the core purpose in the first sentence. The remaining lines are terse and mostly high-value, though the phrase 'Currency is currency' is awkward and slightly tautological.

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 tool's complexity (37 parameters) and the absence of an output schema, the description is far from complete. It provides a high-level outcome and a few parameter notes, but omits return details, request semantics for most fields, and any guidance on failures or edge cases.

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%, so the description must compensate, but it only clarifies a few parameters: currency inference, country as Google gl, and baggage_buffer default. The other 34 parameters, including subtle ones like no_overnight, require_overnight, and proxy, remain explained only by their titles and defaults.

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 line, 'Destinations from one origin, then a priced shortlist,' clearly states the resource (destinations) and scope (one origin) with a distinct outcome. It differentiates from most siblings by implying exploration across destinations rather than point-to-point flights, though it does not name an alternative tool 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?

The description gives useful situational instructions such as 'If unknown, ask' for currency and 'omit when unset' for country, but does not say when to choose search_explore over search_dates, search_flex, or search_trip. Usage context is implied by the purpose line, not explicitly contrasted with siblings.

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, the description carries full behavioral disclosure burden. It reveals that only one shopping search is performed, that Viajante does not convert currency, that an unnamed baggage_buffer defaults to 0, and that flex-calendar misses are not the same as no_results. This is unusually rich behavioral context for a search tool.

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 core purpose is front-loaded in the first sentence, and every subsequent sentence adds a distinct behavior, default, or routing rule. The text is dense and efficient, though the final cluster of notes reads somewhat telegraphically.

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 37-parameter tool with no annotations and no output schema, the description covers usage boundaries, defaults, currency inference, country semantics, and error-handling behavior. It does not describe the return shape or authentication requirements, but the operational guidance is strong enough 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 0%, so the description compensates for the non-obvious parameters: flex is a ±N window, country is a Google gl origin market to omit when unset, baggage_buffer defaults to 0, and currency should be asked about if unknown. Many optional parameters remain undocumented, but their titles and defaults are largely self-explanatory.

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 first sentence defines the operation precisely: flex window around a date, then one shopping search on the cheapest day. It also distinguishes this tool from search_dates and search_flights by name, so an agent can tell exactly what this tool does relative to its siblings.

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 routes usage: use search_dates for a cheapest-week calendar, do not brute-force a date matrix, and fall back to a named-date search_flights when a flex calendar miss occurs. This is concrete, actionable guidance with named 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?

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses inference rules ('Currency is currency or inferred from a named origin's owned country'), constraints ('must not be guessed'), defaults ('Unnamed baggage_buffer is 0'), and specific behaviors like 'Prefer bags / carry_on on the shopping request' and 'max_stops is 0, 1, or 2.' It also warns about environment requirements for fetch=detail. This goes well beyond a basic mutation hint.

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 dense block of text but every sentence carries useful information. It front-loads the core purpose and alternative routing first, then dives into specifics. It is longer than ideal but not verbose – each clause adds a constraint or default an agent must know. The structure could be improved with bullet points, but it remains efficient and scannable.

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 tool's complexity (35 parameters, no output schema, no annotations), the description covers many critical aspects: route format, currency/country inference, bag handling, max_stops, and environment prerequisites. It does not describe the return value structure, which is a gap since there is no output schema, and some optional parameters (e.g., 'proxy', 'depart_window') lack explanation. However, the coverage is strong for the most consequential fields, making it largely complete 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 0%, so the description must compensate. It clarifies key parameters: 'routes' format (ORIGIN-DEST:YYYY-MM-DD), currency inference rules, country as Google gl, baggage_buffer default, and max_stops allowed values. However, many parameters like 'proxy', 'nearby', 'exclude_via', 'depart_window', etc. are left undefined; their titles are self-explanatory or not, and the description doesn't add meaning for them. Partial compensation for a 35-parameter 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 opens with a specific verb and resource: 'Search Google Flights for named routes and dates.' It immediately distinguishes itself from siblings by naming search_dates and search_flex as alternatives for different use cases, so an agent can tell which tool to pick without opening schemas.

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 alternatives: 'Use search_dates for the cheapest week and search_flex for ±N days.' It also gives prerequisites (fetch=detail requires browser extra and Chromium) and instructs to ask when unsure about currency or country, so the agent knows exactly when to call this tool vs 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?

With no annotations provided, the description carries full responsibility. It discloses that the tool does not perform currency conversion and only returns quotes as provided by the provider, which is valuable behavioral insight. It also warns against inventing currency codes, addressing a potential misuse. It does not mention response format or pagination, but the critical behavioral notes are present.

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 compact and front-loaded with the most critical information: 'Hotel search' first, then the currency requirement. Every sentence provides new information; there is no repetition or filler. It uses paragraphs effectively to separate key constraints from detailed behavior.

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 11 parameters, 3 required, 0% schema coverage, and no output schema, the description is quite complete for the core use case. It highlights the most critical constraint (currency) and warns against common errors. It does not explain each parameter or the return format, but the focus on the critical distinction from flight search is sufficient for an agent to call it correctly in most scenarios.

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 clarify parameter meaning. The description emphasizes that 'currency' is required despite the schema listing it as optional (default null), which is a critical clarification. It also implicitly clarifies that 'location' is a hotel destination, not an airport. However, many parameters like 'top', 'rooms', 'adults' remain unexplained, but the essential parameter (currency) is well addressed.

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 begins with 'Hotel search', a specific verb-resource pair that clearly distinguishes it from sibling tools like search_flights or search_trip. It further defines the scope by specifying currency requirements and its distinction from flight-related searches, making it immediately recognizable.

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 that currency is required and clarifies that no origin airport is involved, which helps distinguish from flight search tools. It does not explicitly name alternatives, but the key constraint (currency required, no origin) is clear enough to prevent misuse. There is no explicit 'when not to use' guidance, but the emphasis on currency and the absence of origin implies the tool is for hotel-only searches.

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, the description carries the burden of behavioral disclosure, and it adds meaningful context: currency follows flight origin or an explicit code, Viajante does not convert, the same currency is passed to hotels, and unnamed baggage_buffer defaults to 0. These are non-obvious behaviors beyond what the schema reveals, though it does not describe output shape or other side effects.

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 short and mostly front-loaded with its core concept, but several phrases are cryptic and loosely connected: 'Flights then hotel,' 'Unnamed baggage_buffer is 0,' and 'Prefer bags / carry_on on the shopping request' are jargon-heavy and jump between topics without clear organization. Conciseness is achieved, but at some cost to readability.

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 tool with 38 parameters, no output schema, and no annotations, this description is far from complete. It covers currency, country, and baggage quirks, but leaves the overall search behavior, relationship between routes and location, result format, and most optional filters effectively undocumented. A higher score would require broader and clearer operational 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 0%, so the description must compensate for 38 largely unexplained parameters. It does add value for currency, country, baggage_buffer, bags, and carry_on, but the majority of parameters—routes, location, top, sort, cabin, rooms, adults, source, and many filters—receive no semantic clarification beyond their names and defaults.

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 begins with 'Flights then hotel,' which signals that this tool searches for bundled flight-and-hotel trip options. This distinguishes it from sibling tools like search_flights and search_hotels, though the phrasing is terse and could be more explicit about the tool's full purpose.

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 situational rules: ask when currency is unknown, do not rely on Viajante to convert, prefer bags/carry_on params, and omit country when unset. However, it never explicitly says when to choose search_trip over alternatives such as search_flights, search_hotels, or search_explore, so the selection guidance is implied rather than stated.

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