DayPass

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious context beyond them: availability is a 'live hint' whose exact status is re-confirmed at checkout, warning the agent the result may be provisional. It stops short of describing caching 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?

Two tight sentences with zero filler; the core purpose is front-loaded and the caveat follows immediately. 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?

No output schema exists, so the description carries the return-value burden, and it does so partially by framing the answer as a live availability hint re-confirmed at checkout. It does not say what fields the result contains or what an unavailable response looks like, a minor gap for a 3-param read 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 description coverage is 100%, so the schema already documents the id pattern, the flexible date formats, and the locale purpose. The description adds no parameter-level meaning, which is the expected baseline when the schema does the heavy lifting.

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 (check DayPass availability) and a scope qualifier (given date). It is clear what the tool returns, but it does not name or contrast itself with siblings like get_experience or get_quote, so an agent must infer the boundary itself.

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 only implied: the note that status is re-confirmed at checkout suggests this is a pre-booking check, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. get_quote for pricing). Adequate but leaves routing 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful output-fidelity behavior (proper nouns must not be translated, prices exact and non-convertible) but says nothing about auth, rate limits, or failure 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?

Front-loaded with the core action and its key argument, then a compact parenthetical of returned fields, then the two output-fidelity rules. The parenthetical enumeration is dense but each item earns its place by telling the agent what to expect.

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?

There is no output schema, and the description compensates by enumerating the returned details and warning about proper-noun and price handling. For a simple single-id read tool, nothing an agent needs 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 100%, so all three parameters (id, date with relative-term support, locale for booking-link localization) are already fully documented in the schema. The description only restates 'by id' and adds no param syntax or defaults beyond what the schema provides; 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 and resource with scope — 'Get full details for one DayPass experience by id' — and enumerates the returned content (hours, amenities, photos, pricing, rating, booking link). This clearly separates it from list/search siblings like search_experiences and from render_experience.

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 only implied by 'by id' — the agent can infer it needs a known experience id, but the description never states when to prefer this over check_availability, get_quote, get_reviews, or render_experience. The translation/price rules are output-fidelity instructions rather than when-to-use 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=true and destructiveHint=false, but the description adds real value: the result is only an indicative quote, the final total (taxes/deposit) appears on the booking page, and no payment is ever performed here. This scope boundary helps the agent set user expectations 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?

Three short sentences, each front-loaded and earning its place: what it returns, the caveat about final totals, and the payment boundary. No filler or repetition of the title.

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 no output schema, the description appropriately conveys the nature of the result (indicative quote, not final total) and the payment boundary. It omits whether the id must correspond to an existing experience or whether availability is a prerequisite, but otherwise covers what an agent needs.

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 100%, so all six parameters (id, date, kids, adults, children, locale) are already documented in the schema. The description only alludes to 'a party on a date' and adds no syntax or constraint detail beyond that, matching the baseline of 3 when the schema does the heavy lifting.

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 concrete verb+resource: return an indicative price for a party on a given date. It is clearly a pricing/quote operation, distinct from siblings like get_experience or check_availability, 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?

Usage is implied (call this to preview cost before booking), and the description usefully clarifies that payment happens on the DayPass site, not through the tool. However, there is no explicit when-to-use/when-not guidance nor any named alternative such as check_availability, so the agent must infer the routing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral constraints beyond that: names must not be translated and prices must not be converted or estimated. It still does not explain ordering, recency window, or pagination, so it stops short of a 5.

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 purpose in the first clause, then appends the formatting constraints. No wasted sentences, though the translation/price rules are somewhat tangential to a read tool and could be seen as output-policy boilerplate.

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?

There is no output schema, so the description carries some burden for describing return values; it mentions 'rating and feedback' but not the shape or ordering of results. For a simple two-parameter read tool whose annotations cover the safety profile, this is adequate but not 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 100% – place_id and limit are both documented in the schema, including default and bounds. The description adds no parameter-level meaning beyond what the schema provides, 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 and resource ('Get recent guest reviews for a venue') and clarifies the payload ('rating and feedback'). This is clearly distinguishable from siblings like get_experience or get_quote, which return different data entirely, though it does not explicitly name a sibling it should not be confused 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 description never says when to call this versus alternatives, nor any prerequisite such as needing a valid venue place_id. The formatting instructions about proper nouns and prices are output-handling rules, not usage guidance, so nothing routes the agent to this tool over its siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds value beyond that: the data source ('live site map, so it is comprehensive and always current') and the two-mode response shape. It does not discuss pagination or rate limits, but for a read-only lookup that is minor.

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 purpose and scoping behavior, which is the right ordering. It is somewhat long, since the trailing proper-noun and price-preservation rules read as response-formatting policy rather than tool selection guidance, but each sentence does carry usable instruction.

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?

There is no output schema, and the description compensates by describing the shape of results (countries each with a city count, or cities within a country). Combined with the annotations covering safety, an agent has enough to call it correctly; only the exact response envelope is unspecified.

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 100%, and both fields (locale, country) are documented in the schema itself. The description reinforces the country parameter's behavioral meaning (country in → cities out, omit → all countries), but adds no syntax, format, or validation detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 — 'List all destinations where DayPass is live' — and defines the two resolution modes (all countries with city counts, or cities within a given country). This is clearly distinguishable from siblings like search_experiences or check_availability.

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: 'Use when the user has not named a place, or names a large country and you need to ask which city.' That is strong context. It stops short of naming an alternative tool for the case where the user has named a specific place, so routing is implied rather than fully specified.

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=true, destructiveHint=false, openWorldHint=true), yet the description adds real behavioral context: the output is an interactive card with a booking CTA, and rendering-fidelity rules (do not translate proper nouns, never convert or estimate prices). It lacks any note on failure modes when the id is unknown, but the added context is substantive.

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 display action and its payload, followed by the sibling routing and constraints in three dense sentences with no filler. The translation/pricing rules are slightly tangential to tool selection but are short and operationally relevant to a rendering tool.

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?

There is no output schema, so the description must describe the return value — and it does so thoroughly (card sections plus the Book on DayPass button). Combined with annotations, sibling routing, and id provenance, 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 description coverage is 100%, so all three parameters are already documented (id, date with relative-term examples, locale scope). The description adds only the provenance of `id` ('from a venue's experiences'), a modest increment over the schema, so the 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?

Specific verb (DISPLAY) plus resource (one experience as an interactive detail card), and it enumerates exactly what the card contains (gallery, rating, hours, amenities, pricing, policy, book button). It also names the sibling get_experience and states how the two differ, so an agent can choose 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?

Explicit routing: 'Use this to SHOW a chosen experience; use get_experience when you only need the data.' It also states the precondition that the id comes from a venue's `experiences`, which prevents calling it with an arbitrary or invented id.

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 the safe read-only, open-world profile, so the bar is lower, yet the description still adds real behavior: it renders an interactive map/card rail rather than returning raw data, and it imposes display constraints (proper nouns untranslated, prices shown exactly as given, never converted). It doesn't cover edge cases like empty result sets, but the added context is substantial.

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 the core action and immediately followed by the routing rule; the remaining sentences carry non-obvious display constraints rather than filler. Slightly prose-heavy but no sentence 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?

An output schema exists so return values need not be explained, and the description covers the routing decision, input parity with the sibling, and rendering/formatting constraints. It is complete enough for correct invocation, with only minor gaps around empty results or fallback 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?

Schema description coverage is 100% and every parameter is documented inline (city optional, date formats, sort options, type filter, locale purpose, required country), so the schema carries the weight. The description only summarizes inputs as "the same inputs as search_experiences (city + country, optional filters)" without adding format or syntax meaning beyond the schema, making the baseline 3 correct.

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

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

The description opens with a specific verb and resource ("DISPLAY DayPass search results") and names the concrete output form (card rail + map with List/Map toggle), which no other sibling produces. It also explicitly contrasts itself with search_experiences, so an agent can disambiguate 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?

It gives an explicit when-to-use ("when the user wants to SEE/browse experiences") and a named alternative with its own condition ("use search_experiences instead when you only need the data to reason over"). This is a clean presentational-vs-data routing rule.

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, openWorldHint, and non-destructive, so the safety profile is covered; the description adds substantial extra behavior beyond that. It discloses that sold-out venues are still returned with available:false, that prices are exact and must not be converted, that names are proper nouns that must not be translated, and that locale only localizes the booking link.

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 search modes and result shape, then appends the important output-handling constraints (don't translate, don't convert prices). Four sentences, each carrying real information, though the return-field enumeration slightly overlaps the output 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?

Complete for an 8-parameter, open-world search tool: required vs optional params are clarified, the country-only pattern is explained alongside the city pattern, and the critical presentation rules (exact prices, non-translatable proper nouns) are stated. An output schema exists, yet the description still flags available:false semantics, which is the one return detail an agent needs to reason about.

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 100%, so the baseline is 3; every parameter is already documented (city optionality, relative date terms, sort values, type filter behavior, locale purpose, price/rating filters). The description reinforces city-vs-country semantics and price/currency handling but adds no parameter syntax beyond what the schema already provides.

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 (search DayPass venues) and defines the two search modes: by city, or by country/island name for smaller markets, with a concrete example. It also names the sibling to use for deeper detail (get_experience), so an agent can distinguish it from get_experience without inspecting 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?

Gives clear when-to-use guidance: omit city for a whole-country/island search, and call get_experience when child/kid pricing or full details are needed. It does not mention check_availability or list_destinations as adjacent alternatives, but the primary routing decision is well covered.

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