viajante

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: it computes locally, it 'does not invent seats', it distinguishes confirmed vs estimated/user_supplied evidence, and it discloses an output rule ('unnamed cash_price omits cpp_cents'). That is meaningful extra context, though it doesn't address edge cases like what happens with an invalid or unverifiable offer.

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 tight paragraphs with the core purpose front-loaded and constraints following. The telegraphic style ('Does not invent seats', 'Unnamed cash_price omits cpp_cents') is dense but every clause adds a rule; no filler sentences.

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?

An output schema exists, so return-value detail is correctly omitted, and the description covers the complex nested input and evidence semantics that the schema can't express. It falls short only on balances/currency semantics and on how evidence tiers map to the resulting comparison, minor gaps for a read-only, idempotent 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 0% and the required 'offer' param is an opaque object with additionalProperties:true, so the description carries real weight by enumerating required offer keys (origin, destination, departure_date, program, points, evidence) and the evidence-source rule. It partially covers cash_price ('unnamed cash_price omits cpp_cents') but says nothing about balances or currency, leaving two of four parameters undocumented anywhere.

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+resource (compare a named award offer to cash) and adds a scope qualifier ('locally'), which tells the agent the computation is offline and no live inventory is fetched. No sibling tool in the list performs award-vs-cash comparison, so differentiation is implicit rather than stated, keeping this just short of a 5.

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 gives input-validity rules ('offer must include origin, destination, departure_date, program, points, and evidence', 'confirmed evidence needs a named source') and a caution ('Do not treat estimated or user_supplied as live inventory'), which implies when the tool is appropriate. However, it never says when to choose this over recheck_offer, verify_answer, or other siblings, so usage is inferred rather than instructed.

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 readOnly, idempotent, non-destructive and non-open-world behavior, so the safety profile is covered. The description adds genuinely new context: it is local, returns a {"guide": markdown} payload, and 'may run during a search' — a hint about possible invocation timing, though that phrase is vague and never explained.

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?

Very short and front-loaded: identity/equivalence first, then the audience condition, then the return shape. The trailing fragment 'Local; may run during a search' is terse to the point of ambiguity, which costs a point.

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 zero-parameter, read-only tool with an output schema and full annotation coverage, the description supplies everything essential: what it returns, the resource equivalent, and the client condition. The only incompleteness is the unexplained 'may run during a search' behavior.

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 tool takes zero parameters, so there is nothing for the description to document; the schema is empty and fully covered. Baseline of 4 applies since no parameter ambiguity exists.

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 identifies exactly what is returned: the long operational guide as markdown, equivalent to the viajante://guide resource. No sibling tool serves a comparable purpose, so there is nothing to disambiguate against, but the retrieval verb is only implicit and the guide's subject matter is not stated.

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 gives an explicit selection condition: 'For clients that do not read MCP resources,' which implies the resource is the preferred path when available. That is clear when-to-use guidance, though it does not say what to do for clients that do read resources or note any other constraints.

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?

Beyond the annotations (readOnlyHint/idempotent/openWorld), the description discloses a lot the structured fields do not: lock acquisition on the expensive path, the mismatch conditions (occupancy_mismatch, dates_mismatch, property_mismatch), echo-unknown and partial-quote semantics, and that reads do not evict stored searches while unknown/evicted ids return nothing. This is unusually rich 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?

The purpose is front-loaded, but the body collapses into long run-on sentences ('That quote is not the original stay when the city matches more than one place, the returned coordinates do not match...'), which makes the mismatch rules harder to parse than necessary. Information-dense but structurally weak.

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 an output schema present, return values need not be explained, and the annotations plus description cover the safety profile and edge cases well. The remaining gap is the provenance/format of selection_id, which matters because it is the only required parameter.

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 carries the load, and it does explain room_rates thoroughly (default false, cost/lock implications of true). However selection_id is only hinted at via 'this process returned' and is never defined as the id from a prior search result, leaving one of two parameters underspecified.

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 and resource ('Read a hotel offer this process returned') and scopes it to offers already produced by the search flow, which implicitly separates it from the search_* siblings. It is clear, but it never names a sibling (e.g. recheck_offer, search_hotel_rooms) to reinforce the boundary, so it stops short of a 5.

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 gives explicit operating conditions for the room_rates flag: false returns the stored quote, does not search, and may run during another search; true requests a separate USD quote and takes the one-search lock. That is clear when-to-use guidance, though it never states when NOT to call this at all versus using a sibling 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?

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower; the description still adds two facts beyond them — "No personal paths" (no path leakage in the response) and "May run during a search" (concurrency safety). "No network" partially duplicates openWorldHint=false, so this is value-add rather than fully new 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?

It is short, and the resource list is front-loaded, but the terse telegraphic style leaves the middle sentence ("an npm MCP does not upgrade a separate uv tool installation") cryptic in isolation. Every sentence is relevant, yet the structure costs clarity that a few more words would have bought cheaply.

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?

An output schema exists, so return values need not be described, and there are no parameters to document. For a trivial zero-arg diagnostics call, the description supplies purpose, timing, and side-effect profile — everything needed to invoke it correctly, with only the interpretation of the version results left implicit.

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 tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. No parameter semantics are needed or missing.

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 names the exact resources returned — the executing package version, Python version, and hotel schema version — which pins the purpose despite the fragmentary, verb-less phrasing. It is clearly distinct from every sibling, which are all search/lookup/validation tools, though it never explicitly says so. An agent can tell what it gets without opening the output schema.

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?

"Check before searches" gives explicit timing guidance, and the npm/uv sentence explains why a version check matters (an npm-installed MCP won't upgrade a separate uv tool install). "May run during a search" also reassures that call placement is flexible. It stops short of saying what to do with the version output, but for a zero-arg diagnostic tool this is solid 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?

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?

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description's one real addition is the staleness caveat 'Local ... not live', which usefully warns the agent the data is static, but it says nothing about freshness dates, coverage of programs, or rate 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 very short sentences with no padding, and the disqualifying condition is front-loaded. The first sentence is a verbless fragment, which slightly hurts readability but not economy.

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?

An output schema exists so return values need no explanation, but for a 3-parameter tool with zero schema descriptions the description supplies no parameter meaning and only the barest usage boundary. It is not complete enough to invoke confidently without opening the schema.

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% and the description explains no parameters at all. 'balances' in particular is undocumented and non-obvious (an optional array, semantics unknown), and there is no hint about the units or format expected for 'points' or 'program'.

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 fragment 'Local card-to-program transfer table' identifies the resource (credit-card-to-loyalty-program transfer ratios) but never states an action verb and never names or contrasts the closest sibling, compare_awards. An agent must infer from the title that this performs a lookup rather than, say, a comparison.

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?

'Not live award availability' gives one negative boundary, implicitly routing live-award questions elsewhere, but no alternative tool is named and the positive use case ('when you need static transfer ratios') is only implied. Reasonable but not explicit.

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 cover read-only/idempotent/local safety. Description adds behavioral constraints: nights must be consecutive, roster key format (night-start date), output block fields, and 'Never decides where anyone sleeps' clarifies scope.

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?

Front-loaded with the core action, then necessary detail on input, output, and constraint. No filler; every sentence 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?

For a local, single-parameter planning tool with an output schema, the description supplies input format, output block fields, constraints, and scope boundary. Nothing essential for correct invocation 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 coverage is 0% and there is 1 nested parameter. The description compensates by defining roster as a date→names mapping with YYYY-MM-DD night-start keys and consecutive-night requirement, though it doesn't specify every edge case (e.g., empty arrays).

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?

States a specific verb 'group' and resource 'consecutive nights' with scope 'same people into blocks'. The 'Local:' prefix and downstream reference to search_hotels distinguish it from search 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?

Provides clear context: use this to produce blocks so one search_hotels stay per block can use headcount as adults. Does not explicitly state when not to use or name alternative planning tools, so not a full 5.

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 establish read-only, idempotent, non-destructive, closed-world behavior, and the description adds genuinely new behavioral facts on top of that: the environment opt-in requirement, the no-conversion/no-forecast guarantees, the failure mode (unreadable log yields read_error with series null), and the crucial distinction that null means unknown rather than empty. That is exactly the kind of context annotations cannot carry.

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 identity and the opt-in constraint are front-loaded, and nearly every clause carries a distinct fact (scope, series shape, single-observation behavior, currency rule, null semantics). The telegraphic 'route is ORIGIN-DEST; date matches...' style is efficient, though the clipped phrasing costs a little 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?

An output schema exists, so return-field explanation is not strictly required, yet the description helpfully characterizes the series anyway and covers the failure/null semantics an agent needs for correct interpretation. The remaining hole is the undocumented kind/limit/query_key parameters, which is the one thing an agent could still get wrong.

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 carries the whole burden, and it defines four of seven parameters: route as ORIGIN-DEST, date as matching a departure/return/check-in/check-out, location as a hotel stay, and currency via the never-merged/never-converted rule. It is silent on kind, limit, and query_key, leaving a substantial part of the surface undocumented in both places.

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?

States a specific verb and resource — a local read of price observations recorded on this machine — and scopes it precisely with the opt-in environment flag and the per-series shape (first_seen, last_seen, lowest, highest, change). It implicitly separates itself from search_flights/search_hotels (live search) and watch_price (forward-looking) by insisting nothing is forecast and nothing is merged or converted, though it never names those siblings 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?

It discloses a real precondition (VIAJANTE_PRICE_HISTORY=1 must be set) and the interpretive rule that a single observation yields no trend, plus the note that it may run during a search. However there is no explicit routing advice — no statement of when to prefer this over watch_price or a fresh search, nor what to do when the log is disabled. Usage is implied rather than directed.

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 cover read-only/idempotent/non-destructive/open-world, yet the description adds substantial behavior the annotations cannot: a fresh search is always performed (never the replay cache), a price_cap is intentionally omitted with breaks surfaced in filter_violations, and critically that check_failed means the check did not run rather than the offer being gone. It also disclaims that this is not a booking guarantee.

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?

Dense and front-loaded, with the core action and the freshness constraint stated first. Every sentence carries information, though the middle clauses are telegraphic and would benefit from slightly clearer separation.

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?

An output schema exists, so return values need not be re-explained; the description instead supplies the interpretation of the check_failed outcome, which is the non-obvious part. For an 8-param tool it delegates full rules to get_guide, which is reasonable, and covers the primary call path adequately.

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% across 8 parameters, so the description must compensate. It richly explains the two key inputs — offer (required fields: price plus each segment's flight_number, origin, destination, departure clock) and query (defaults to the offer's evidence query, replayed with cabin/stops/bags/airline filters) — but leaves fetch, proxy, country, currency, allow_substitute, and allow_loose_match entirely undocumented.

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?

States a specific verb (re-check) and resource (an earlier flight offer) with a precise scope: one fresh Google Flights search, never the replay cache. This cleanly distinguishes it from search_flights, which the description explicitly references as the source of the offer being re-checked.

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?

Establishes the context of use (re-validating a prior search_flights offer) and what input qualifies as an offer, including the minimum fields needed. It does not name a sibling to use instead for other scenarios, but the 'earlier offer' framing makes the triggering condition 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?

Adds real context beyond the annotations: HTTP-only transport, no fetch/browser fallback, blocking behavior, and the deadline_seconds failure mode where unfinished queries return error code deadline rather than empty results. Currency conversion behavior ('Viajante does not convert') is also disclosed. It stops short of saying anything about result shape, though the output schema covers that.

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?

Front-loaded with the core capability and scope before the alternatives and caveats; almost every sentence carries operational information. Minor drag from the oddly indented deadline_seconds block, but no filler.

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 decision-critical behaviors (blocking, no fallback, deadline semantics) are covered and an output schema exists so return values need not be described. However, for a tool with 37 parameters and no schema documentation, an agent is still guessing on most optional filters, which is a meaningful completeness gap.

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 37 parameters at 0% schema description coverage, the description carries the full burden, yet it explains only route, start, end, currency, country, and deadline_seconds. The remaining ~30 (sort, trip, cabin, adults, children, nearby, nights, price_cap, max_stops, airline/alliance filters, layover bounds, etc.) are left entirely undefined in both schema and 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?

States a specific verb and resource: 'Cheapest-per-day calendar for one named route, up to 31 days', and pins the scope with route/start/end semantics. It explicitly contrasts itself with search_flex, so an agent can route between them without opening the schema.

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?

Gives explicit alternative routing ('Use search_flex for +/-N around one date') and an explicit stop rule: on 'blocked', do not switch to browser or follow with search_flex or search_flights. Both when-to-use and when-not-to-use are stated.

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?

Beyond the annotations (which already cover read-only, idempotent, non-destructive, open-world), the description adds real behavioral detail: a dependency requirement ('browser extra'), no currency conversion, unpriced destinations surfacing as not_loaded, and timeout semantics via deadline_seconds returning error code deadline rather than an empty result.

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 purpose is front-loaded and the text is dense but short for a 38-parameter tool; each sentence carries information. The stray indentation in the second paragraph and heavy reliance on cross-references ('as in search_flights', 'See get_guide') slightly hurt 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 38-parameter exploration tool with zero schema description coverage, the description leaves most inputs unexplained, which is a substantial gap even though an output schema exists and the safety profile is covered by annotations. The error/prerequisite notes are good but do not compensate for the parameter coverage void.

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% across 38 parameters, so the description carries the full burden, yet it meaningfully covers only a handful (start, month, currency, country, deadline_seconds, and the adults/cabin restrictions). The other ~30 parameters (top, via, bags, sort, price_cap, max_layover, exclude_*, require_overnight, etc.) are undefined in both schema and 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?

The opening sentence names the resource and the two-stage output ('Destinations from one origin, then a priced shortlist'), so an agent knows it returns priced destination options from a single origin. It does not, however, differentiate itself from plausible siblings like search_dates or search_flex, so the agent must infer the boundary.

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 gives hard operating constraints ('Needs the browser extra', 'one adult in economy only') and an input rule ('Give start ... or month, not both'), plus a pointer to get_guide. It never states when to prefer this tool over search_dates/search_flex/search_trip, so usage context is only implied.

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 readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond them: deadline_seconds stops starting queries and returns error code deadline (not loaded, not empty), plus markup_drift semantics, and points to get_guide. Strong but not exhaustive (no pagination/rate-limit detail).

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?

Mostly tight and front-loaded: the core mechanic and sibling routing come first, with the deadline caveat and guide pointer afterward. A couple of sentences (markup_drift, allowed search_flights) are slightly fragmentary but each carries routing or failure-mode value.

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?

An output schema exists, so return-value explanation is rightly absent. However, for a 38-parameter tool with zero schema coverage, the description's parameter gap is a meaningful completeness shortfall; the routing and failure-mode guidance are good but do not fully equip the agent to call it 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?

With 38 parameters and 0% schema description coverage, the schema documents essentially nothing. The description only clarifies route (ORIGIN-DEST), around (ISO date), flex, and defers currency/country to search_flights. That leaves the vast majority of parameters (sort, trip, cabin, stops, layover windows, excludes, passengers, etc.) semantically undocumented in either place.

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?

States a specific verb and resource ('Flex window of +/-N days around one date, then one shopping search on the cheapest day') and names route/around formats. It clearly distinguishes itself from search_dates and search_flights, so an agent can select it without opening a schema.

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 routes to alternatives: 'Use search_dates for a cheapest-week calendar; do not brute-force a date matrix' and 'A named-date search_flights is allowed.' It also gives exclusion guidance on markup_drift days ('not no_results'), so when-to-use and when-not are fully covered.

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?

Beyond the read-only annotations, it discloses important behavior: currency inference and no conversion, refusal of exclude_basic_economy, how nearby_days builds a separate cheapest-fare grid, deadline_seconds producing error code 'deadline' rather than an empty result, and that price_insight is Google's label, not a forecast.

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 opening is front-loaded and information-dense, with little filler. However, the body is a run-on stream of clauses with no grouping or headings, and the trailing deadline_seconds block has awkward indentation, making the definition hard to scan despite its useful content.

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 presence of an output schema means return values need not be explained, and annotations cover the safety profile. The description captures several critical gotchas for a complex search tool, but it does not fully equip an agent to use a 43-parameter surface whose schema has no per-field 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?

With 43 parameters and 0% schema description coverage, the description must carry parameter meaning but only explains a subset: routes format, max_stops values, nearby_days, include_price_history, deadline_seconds, fetch, currency, and exclude_basic_economy. Many parameters such as top, via, sort, cabin, proxy, airlines, alliance, min_layover, and the clock-bound fields are left without semantic 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 first sentence names a specific verb and resource ('Google Flights search') plus the required route format 'ORIGIN-DEST:YYYY-MM-DD'. It also distinguishes this tool from search_dates and search_flex, so an agent can identify it without opening sibling 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?

The description explicitly routes alternatives: 'Use search_dates for the cheapest week and search_flex for +/-N days', and constrains search_hidden_city to one run after a named hub or leisure trunk, never when bags were named. It also points to get_guide for rules and wording.

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 cover the safety profile (readOnly, idempotent, openWorld), and the description adds real context beyond them: hidden-city tickets may violate airline contracts, Viajante does not book so the user must confirm on booking_url, results should be led with hidden_city true rows, and it is a single opt-in run rather than a repeatable search.

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?

Front-loaded with purpose then usage then caveats then currency semantics, and every sentence carries information. A few clauses are telegraphic and idioms like 'an optional keep of the card currency' cost the reader a second pass.

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?

An output schema exists so return values need no explanation, and the description covers routing, eligibility, contract risk and currency. The remaining gap is silent parameters (top, adults, return_date) that an agent must guess at from names alone.

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 carries the full burden. It explains currency in depth (keep semantics, USD cards, currency_mismatch, no conversion) and implies route/departure, but top, adults and return_date are never mentioned, leaving half the parameters undocumented.

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?

States a specific verb and resource ('Skiplagged search for a named route') and immediately scopes it against the sibling search_flights ('run it once after search_flights'). An agent can distinguish this hidden-city fare source from ordinary flight search without opening the schema.

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 gives when-to-use (after search_flights, on a named common route and date, opt-in only) and when-not (named bags, explore, dates, flex, multi-city, unproven destinations), naming several sibling tools as the alternatives. Nothing about routing 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial behavior beyond them: exact name matching with case/accents/punctuation ignored, ambiguous or absent matches return no_results rather than a guess, prices are unconverted USD in provider order. These are exactly the operational traits an agent cannot infer 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?

Front-loads the core statement ('Room rates for one Skiplagged hotel, for 1-3 finalists') and every subsequent sentence carries distinct information (matching rules, provider exclusivity, price semantics). It is dense and some clauses are run-on, but there is little padding to cut.

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 rate-lookup tool with an output schema, the description covers the high-risk gotchas: provider mixing, the occupancy_limit-per-room-type caveat, total_price scope, and currency. The remaining gap is that it never clarifies the date parameter formats or the rooms/adults defaults for a 7-param tool, so it falls just short of fully 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 description coverage is 0%, so the description carries the full parameter burden. It does explain hotel_id (provider_id from a skiplagged search_hotels offer), the hotel_name+city pairing, and exact-match semantics, and touches rooms/adults indirectly via 'the party and rooms searched'. However check_in/check_out and the city parameter are never defined, leaving several parameters undocumented in both places.

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?

States a specific verb+resource (room rates) scoped to exactly one Skiplagged hotel, and explicitly links its input to 'the provider_id of a skiplagged search_hotels offer', which cleanly separates it from the sibling search_hotels and get_hotel_details. An agent can tell what this returns (rate rows for a single hotel) without opening the schema.

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?

Gives concrete when-to-use conditions: intended 'for 1-3 finalists', and the hotel_name form should be used 'for a Google finalist' because Google hostel prices may be dorm beds. It also states an explicit exclusion ('Skiplagged only: do not mix these rows with Google or Booking prices'), so both selection and non-selection are covered.

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 cover read-only, open-world, idempotent and non-destructive, and the description still adds substantial behavioral context beyond them: no currency conversion and no invented ISO codes, deadline_seconds yields error code 'deadline' (not loaded, not empty), property_matrix nulls are not proof of unavailability, and Google ordering is not advice. These are exactly the non-obvious traits an agent needs before calling.

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?

Nearly every sentence carries real information, so it is not padded, but it is delivered as a dense telegraphic wall that mixes input-parameter semantics with output-field semantics (property_matrix, lodging_evidence_conflict) and ends with an oddly indented deadline_seconds note. It is hard to scan and not cleanly 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?

An output schema exists so return shape needn't be explained, and the description covers most behavior for a 15-parameter tool. However, with zero schema descriptions it leaves min_rating, free_cancellation, and top entirely undocumented, and never clarifies that all parameters are optional or which combination of location/check_in/check_out is actually required to get a useful result.

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 carry the load, and it does for most high-stakes parameters: currency and the skiplagged USD exception, location as a single named place, adults/rooms with no room split, stays batching up to 8 objects, near as {lat,lng} with max_distance_km depending on it, entire_home semantics, and deadline_seconds. It stops short of documenting top, min_rating, and free_cancellation, so coverage of the 15 parameters is strong but incomplete.

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+resource ('Hotel search') and immediately scopes it with substantive semantics (total-stay quotes, currency behavior, batch mode via stays). It differentiates the scope of the search from the downstream artifacts it produces (property_matrix, lodging_evidence_conflict), though it never explicitly contrasts itself with close siblings like search_hotel_rooms or get_hotel_details.

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?

Usage is implied rather than stated: it says to ask when 'location' is a typo/region/multiple towns, forbids stating a room split, and routes to get_guide for 'full rules'. But there is no explicit when-to-use-this-instead-of-X guidance against a 22-tool sibling set, which leaves the routing burden on 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?

Beyond the readOnly/idempotent/openWorld annotations, the description discloses important behavior: packaged search runs first, then up to max_hubs hubs with 2 queries per hub (3 with allow_overnight), and it stops at a recorded rate limit without retrying. It also explains that each ticket is confirmed on its own google_flights_url, that missed connections are not rebooked, that bags may need re-checking, and that total is null unless all parts share one currency.

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 front-loaded with the core definition and route syntax, and nearly every sentence carries operational information. It is dense and somewhat clause-heavy, but given the tool's complexity and 37 parameters, the length is justified rather than padded.

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?

An output schema exists, so return values need not be explained, and the annotations cover the safety profile. The description still supplies essential caveats about split ticketing, connection risk, currency aggregation, and rate limits. It is not fully self-contained for a 37-parameter tool, though, because many parameters are only indirectly covered and the description defers to get_guide for full rules.

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 carry parameter meaning. It does well for the distinctive parameters: route formats, trip, max_hubs bounds/default, via/exclude_via hub behavior, allow_overnight query behavior, and min_connection_hours as a planning default. However, with 37 parameters, many key inputs such as top, fetch, proxy, max_stops, leg_max_stops, baggage_buffer, and most passenger/filter fields are left unexplained or only covered by broad category references, so it only partially compensates.

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 resource and scope: separately ticketed itineraries built from real one-way quotes, with route syntax and round-trip behavior. It distinguishes itself from packaged search by running packaged search first and by flagging split_ticket true / connection_protected false, so an agent can identify when this tool rather than search_flights or search_trip applies.

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?

Usage is clearly implied as opt-in split-ticket search, with explicit route formats for one-way and trip="rt", and an exclusion: 'Not for multi-city.' It also points to get_guide for full rules. It does not explicitly compare itself with search_flights/search_trip by name, so it stops short of a full when-to-use/when-not matrix.

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 readOnly/idempotent/non-destructive/openWorld, yet the description adds real operational detail: no currency conversion, hotel inherits the flight currency, stay dates default to the flight window, positive carry_on is verified on-page while named bags are refused, trip_total is omitted if either side misses, and deadline_seconds yields error code 'deadline' rather than empty results. The deadline and trip_total semantics in particular are non-obvious behavior that annotations cannot convey.

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?

Purpose is front-loaded and the whole description is short for a 39-parameter tool, so it is not padded. However, several fragments ('Unnamed baggage_buffer is 0', 'under one lock') are terse to the point of ambiguity and the odd indentation of the deadline_seconds block hurts scanability.

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?

An output schema exists, so return shape needn't be spelled out, and the description does cover several cross-cutting behaviors. But for a tool this complex (two bundled searches, 39 params, 0% schema coverage), omitting the format and semantics of the required routes and location arguments, plus nearly all filter parameters, leaves the agent unable to invoke it correctly without external help.

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% across 39 parameters, so the description carries the full burden, yet it only touches currency, check_in/check_out defaults, baggage_buffer, carry_on, bags, and deadline_seconds. The two required parameters, routes and location, are never described, and the meanings of sort, trip, fetch, source, via, max_stops, price_cap, and the exclude/include families are left entirely undocumented.

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 gives a concrete composite verb+resource: it searches flights and then one hotel stay 'under one lock'. That is distinguishable from search_flights and search_hotels, and it explicitly ties its flight output to the search_flights recommendation block. It stops short of naming the siblings it replaces, so it is clear but not fully differentiated.

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?

There is no explicit when-to-use statement versus search_flights, search_hotels, or plan_stay_blocks. The only conditional guidance is 'if unproven, ask' for currency and a referral to get_guide for deadline behavior. The agent has to infer that this tool is for combined flight+lodging itineraries.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description still adds real behavioral content: cents are allocated so each stay sums exactly, uncovered nights surface as unallocated_nights, currency is never converted, and fee_per_person_night is applied per person. That is meaningful disclosure about rounding and output 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 core action is front-loaded in the first clause, and the remaining sentences each carry distinct semantics (rate derivation, currency, fee, rounding, unallocated nights). It is dense but nothing is obviously redundant.

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?

An output schema exists, so return values needn't be spelled out, yet the description usefully explains the unallocated_nights concept and the exact-sum rounding guarantee. The only real gap is the roster structure, which is delegated to a sibling rather than described for a tool with nested-object inputs.

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 carries the full load. It documents the stays shape ({name, check_in, check_out, total}), the currency semantics, and what fee_per_person_night does, but it defers the roster format entirely to plan_stay_blocks rather than describing it. Three of four parameters are partially covered; the fourth is only referenced.

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?

States a specific verb and resource ('split each stay's total among the people who sleep there') and marks it as 'Local' arithmetic, which separates it from the search/booking siblings. It also ties itself to plan_stay_blocks via the roster reference. It stops short of a full sibling differentiation (e.g., when to choose this over plan_stay_blocks).

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?

Usage is implied rather than stated: 'roster is as for plan_stay_blocks' signals it follows that tool in a workflow, and 'Arithmetic only: it does not price or recommend a stay' functions as a when-not boundary. But no alternative is named for the case where the agent wants pricing or recommendations, so the guidance is only partially explicit.

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 cover read-only, idempotent and non-destructive traits, so the bar is lower; the description still adds real behavior: local-only execution with no fetch, and a tri-state result where 'unknown evidence never becomes pass'. Timezone resolution rules (offset compared in UTC, naive time local at arrival airport) further disclose non-obvious semantics.

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?

Front-loaded and free of filler, but the final two sentences rely on terse domain jargon ('chronological checks owned segment instants', 'owned journey dates') that costs comprehension. Every sentence earns its place, yet the phrasing is compressed past clarity in places.

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 complex nested tool the description covers ordering, the exact-input contract, tri-state semantics and timezone handling, and the output schema exists so return formatting needn't be restated. Remaining gaps — full constraints fields and failure/error behavior — are real but secondary given the output schema's presence.

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% and the objects are opaque (additionalProperties: true), so the description carries the burden and largely meets it: legs must be in travel order with an exact query plus one selected offer, and constraints keys arrival_deadline, min_stay_days and max_stay_days are explained with their date/time semantics. It stops short of enumerating the full constraints shape or the currency parameter, so it is not exhaustive.

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?

States a specific verb+resource ('validate selected v2 flight offers') and adds the key distinguishing constraint 'locally, without fetching', which separates it from fetch-based siblings like recheck_offer. It is clear about what is validated, though it never names the sibling it contrasts with.

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 'without fetching' implies this is the cheap/local alternative to a networked recheck, and 'Pass legs in travel order, each with its exact query and one selected offer' gives invocation context. However, no sibling is named and no explicit when-not condition is stated, so the agent must infer the boundary.

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 cover safety (readOnly, idempotent, non-destructive, closed-world), but the description adds substantial semantics beyond them: what the tool returns (each unowned amount/currency/IATA code/ISO date/URL), the edge case that agent-computed sums count as unowned unless a payload carries them, and execution context ('Local; may run during a search'). This is rich, non-redundant 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?

Front-loaded purpose, then trigger, then output semantics, then the computed-sum caveat, then the execution note. Every sentence adds distinct, actionable information with no filler.

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?

Purpose, trigger, output meaning, and the key edge case are all covered, and an output schema exists so return structure needn't be restated. Nothing an agent needs in order 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 0%, so the description must carry the burden, and it does partially: 'Check a draft reply' tells the agent the single 'answer' parameter is the draft reply text. It stops short of stating format or length constraints, so it compensates 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 states a specific verb (check/verify) and resource (a draft reply against recorded search payloads), and it clearly distinguishes itself from the sibling search_* and lookup_* tools by being a pre-send validation gate. An agent can tell exactly what it does without opening the schema.

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 gives an explicit trigger condition — 'Call before sending a reply that quotes fares, stays, dates, airport codes, or links' — and prescribes the follow-up action ('Drop or re-search every unowned row; do not quote it as found'). Nothing about when to invoke it 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 only give the generic safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds the behavior that matters: saving under an existing name replaces that watch, an observation is recorded even when history opt-in is off, and cached/rate-limited runs record nothing.

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 dense and front-loaded with the core action, and parenthetical asides compress edge cases (file-unreadable behavior, cached runs) efficiently. Slightly run-on in the middle paragraphs, but no sentence is filler.

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?

An output schema exists, so return values need not be re-explained. For a stateful, side-effecting watch tool with an open-world hint, the description covers modes, persistence semantics, and recording conditions without 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?

Schema description coverage is 0% and all three params are untyped nullables, so the description carries the full burden. It does so by defining each one: name identifies the watch, kind is 'flight or hotel', and params takes 'the search_flights or search_hotels arguments', plus the semantics of omitting them entirely.

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 (re-run) and resource (a saved flight or hotel search) and states the outcome (report the change). It is clearly distinguishable from siblings like search_flights and search_hotels, which it explicitly references rather than duplicates.

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 enumerates each invocation mode and its effect: no arguments lists watches, name+kind+params validates/saves/runs, and name alone runs the saved search. It also supplies an explicit when-not-to-use rule ('no scheduler and no notification: do not call it in a loop').

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