TripWays

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), but the description adds real behavioral context: slots that cannot fit the group are omitted, party_size wins over travelers, and the status field enumerates ok/no_schedule/no_fit/calendar_gone. It stops short of error handling or rate-limit behavior.

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

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

Three sentences with no filler; the core capability is front-loaded, followed by the input-precedence rule and the downstream tool. Every sentence carries information an agent needs.

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, the return shape need not be explained, and the description still adds status-value semantics. Complete enough to call correctly; only minor gaps around error or timezone behavior remain.

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 60%, so the baseline is 3. The description restates precedence rules and the 31-day cap that the schema largely already documents, adding little beyond what the schema and its nested descriptions provide.

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 ('Check live start times and remaining seats for a TripWays tour') and bounds the scope ('one date or a range of up to 31 days'). An agent can distinguish this from search_tours or get_tour_details 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 the agent to get_price_quote with the same date, start time, and travelers for totals, which is a clear alternative-tool handoff. It also clarifies the party_size vs travelers precedence. It does not state when-not to use this tool, so it falls short of the full when/when-not/alternatives bar.

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), so the description only needs to add operational detail — and it does: non-bookable ids surface in not_found, and the comparison derives lowest price, shortest duration, best rating gated at 10+ reviews, and free-cancellation flags. It does not mention any rate limits or permission requirements, but none are implied for this read-only 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?

Front-loads the core action and scope, then the derived outputs, then the not_found edge case, then the alternative routing — four tight sentences with no filler despite the long field list.

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 structure need not be repeated; the description still covers the surprising edge case (not_found for non-bookable ids) and the derived-comparison logic. Combined with full schema coverage and rich annotations, an agent has everything needed to invoke 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?

Schema coverage is 100% and the single parameter is fully documented in-schema (pattern ^[0-9]+$, min/max 2-4, tripways.com/t/{id} mapping). The description restates 'by bokun_id' and the 2-to-4 bound without adding new semantics, so the baseline 3 applies.

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 (compare), resource (TripWays tours), scope (2 to 4, keyed by bokun_id) and enumerates exactly which attributes are compared. An agent can distinguish this from get_tour_details or search_tours without opening any 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 the adjacent use case away: 'For group totals on a date, use check_availability and get_price_quote.' It also implies the when-to-use case (multi-tour side-by-side comparison) and the 2-4 id bound, leaving little 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 (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false). The description adds genuinely new behavioral context the annotations cannot: it reads several live calendars and therefore can take a few seconds, plus the 31-day date-range ceiling and the 1-to-5 result cap.

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

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

Three sentences, front-loaded with purpose, then required inputs, then result shape and the latency caveat. Every sentence carries distinct information with no filler or repetition.

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 spelled out, yet the description still summarizes the response (cards plus up to three open start times and the original tour's status), which is a slight redundancy but harmless. Combined with the latency note and range limits, 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?

With only 50% schema description coverage, the description compensates by explaining the key inputs: bokun_id is the traveler's desired tour, the date/range is capped at 31 days, and party_size or travelers (with party_size winning) define the group. It adds meaning beyond the raw schema properties, though it does not restate the full traveler age breakdown.

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 with scope: find tours similar to one given tour that have open start times on a date or date range. This is clearly distinguishable from siblings like search_tours (general discovery), check_availability (single-tour status), and compare_tours (comparison), so an agent can route correctly without opening any 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 usage context: 'Pass the tour the traveler wanted (bokun_id), the date, and party_size or travelers', making it clear this is the fallback when a specific tour lacks open start times. It stops short of explicitly naming when to prefer it over check_availability or search_tours, so it is clear but not fully routed.

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, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond that: payment happens on tripways.com, the tool does not hold seats or take payment, and the result's bookable_natively/reason fields signal whether checkout or the operator's calendar opens and whether hotel pickup is required.

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

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

Three front-loaded sentences with the core purpose first and no filler. The final sentence explains the returned bookable_natively and reason fields, which is partly redundant since an output schema exists, but it still conveys useful behavioral context rather than pure padding.

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 fully described, and the description covers the key non-destructive/no-payment behavior an agent needs. The remaining gap is parameter-level detail for bokun_id and start_time/start_time_id in a 6-parameter, nested-object tool, which keeps this from being 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 only 33%, so the description must compensate by explaining parameters. It names the presetable dimensions (date, start time, rate, traveler mix), covering most optional inputs, but never mentions bokun_id (the required key) or explains the distinction between start_time and start_time_id, leaving meaningful gaps against a low-coverage 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?

States a specific verb and resource ('Get the TripWays checkout link for a tour') and scopes it clearly enough that it is distinguishable from read-oriented siblings like get_price_quote and check_availability. It does not explicitly name or contrast a sibling, 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?

The description implies usage context by saying the link can be 'optionally preset' with specific fields and clarifying 'this tool does not hold seats or take payment', which helps an agent understand when it applies. However, there is no explicit when-to-use versus check_availability or get_price_quote, nor any mention of prerequisites, so it remains implied guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context in 'when the tour has them' (fields may be absent) and the fact that data is operator-authored policy text, but it discloses no auth, rate-limit, or failure behavior beyond 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?

Two sentences, front-loaded with the verb and resource, then the returned fields and a scoping caveat. No filler; every clause adds information.

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

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

With an output schema present, the description needn't enumerate return structure, yet it does so helpfully, and it clarifies the tour-scoped (non-booking) semantics. It is complete enough to invoke correctly, with only the parameter's id origin/format 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?

Single parameter with 0% schema description coverage, so the description must carry the load. It tells the agent bokun_id identifies 'one TripWays tour,' which is meaningful scoping, but adds nothing about the numeric-string format or where the id comes from.

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 (Get) and resource (cancellation terms stored for one TripWays tour), and enumerates the returned fields (type, refund percent, cutoff, operator policy text). It also draws a boundary against get_price_quote by clarifying these are the tour's stored terms, not a booking-specific quote.

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 closing sentence carves out the usage case by contrasting with a booking-specific quote, implicitly steering the agent to get_price_quote for that need. However, it does not name that alternative explicitly or state hard when/when-not conditions, so it stops short of a 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 carry the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them by disclosing the failure path ('returns destination_ambiguous with a did_you_mean list') and the alias behavior ('Area names resolve to their parent destination and include resolved_via=area_alias'). These are non-obvious runtime traits an agent must plan around.

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

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

Three sentences, front-loaded with the core action, then the routing rationale, then the edge-case behavior. No filler and no restatement of the title or structured fields.

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 enumerated, yet the description still flags the two return shapes an agent must branch on (destination_ambiguous, resolved_via=area_alias). Nothing needed to call this correctly is missing.

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

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

Schema coverage is 50% and the undocumented param is `query`, whose meaning the description does supply (place names, including well-known areas). It also adds disambiguation semantics for country_code — that it exists to pick one meaning — beyond the schema's bare 'Optional ISO2 pin, e.g. FR.'

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 ('Resolve a place name ... to a TripWays destination with bookable tours') and enumerates accepted input forms (city, region, country, well-known area like Khao Sok). It also distinguishes itself from the sibling search_tours by naming it and its prep-step role.

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

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

Explicitly says when to reach for it: 'Useful before search_tours when a name could mean more than one place.' It names the alternative tool and the exact condition that selects this one, plus the fallback lever (pass country_code) when the first call is ambiguous.

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 closed-world, so the safety profile is covered. The description usefully adds behavior beyond that: the output shape (one full-day tour, or a morning/afternoon pair, with from-prices and links), that multi-day tours are listed separately, and the important limitation that availability, seats, and group totals are unverified.

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

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

Three sentences, front-loaded with the core action and only lightly redundant on the days default that the schema already specifies. The output-shape sentence earns its place by telling the agent what a response looks like.

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 3-parameter read tool with a full output schema and rich annotations, the description supplies the essential caveat about unverified availability plus the structure of the returned plan. An agent has enough to call it correctly; only explicit sibling routing 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 67% and the description largely restates what is already there (destination, days 1-7 with default 3). It does add marginal value by widening the interests example from the schema's 'food and history' to 'food, history, or boat trips'. Baseline 3 is appropriate.

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

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

A specific verb (suggest/plan) applied to a specific resource (a day-by-day plan of bookable TripWays tours) with a stated scope (a destination). It clearly distinguishes itself from siblings like search_tours and compare_tours, which return raw listings rather than an assembled itinerary.

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 closing caveat that 'dates, seats, and group totals are not checked' implies this is not the tool for firm availability, which nudges toward check_availability/get_price_quote, but no sibling is named and no explicit when-to-use/when-not statement is given. Usage 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 readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: missing operator fields are omitted rather than returned empty, and a note is emitted when nothing is stored. That is real output-shape disclosure an agent would not otherwise know.

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 primary purpose and identifier are front-loaded in the first clause, and the second sentence covers output behavior without padding. The field enumeration is dense but each item maps to a real returned value, so little is wasted.

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, the description need not document return structure, yet it still summarizes returned content and missing-field handling. For a single-parameter read tool with full annotation coverage, nothing an agent needs to call it correctly is absent.

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 meaning of bokun_id; it does add that the id refers to a TripWays tour, which is more than the schema's bare pattern constraint says. But it gives no format or sourcing hint (e.g., numeric string, obtainable from search results), 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?

Names a specific verb and resource ('Get where one TripWays tour starts') and enumerates exactly what is returned: meeting point text, hotel pickup availability, know-before-you-go notes, and what to bring. That enumeration clearly carves out a niche distinct from get_tour_details or get_itinerary_ideas without needing to name them.

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 'by bokun_id' implies the prerequisite (you need a tour identifier, presumably from search_tours or get_tour_details), so usage is inferable. However, there is no explicit when-to-use statement, no guidance on when get_tour_details would be the better call, and no exclusion conditions.

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 and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: no seat hold, no charge, extras/promos excluded, and the 'unpriced' failure mode when rates can't price a mix.

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?

Four tight sentences, front-loaded with the core action and scope, followed by the non-obvious constraints (no hold/no charge, exclusions, unpriced outcome). No filler, though the final sentence could be folded in.

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 described. For a read-only pricing tool with a nested traveler object, the description covers scope, side effects and the failure case adequately; only the id/time-id parameter ambiguity is left unaddressed.

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

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

Schema description coverage is only 40%, so the description should compensate more than it does. It ties date, start time and traveler mix together meaningfully, but says nothing about bokun_id or the start_time vs start_time_id precedence, leaving those to the schema alone.

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 ('Get the live total for a TripWays tour') plus the exact scoping inputs (date, start time, traveler mix) and the pricing source (operator's booking calendar). This is clearly distinguishable from check_availability and search_tours without opening any 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 clear context for use: a quote is a pre-booking price check that does not hold seats or charge, and it excludes extras and promo codes. It stops short of explicitly routing to sibling tools (e.g. 'use check_availability to hold seats'), so it is strong but not exhaustive.

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, so the safety profile is covered. The description adds meaningful behavior beyond that: this returns static catalog content (summary, itinerary, inclusions, cancellation policy, hero_image, checkout_url) while volatile data lives in the two named siblings. It doesn't address error behavior for a nonexistent id, which is the only notable gap.

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

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

Two sentences, front-loaded with the action and the identifier source, then a short routing clause naming the alternatives. No filler and nothing redundant with the schema.

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 single-parameter read tool with an output schema and full annotation coverage, this is complete: the agent knows what it gets, how to form the key, and which siblings cover the data this tool deliberately omits.

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: it translates bokun_id into 'the number in tripways.com/t/{id}', which tells the agent where to obtain the value. It doesn't restate the numeric-only pattern, but the URL decoding implies it clearly enough.

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 (fetch full details of one tour) and pins the identifier semantics to a concrete artifact ('the number in tripways.com/t/{id}'). It also enumerates the payload, so an agent can distinguish it from search_tours and the availability/quote siblings at a glance.

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 live dates and group totals to check_availability and get_price_quote, which is exactly the boundary an agent needs. It doesn't state a when-not condition for this tool itself (e.g., use search_tours first to find an id), so it falls just short of full when/when-not guidance.

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 readOnly, idempotent, non-destructive and closed-world behavior. The description adds genuinely useful non-schema context: reviews originate only from TripWays bookings while the aggregate rating may include other platforms, and written reviews are returned newest first.

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?

A single front-loaded sentence carrying purpose, provenance, and the limit semantics with no filler. Every clause (review contents, rating provenance, ordering) 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?

With an output schema present, return values need not be detailed, and the description still sketches what reviews contain (name, country, date, star rating, text). For a two-parameter read tool, nothing essential 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 carries the load, and it does: it explains bokun_id identifies a single TripWays tour and spells out limit's range, default, and ordering. It stops short of explaining what a bokun_id is or where it comes from, leaving a small gap.

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 ('Get the rating summary and written reviews for one TripWays tour') and scopes it to a single tour by bokun_id. This distinguishes it from siblings like get_tour_details or search_tours without needing to open 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?

Usage is implied: you call it when you want reviews for a known tour id. However, no explicit when-to-use/when-not guidance or named alternative (e.g., get_tour_details) is offered, so the agent must infer that reviews are not included in the general tour lookup.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds that results are 'ranked' and enumerates returned fields, which is useful behavioral context, but it adds nothing about pagination limits or scoring behavior beyond the limit cap in the schema.

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

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

Three sentences, each earning its place: what it searches, how to call it, what it returns, and the sibling handoff. The core purpose is front-loaded in the first clause 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?

An output schema exists, so return values need not be explained, though the description redundantly enumerates them. Given the 10-parameter surface and low schema coverage, the description covers the meaningful filter semantics and routing; only the untouched limit/duration-range params leave a minor 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 only 30% schema description coverage across 10 params, the description compensates well by naming the filter families (destination, price range in USD, duration in hours, activity, theme, cancellation policy) and clarifying the USD unit, which the schema's price_min/price_max do not state. It does not explain limit or the duration_min/max pairing explicitly, 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 (Search) and resource (TripWays catalog of bookable tours, day trips, activities), and explicitly contrasts scope with siblings by routing live availability/pricing to check_availability and get_price_quote. An agent can distinguish it from get_tour_details and get_destination_info without opening any 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 clear usage context ('Pass a natural-language query plus any filters you already know') and names two alternatives with the conditions that select them (live dates, remaining seats, group total). It stops short of an explicit when-not-to-use statement for search itself, but the routing is unambiguous.

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