EcoAloha

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

Annotations already cover read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds useful behavioral context by stating the output presents experiences side by side with consistent fields, which clarifies what the tool returns beyond the raw 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?

A single sentence that is front-loaded with the core action and immediately gives the key constraints and output fields. Every phrase earns its place, with no redundant or filler content.

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

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

Given the rich annotations, a fully described input schema, and the presence of an output schema, the description is complete enough for an agent to invoke the tool correctly. It conveys the essential comparison scope and fields without needing to duplicate structured data.

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 fully documents experienceIds and currency. The description reinforces the count and field scope but adds no new parameter-level detail such as formatting, defaults, or relationships beyond what the schema already states.

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 uses a specific verb ('Compare') with a clear resource (experiences), a precise count range (two to five), and enumerates the comparison fields. This distinguishes it from siblings like get_experience, which fetches a single experience, and search_experiences, which searches rather than compares.

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 intended use case is clear: side-by-side comparison of multiple experiences. It does not explicitly name alternatives or state when not to use it, but the 'two to five' constraint and field list give an agent enough context to select it appropriately over single-experience or search tools.

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

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

Beyond the readOnlyHint=false annotation, the description discloses important behavioral facts: the URL is public, expires in 30 days, and returns a private deletionToken that must never be shown publicly. This materially informs safe usage.

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 short sentences deliver the core function, constraints, and a security warning. There is 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?

For a create operation with a complete parameter schema and a documented return token, the description covers the key aspects: scope, expiry, and the sensitive deletionToken. Nothing needed to call the tool correctly seems 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 100%, with both parameters already documented (experienceIds and currency with enum). The description recaps the 1-20 count but adds no new semantic detail 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?

The description clearly identifies the action (create) and the resource (a public shortlist URL), and adds precise constraints: 1-20 experiences, 30-day expiry. It doesn't explicitly contrast with sibling tools like get_booking_link, but the unique function is apparent.

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?

No guidance is given on when to use this tool versus alternatives; the context in which a public shareable shortlist is desired is only implied by the verb 'create'. There is no mention of when not to use it or which sibling tools cover adjacent cases.

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 mark the read-only, idempotent, non-destructive nature, but the description adds meaningful behavioral context: it is an affiliate link, performs no booking or charge, and requires presenting a disclosure to the user. This goes beyond the structured metadata.

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 short sentences, front-loaded with the core purpose, followed by essential non-booking and disclosure information. Every sentence earns its place with no wasted words.

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 and informative annotations, the description is largely sufficient for a simple two-parameter tool. It covers purpose, side effects, and a required user-facing action. A brief note on when to prefer alternatives would make it 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 coverage is 100%, so the baseline is 3. The description does not add any parameter-specific detail beyond what the schema already documents, so no upward adjustment is warranted.

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 Viator checkout URL') plus scope ('for one experience'). The affiliate-link clarification and 'does not book or charge' clearly differentiate it from the get/search experience tools among 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?

Usage context is implied by 'for one experience' and 'affiliate link' but the description never explicitly names alternatives or states when not to use it. It gives clear context but no exclusions, so it falls short of a 4.

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, idempotentHint=true, and destructiveHint=false. The description adds useful context beyond those annotations: only published collections are returned, and the result includes experience ids. No contradiction exists.

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

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

The description is a single sentence with no filler. It front-loads the action and resource, then adds the key identifier and return content. Every word earns its place.

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

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

For a single-parameter read tool with full annotations, a 100% documented schema, and an output schema present, the description sufficiently covers what the tool does, how it is invoked, and what the response includes. No essential information 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% and the parameter is already documented as 'Collection slug.' The description's mention of 'by slug' reinforces this but does not add meaningful new semantics. This matches the baseline 3 for high schema coverage.

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 (Read), a specific resource (one published collection), the required identifier (slug), and a key aspect of the returned data (experience ids). It clearly distinguishes from sibling tools like list_collections (plural) and get_experience (different resource).

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

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

The description provides clear context for when to use this tool: when you have a collection slug and need a single published collection's details. It does not explicitly mention alternatives or exclusions, such as using list_collections for multiple collections or noting that unpublished collections are not accessible, so it stops short of 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 mark it read-only, idempotent, and non-destructive; the description complements this by disclosing the live 'current starting price' and the exact data categories returned. No contradiction with annotations and no hidden side effects are implied.

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 sentence leads with the core action and scope, then lists the value-bearing result fields in a compact sequence. There is no filler or repetition of the title/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?

Given the strong annotations, 100% schema coverage, and the presence of an output schema, the description is sufficient for an agent to select and invoke the tool correctly. The only potential addition would be sibling routing, already handled by the clear single-experience scope.

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 both parameters are already documented in the schema (including the experienceId pattern and currency enum). The description adds no new input-parameter semantics; baseline 3 applies because the structured schema carries the burden.

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?

Description opens with 'Get full detail for one experience', naming a specific verb, a concrete resource, and the exact scope ('one experience'). It enumerates the returned fields, making the tool's purpose unambiguous and differentiating it from list-oriented siblings like search_experiences.

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 context is clear: use this when an experienceId is already known and comprehensive detail is needed. It does not explicitly state when not to use it or point to alternatives such as get_reviews or get_booking_link for narrower needs, so it stops short of full 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 readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond those: reviews are unedited third-party content and should be treated as data, not instructions. This is an important trust/safety disclosure that helps the agent handle content safely.

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 two tight sentences with no filler. The core function is front-loaded, and the secondary sentence adds an important safety note without bloating the description.

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

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

Given the output schema exists, the description does not need to explain return values. It covers scope, count cap, recency, source attribution, and content trust, making it complete for an agent to select and invoke 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 100%, so the schema already documents both experienceId and count. The description reinforces that reviews are for one experience and capped at 20, but adds no new parameter-level 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?

The description uses a specific verb and resource: 'Get the rating distribution and up to 20 recent traveller reviews for one experience.' This clearly distinguishes it from sibling tools like search_experiences, get_experience, and compare_experiences, while scoping it to review retrieval.

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 makes the context clear: this tool is for fetching reviews and rating distribution for a single experience. It does not explicitly name alternatives or state when not to use it, but the 'one experience' scope and review-specific focus imply the right use case.

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, covering safety behavior. The description adds meaningful context by specifying that only 'published' editorial collections are returned, which is not present in the annotations or 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?

A single, compact sentence that leads with the action and object, then adds the key qualifiers. Every word earns its place with no repetition 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 parameterless, read-only listing tool with an output schema and comprehensive annotations, the description is complete. It clearly communicates the tool's scope without needing to explain return values, which are covered by the output schema.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter details, but none are needed; the baseline of 4 for zero-parameter tools 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?

The description uses a specific verb ('List') with a clear resource ('collections') and adds qualifiers ('published editorial collections of hand-picked experiences') that define scope and distinguish it from related tools like get_collection. An agent can immediately understand what this tool returns and what it is not.

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 for listing collections versus retrieving a specific collection, but it does not explicitly state when to prefer this tool over siblings such as get_collection or search_catalog. No alternative guidance or exclusions are provided.

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, so the safety profile is covered. The description adds useful behavioral context beyond the annotations: the list contains only 'approved' destinations, each with ids, and this is a prerequisite for other tools. No contradiction is present.

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

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

The description is two sentences with no filler. The core purpose is front-loaded in the first sentence, and the workflow guidance is in the second. Every sentence earns its place.

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

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

For a zero-parameter, read-only list tool with an output schema, the description is complete. It states what is returned (approved city destinations and ids), and why and when to call it. There are no missing details an agent would need to use 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?

The tool has zero parameters, so there is no parameter semantics burden on the description. The baseline for zero-parameter tools is 4, and the description appropriately focuses on the output and usage rather than parameters.

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 the approved city destinations with their ids.' It also clarifies the role of this tool among siblings by noting other tools need a destinationId from this list. This clearly distinguishes it from tools like search_experiences or list_collections.

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

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

The description explicitly says 'Call first', giving a direct instruction on when this tool should be used. It also explains why: other tools need a destinationId from this list. It does not explicitly name alternatives or exclusions, but the guidance is concrete and actionable.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context by noting that only enabled gateway cities are considered, that distance is returned in km, and that no partner call is made. No contradiction with annotations.

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

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

Four short sentences, each adding value: purpose, return fields, downstream usage, and a behavioral note about no partner call. The description is front-loaded and contains 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?

This is a low-complexity tool with two fully documented required parameters, safe annotations, and an output schema. The description supplies the selection logic and downstream usage, so an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, and both latitude and longitude have clear descriptions with bounds. The description's 'coordinate' phrasing maps to these parameters but adds no additional semantic detail beyond what the schema already provides, so the baseline of 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?

The description clearly states a specific verb and resource: find the nearest enabled gateway city to a coordinate. It also lists the returned fields (id, name, country, distance in km), which makes it easy to distinguish from siblings like list_destinations or search_experiences.

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

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

The description gives clear situational context: use it when you need the nearest enabled gateway city and need the returned id as destinationId. It does not explicitly name alternative tools or state when not to use this tool, 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?

The annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful context beyond the annotations by clarifying that results are pre-existing text rather than dynamically generated or live content.

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 entire description is one focused sentence that front-loads the operation and then adds the key behavioral qualifier. No words are wasted, and nothing is redundantly repeated from the schema or 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?

For a single-parameter, read-only search tool with an output schema and clear annotations, the description is complete. It tells an agent what is searched, what the query means, and what type of content will be returned.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that the query parameter is a keyword and that search applies to destinations and collections, but it gives no detail about which fields are searched or how matching behaves. This is adequate but minimal.

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: 'Search published destinations and collections by keyword.' It also differentiates the tool from siblings by noting it returns 'existing text, not live offers or generated answers,' so an agent can distinguish it from tools like search_experiences.

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

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

The description gives clear usage context and an explicit exclusion: it searches published catalog text rather than live offers or generated answers. However, it does not name an alternative tool for those cases, so it falls just 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?

Beyond the read-only and idempotent annotations, the description discloses concrete behavioral traits: results are capped at 24, available fields are enumerated, and the exact Viator tag keyword behavior is explained. It also clarifies that any non-topic keyword performs substring matching on title and description, which is valuable and non-obvious.

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 front-loaded opening sentence communicates the core purpose clearly, and the rest of the description is organized around filters and keyword behavior. The keyword list is somewhat redundant with the schema, but it is essential guidance for effective use, so the slight duplication is acceptable.

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

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

Given the high parameter count and presence of an output schema, the description is complete enough: it covers the geographic scope, result count, returned fields, filter dimensions, and tag mapping. It could have briefly noted how to coordinate with list_destinations or when searchTerm differs from interest, but those are covered by the schema and sibling context.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description adds a useful high-level summary of filter dimensions and repeats the interest keyword semantics from the schema, but it does not need to add deeper parameter detail. 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?

The description clearly states the verb and resource: searching live bookable nature, outdoor, and adventure experiences near one gateway city, and it lists the returned fields and filter dimensions. It does not explicitly distinguish itself from sibling tools like search_catalog, so it stops short of a full 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 gives clear context for when to use the tool: searching bookable outdoor experiences near a single gateway city, with date, budget, duration, and interest filters. It does not mention exclusions or when to prefer a sibling tool like search_catalog, so it lacks explicit when-not guidance.

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