TripWays

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

Beyond the annotations' read-only and idempotent hints, the description discloses the filtering behavior ('slots that cannot fit the group are left out'), the precedence rule between party_size and travelers, the 31-day range cap, and the status values ok, no_schedule, no_fit, and calendar_gone. These are substantive behavioral traits that help an agent interpret results correctly.

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 purpose and then moves efficiently through input selection, status values, and the get_price_quote handoff. It is dense but appropriately sized; the final sentence about rate_options and rate_ids is slightly compressed but still earns its place by linking to the pricing sibling.

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 explained, and the description still names the status values and the sibling to use for pricing. It leaves the meanings of no_schedule, no_fit, and calendar_gone implicit, but overall it gives enough context for an agent to call the tool 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 description coverage is 60%, and the description mostly restates what the schema already says about party_size, travelers, and their precedence. It adds little for the undocumented bokun_id and date parameters, and does not explain formats or edge cases beyond the schema's own patterns and constraints.

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 gives a specific verb and resource ('Check live start times and remaining seats') plus the exact scope: a TripWays tour, one date or a range up to 31 days. It also distinguishes this tool from get_price_quote by assigning pricing to that sibling, so an agent can tell them apart without reading 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 clearly says to use get_price_quote with the same date, start time, and travelers for the total, which gives a concrete handoff condition. It also states party_size wins over travelers when both are supplied. It does not explicitly list when not to use this tool, so it stops short of a full when/when-not routing statement.

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, closed-world behavior. The description adds real value beyond that: it discloses the derived verdicts returned (lowest price, shortest duration, best rating with a 10+ review threshold, free cancellation flags) and how unresolvable ids surface in not_found.

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 the returned attributes and derived picks, then the sibling routing. Every sentence earns its place 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?

With an output schema present and full param coverage, the description supplies the extra semantics an agent needs: the derived 'best' logic and not_found behavior. Minor residual gap is ordering/pagination of results, which is low-impact for a max-4-item comparison.

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 schema already documents the 2-4 count, uniqueness, and the tripways.com/t/{id} form. The description repeats the count and id meaning without adding format or edge-case detail beyond the schema.

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

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

States a specific verb and resource ('Compare 2 to 4 TripWays tours side by side by bokun_id') and enumerates the compared attributes. It also distinguishes itself from siblings by naming check_availability and get_price_quote for a different need.

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?

Clear positive guidance: use this to compare 2-4 tours by bokun_id, and route to check_availability/get_price_quote for group totals on a date. Lacks an explicit exclusion such as pointing to get_tour_details for a single tour, 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 declare read-only, idempotent, open-world, and non-destructive behavior. The description adds non-obvious behavior: it reads several live calendars, may take a few seconds, and returns up to limit tours with card data and up to three open start times plus original-tour status. No contradiction.

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 invocation, then return and latency expectations. The limit/default detail repeats the schema, but every sentence contributes useful selection or expectation-setting information.

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

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

For a read-only tool with annotations, an output schema, and nested parameters, the description covers purpose, invocation, return shape, latency, and date-range cap. Remaining gaps are mostly sibling routing rather than missing call-critical information.

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 already documents date_end, travelers precedence, and party_size precedence, but overall coverage is 50%. The description adds meaning for bokun_id ('the tour the traveler wanted'), date/date-range scope, and party_size-or-travelers, but does not fully explain the nested travelers object or all constraints beyond the schema.

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

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

States a specific verb and resource ('Find tours similar to one TripWays tour') and scopes it to open start times on a date or date range for a group. It is clearly different in substance from check_availability or search_tours, though it does not name a sibling 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?

Provides invocation guidance ('Pass the tour the traveler wanted ...'), which implies the use case, but it never says when to choose this over check_availability/search_tours or when not to use it. Alternatives and exclusions are left to inference.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, yet the description adds real context: the link does not hold inventory or process payment, and the returned bookable_natively and reason indicate whether checkout happens on TripWays or the operator's calendar and whether a hotel pickup must be selected. That is exactly the side-effect clarity an agent needs before handing a link to a user.

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 dense sentences, front-loaded with the core action, then the payment/inventory disclaimer, then the return-field semantics. No filler and nothing repeated from the annotations.

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 covers return values and the description still explains bookable_natively and reason helpfully; the nested travelers object is noted as mapping to Bokun pricing categories. Minor gaps remain: bokun_id is never explained as the tour identifier, and link expiry/validity is unmentioned, which matters for a link-generation 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 only 50%, but the description compensates by explaining the optional preset set (date, start time, rate, traveler mix) and by defining rate_id's relationship to get_price_quote's rate_options. It does not clarify bokun_id's meaning nor the start_time vs start_time_id precedence beyond what the schema text says.

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 the TripWays checkout link for a tour) and enumerates the preset dimensions (date, start time, rate, traveler mix). It is clearly differentiated from siblings like get_price_quote and check_availability, which price and check rather than produce a purchasable link.

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 rate_id parameter text ties the tool to get_price_quote ('the rate_id get_price_quote priced or one from its rate_options'), which implies the quote-then-link workflow. It also states the traveler pays on tripways.com and the tool does not hold seats or take payment, but it never explicitly says when not to use it or that availability should be confirmed first.

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, closed-world behavior, so the safety profile is covered. The description adds real value beyond that: the result structure (from-prices, links, multi-day tours listed apart) and the important caveat that availability, seats, and group totals are unverified. It does not discuss result size, empty-result behavior, 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?

Four sentences, front-loaded with purpose, then parameters, then output shape, then the caveat — each carrying distinct information with no restatement or 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?

For a three-parameter read-only suggestion tool with an output schema, nothing essential is missing: inputs, result structure, and the key limitation (no live availability) are all stated. The remaining gaps, such as empty-destination handling, are minor.

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 67%; the description reinforces the days bounds (1 to 7, default 3) and broadens the interests examples to 'food, history, or boat trips' beyond the schema's single example. It explains what interests actually do (shape the suggested plan), which the schema does not.

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

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

States a specific verb and resource — 'Suggest a day-by-day plan of bookable TripWays tours for a destination' — and the structured shape of the result (full-day tour or morning/afternoon pair, multi-day listed apart). This is clearly distinct from siblings like search_tours or compare_tours, which return flat lists or comparisons rather than a plan.

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?

'These are suggestions only: dates, seats, and group totals are not checked' establishes the planning context and implicitly routes verification to check_availability/get_price_quote. It never names an alternative tool explicitly, so the agent must infer the handoff rather than being told it.

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?

Goes well beyond the readOnly/idempotent annotations: states a quote holds no seats and charges nothing, excludes extras and promo codes, and describes the unpriced outcome with a message giving the group size the options can take. This is exactly the extra context 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?

Dense and front-loaded, starting with what is priced and following with the rate_id ladder, then behavioral caveats. A few sentences (the rate_id restatement) duplicate the schema, which trims a point off an otherwise efficient definition.

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 six-param pricing tool with an output schema, the description covers fallback behavior, optional parameters, exclusivity of extras/promos, and the failure mode. It also clarifies what from_price and group_price mean, so an agent can interpret results without guessing.

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 50% schema coverage, the description compensates by explaining the pricing fallback for a missing rate_id and the condition for omitting start_time, plus how traveler mixes map to pricing. It repeats the rate_id schema description somewhat, and travel-mix category mapping stays briefly noted rather than fully elaborated.

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 (live total for a TripWays tour on a date/start time for a traveler mix) and scopes the pricing source to the operator's booking calendar. It also distinguishes the rate_options path from check_availability, making it easy to tell apart from siblings.

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

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

Explicitly explains the rate_id decision ladder (advertised option → operator default → cheapest fitting option), when to pass a rate_id from rate_options, and that start_time can be omitted for single-time dates. Effectively states when and how to use it rather than leaving options to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds meaningful context beyond them: the response is a static catalog snapshot, with live dates and group totals explicitly excluded. It doesn't mention auth requirements, rate limits, or error behavior for a nonexistent bokun_id, so it stops short of full disclosure.

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 key identifier and scope are front-loaded, and the second sentence is a tight hand-off to the money/availability tools. The long field enumeration partially duplicates the output schema, making one sentence do more work than necessary.

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 explained, yet the description still previews the payload shape well enough to plan a call. For a single-parameter read tool with strong annotations, nothing an agent needs 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% for the single parameter, so the description must carry the meaning — and it does, explaining that bokun_id is the numeric id from the tripways.com/t/{id} URL. It adds no note on the digits-only pattern or what happens with an invalid id, keeping it below a 5.

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 full details of one TripWays tour') and disambiguates the identifier by tying bokun_id to the number in tripways.com/t/{id}. It also enumerates the returned content and names the siblings that serve live pricing/availability, so the agent can distinguish it from check_availability without opening either 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 dynamic concerns elsewhere: 'Live dates and group totals come from check_availability and get_price_quote.' That is clear positive guidance on when to use alternatives, but it doesn't address the other overlapping siblings (get_meeting_point, get_cancellation_policy, get_tour_reviews), which return subsets of the same data.

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 cover read-only, idempotent and closed-world behavior. The description adds that results are ranked and that filters are optional ('any filters you already know'), which guides partial-query usage. It does not disclose result-set sizing or the effect of the limit cap, but with annotations carrying the safety profile this is close to complete.

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 and usage before the field list. The return-field enumeration is somewhat wasted because an output schema exists, but it does not obscure the actionable guidance.

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

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

For a 10-parameter, read-only search tool with an output schema, the description covers purpose, filter semantics and sibling routing. Only behavior around the limit cap and result ranking/ordering is unstated, which is a small residual 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?

Schema description coverage is only 30%, so the description does real work: it enumerates query, destination, price range in USD, duration in hours, activity, theme and cancellation policy, confirming all are optional refinements. Only 'limit' is left unexplained, which is a minor gap given its documented default and maximum in the schema.

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

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

States a specific verb and resource ('Search the TripWays catalog of bookable tours, day trips, and activities worldwide') and scopes it to catalog discovery rather than live availability. An agent can distinguish it from check_availability and get_price_quote without reading either 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 describes two modes: free-text query plus optional known filters. It also names the exact conditions that route elsewhere — live dates, remaining seats, group totals go to check_availability and get_price_quote. This is a clear when-to-use / when-not-to-use split.

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