Queenstown Tourism

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

With no annotations supplied, the description carries the full behavior burden and does disclose meaningful traits: output includes sources, the tool abstains from eligibility judgments, and 'a rule not listed may still exist' warns about incomplete results. It does not cover behavior for an unrecognized activity name or whether the lookup is read-only against a cached vs live source, leaving some gaps.

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 capability comes first and the two limitations follow immediately. Every clause 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 one-parameter read tool with no annotations and no output schema, the description covers the core capability, the evidentiary nature of results ('with sources'), and the key caveats. It stops short of describing the return structure in any detail or what happens on an unknown activity, which would matter without an 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?

Schema description coverage is 100% and the single 'activity' parameter already ships examples, so the schema does the heavy lifting. The phrase 'one activity or track' adds a mild clarification that trail/track names are valid inputs, but nothing about format, aliases, or ambiguity handling.

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: 'List the published age, height, weight, health and safety rules' for 'one activity or track.' It also carves out a scope boundary ('never decides whether a person can take part') that separates it from advisory siblings like get_answer or travel_faq.

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 scope exclusion ('Lists rules only: it never decides whether a person can take part') tells the agent when this tool is the wrong choice, which is useful negative guidance. However, it never names the alternative tool to use for an eligibility decision, so the routing is implied rather than explicit.

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

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

With no annotations, the description carries the full burden. It does disclose meaningful traits: the facts are 'reviewed' (curated content), sources are attached, and no verdict or ranking is produced. It says nothing about behavior for unknown or unmatched options, about the scope limit of exactly two items, or about result shape, so the disclosure is useful but partial.

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 operation and closed with the key negative constraint. Nothing is redundant and every clause carries 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 three-parameter, read-only comparison tool with no output schema, the description covers the core intent and the sources/no-verdict behavior. It is thinner on what the caller gets back structurally and on the optional topic filter, which an agent must learn from the schema alone.

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

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

Schema description coverage is 100% with an enum on topic, so the schema already does the heavy lifting and baseline 3 applies. The description does add a little meaning by restricting 'first'/'second' to activities, walks, or places rather than arbitrary strings. The optional topic parameter is never mentioned in the description, so no extra guidance on topic selection is gained there.

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

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

The description names a concrete operation on a concrete resource: putting reviewed facts on two activities, walks, or places side by side, with sources. The closing clause 'offers no ranking or verdict' separates it from a recommendation-style tool and hints at what siblings like get_answer or plan_trip do instead. It stops short of a crisp verb-resource phrasing, which keeps it out of the top band.

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 comparison framing implies when to reach for it, and 'offers no ranking or verdict' sets a boundary on what it will return. However, it never states an explicit trigger ('use when choosing between two candidates') nor names an alternative such as calling get_experience twice for each option. Usage is inferable but not spelled out.

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?

With no annotations, the description carries the full burden: it discloses that only "published" listings are returned, that openNow relies on structured hours evaluated in New Zealand time, and that no booking capability exists. It stops short of disclosing ordering/ranking of results, pagination behavior, or what fields a returned business record contains.

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 that spends no words on preamble; the geography lands early and the scope exclusion closes it. It is dense — six facets chained with "and" — which costs a little readability but nothing is redundant.

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

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

For a six-parameter, zero-required search tool with no output schema and no annotations, the description covers scope, geography, and the openNow time basis. It leaves gaps on result ordering, behavior when filters return nothing, and what a result record looks like, which matter given no output schema exists to explain returns.

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 optional parameters are already documented, including the NZ-time semantics of openNow and the limit default. The description's facet list mirrors the schema without adding syntax, precedence, or combination rules (e.g., how query interacts with area/type).

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+resource ("Find published places to eat and drink") plus an explicit geographic scope (Queenstown, Wanaka, Arrowtown, Te Anau) and the facets it can be filtered by. The final clause ("Business details only, no booking") bounds the resource so an agent can tell it apart from booking/experience 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 is implied by the scope statement — this is the discovery tool for eateries in the four listed areas — and "no booking" rules out one adjacent intent. However, no alternative is named: it never says to use get_venue for detail on one place or search_experiences for activities, so routing between siblings is left to inference.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses that answers come from reviewed facts with attribution (who states it, source link, date last confirmed) and that the tool explicitly reports when no reviewed fact covers the question rather than guessing. It does not restate that this is a read-only, non-mutating operation or discuss response shape beyond the fact records, leaving minor gaps.

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, front-loaded with the core capability, then the source-quality guarantee, then the fallback and the live-data caveat. No filler or repeated phrasing.

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 tool with no output schema and no annotations, the description covers what is returned (attributed, dated facts), what happens on failure (says so when nothing reviewed covers it), and the data-freshness boundary. Nothing needed 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 coverage is 100% and there is a single required parameter with an example, so the schema already does the work. The description reinforces that the question must name the activity, walk, route or town, which is useful but largely duplicates the schema's own guidance — 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 (answer) and a precisely scoped resource (questions about named Queenstown/Fiordland/Wanaka/Arrowtown activities, walks, routes or towns) answered only from reviewed facts. The closing 'Not live information' distinguishes it from live_conditions and today_fact without ambiguity.

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?

Implies the use case clearly — ask a question about a named activity/route/town — and excludes live data, which routes the agent to live_conditions instead. It stops short of naming that sibling explicitly or stating other exclusions, so it is clear context rather than a full 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?

No annotations are supplied, so the description carries the full burden. It does disclose meaningful behavior: results are grouped by topic and each fact carries its source and a last-confirmed date, which tells the agent the data is curated and dated. It omits what happens when the entity is unknown or has no reviewed facts, and says nothing about result volume or permissions.

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 with the verb and resource first and the output shape trailing. Dense but every clause (grouped by topic, source, date confirmed) conveys information an agent needs. Slightly clause-heavy, but no filler.

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

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

With no output schema, the description responsibly describes the return shape: facts grouped by topic, each with source and confirmation date. It covers the two-parameter tool adequately, with the only real gap being empty-result and volume 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 the enum of topics is fully enumerated, so the schema already does the heavy lifting. The description adds only the notion of grouping by topic, which loosely connects to the optional topic filter but does not explain its filtering semantics. 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: 'List every reviewed fact we hold on one activity, walk, route, place or facility'. The scope of entity types is explicit and the 'reviewed fact' framing distinguishes it from raw search tools. It does not, however, name a sibling such as get_experience or get_venue to clarify which entity-level tool an agent should pick.

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: an agent can infer this is the tool for pulling curated facts about a named place or activity. There is no explicit when-to-use or when-not guidance, and no routing toward alternatives like get_experience, get_route or get_answer that likely overlap for the same named entities.

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?

No annotations are supplied, so the description carries the full behavioral burden. 'Get full details' clearly signals a non-mutating read and the field list discloses what is returned, but it says nothing about not-found handling, caching, rate limits, or data freshness.

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 with no filler: the verb and lookup key come first and the enumerated return fields follow. Nothing is redundant or padded.

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

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

For a one-parameter read tool with no output schema, the description compensates well by enumerating the returned fields (highlights, inclusions, price, rating, cancellation). The remaining gap is the absence of failure-mode guidance.

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 schema even includes a concrete slug example, so the schema already does this work. The description only restates that the lookup key is the slug, adding no format or source guidance 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?

Names a specific verb and resource ('Get full details for one experience') and enumerates the fields returned. The singular 'one experience by its slug' implicitly contrasts with the list-oriented search_experiences sibling, but never names it 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 only implied: an agent can infer this is the detail-fetch step after obtaining a slug from search_experiences. There is no explicit when-to-use statement, no guidance on what to do instead, and no mention of behavior when a slug is unknown.

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?

With no annotations, the description carries the full load and does well: it discloses that data is static/reviewed rather than real-time, that every fact is attributed to a source, and that coverage is limited to Southern Lakes and Fiordland. It does not cover what happens when no reviewed route exists or how many facts are returned, which keeps it from 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?

Two short sentences, front-loaded with the capability and ending on the highest-value constraint (not live data). Nothing is padded or repeated from the schema.

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

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

For a simple two-parameter lookup with no output schema, the description supplies the missing return-value context (distances, drive times, services, sourced) and the regional boundary. Only the not-found/empty-result behavior is left unstated.

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 both from/to are already documented with place examples. The description adds only that the pair represents travel between two places within a named region; it gives no format, disambiguation, or ordering guidance 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 ('List') and resource ('reviewed facts on getting between two places'), plus the concrete data types returned (distances, drive times, services). The geographic scope and the explicit 'not live road or timetable information' caveat separate it cleanly from the sibling live_conditions.

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 exclusion 'Not live road or timetable information' effectively tells the agent when to route elsewhere, and the 'reviewed facts... each with its source' framing implies planning/research use. It stops short of naming live_conditions or any alternative as the replacement, so the routing is implied rather than explicit.

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

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

With no annotations present, the description carries the load and does disclose real behavior: only published venues are returned, values are reproductions of printed prices, and each response carries a capture date and source link so staleness is visible. The 'prices change without notice' caveat is genuinely useful context an agent could not infer. Gaps remain around not-found handling and whether results are cached.

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 action and payload, followed by a single-scope caveat. Nothing is repeated and 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?

For a one-parameter read tool with no output schema, the description enumerates what a caller receives and flags data-freshness risk, which is sufficient to call it correctly. It could still say what happens when the slug is unknown or unpublished.

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 single parameter's meaning ('Venue slug from find_places_to_eat') lives in the schema itself. The description only restates 'by slug' and adds no format or sourcing detail beyond it; 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?

States a specific verb and resource ('Get one published venue by slug') and enumerates the returned data: address, contact, hours, menu lines, capture date, source link. The 'published' qualifier signals scope, but it never names how it differs from siblings such as get_entity or get_experience, which also retrieve a single record.

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 description and schema together suggest this is the follow-up call once a slug is known from find_places_to_eat. There is no explicit statement of when to prefer this over get_entity or search_experiences, and no when-not guidance.

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

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

No annotations are supplied, so the description carries the full burden. It usefully discloses that exactly four records return and what each record contains, which is real behavioral detail, but it says nothing about ordering, whether the count is live or cached, or what happens on failure. For a trivial zero-parameter read this is adequate rather than rich.

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 front-loads the verb and the scope, with the returned fields trailing as a qualifier. No filler, no repetition of the tool name, nothing to cut.

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

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

With no output schema and no annotations, the description must convey the return shape, and it does at a summary level (destination name, description, count of bookable experiences). Only minor gaps remain, such as ordering of the four entries, which for a tool this simple is not a blocker.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly does not invent parameter guidance for a parameterless call.

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 (List) plus resource (the four Queenstown Tourism destinations) and the payload each entry carries (description, bookable-experience count). The fixed cardinality and named region make the scope unambiguous, though no sibling tool is named to distinguish it from broader retrieval tools like get_entity 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?

Usage is only implied: the word 'List' plus the fixed set of four suggests a browse-all orientation step, but there is no explicit when-to-use or when-not guidance and no pointer to alternatives such as get_entity for drilling into a single destination. An agent can infer intent but must guess at 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?

With no annotations, the description carries the full burden. It usefully discloses that no bundled condition claims are returned and that certain widgets are retired, which sets expectations. It still leaves unclear what exactly is returned (e.g., URLs, text, timestamps format) and whether the tool performs live network lookups.

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 three sentences and front-loads the main purpose before the negative and deprecation notes. It is efficient, though 'weather reader' is slightly jargon-like and the Queenstown specificity could be clearer.

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 tool without an output schema, the description should clarify the return shape. It names the kinds of outputs (reader, timestamps, links) but does not specify format or structure, leaving an agent unsure what invoking it actually yields.

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 meaning to add beyond the empty schema. The baseline for a no-parameter tool is 4.

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 action (find the Queenstown weather reader and source timestamps) plus official travel and resort report links. It distinguishes itself from travel-planning siblings by being a source locator rather than a trip planner. The name 'live_conditions' could imply returned conditions, but the description explicitly corrects that expectation.

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 implies usage by stating what it does not return (current condition claims from bundled data) and that road/ski widgets are retired. However, it does not explicitly say when to use this tool versus a sibling or what alternative to use when actual condition data is needed.

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?

With no annotations, the description carries the full behavioral burden and discloses little: 'locally supplied' hints at a curated static dataset but doesn't say whether the tool is read-only, what happens with no results, how results are ranked, or how query and days combine. No return-shape or result-count information is provided.

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 well-formed sentence that front-loads the domain and filters with no filler. Slight efficiency loss only in that the name mismatch adds ambiguity an agent must resolve.

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 simple two-optional-parameter search with full schema coverage and no output schema, the description covers the domain and filters adequately but omits result behavior (ranking, empty results) and how the two parameters interact. Marginal but with clear gaps for an agent deciding between this and sibling search tools.

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 parameters are documented, so the baseline is 3. The description restates the two filter axes ('free-text query and duration') without adding matching behavior, such as whether query and days must both match or how duration is applied.

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 (Find), resource (itinerary records), and domain (Queenstown and Milford Sound) with the two filter axes. It is reasonably distinct from siblings like search_experiences and get_experience, though the name 'plan_trip' suggests an action while the description describes a lookup, leaving a mild mismatch.

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

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

There is no explicit when-to-use guidance, no mention of prerequisites, and no named alternative among the many search-oriented siblings (search_experiences, compare_options, get_experience). The agent must infer that this is the itinerary-lookup tool from the description alone.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that results are locally supplied details only, implying a read-only retrieval rather than a booking operation, but it does not describe result ordering, pagination behavior, or what happens when no filters are supplied.

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 and front-loads the searchable scope and filters. It is efficient overall, though the phrase 'locally supplied' is repeated in the second sentence without adding new meaning.

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 six-parameter search tool with no output schema and no annotations. The description does not explain the return shape, default limit, ranking or behavior when no matches are found, leaving important gaps for correct invocation.

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 all six parameters. The description mentions destination, category, maximum price and minimum rating but adds no syntax, defaults or format details beyond what the schema provides, and does not mention query or limit.

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 experiences, scoped to Queenstown, Milford Sound, Wanaka and Te Anau, with named filters. It is clear what the tool does, though it does not explicitly distinguish itself from the sibling get_experience tool.

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 by listing filter dimensions, but gives no explicit when-to-use guidance relative to alternatives such as get_experience or compare_options. It also omits that all parameters are optional and offers no exclusions or decision rules.

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?

With no annotations, the description carries the full disclosure burden; it does signal that results are read-only facts and that each comes "with its recorded basis," which usefully tells the agent provenance is attached. It does not say whether the fact is randomly selected, fixed, or how many exist, nor anything about the response shape beyond the basis field.

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 with the verb first, the scope in the middle, and the returned provenance last. No filler, no restatement of the tool name.

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 tool with no output schema, the description covers the essentials: what is returned, where it applies, and that a recorded basis accompanies it. It could add a line on how the fact is chosen or how it differs from today_news, but nothing critical is missing for correct invocation.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly avoids inventing inputs the schema does not support.

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 pairs a specific verb ("Get") with a specific resource ("a locally supplied verified fact") and bounds it geographically to Queenstown, Fiordland, or the Southern Lakes. That is clear enough to distinguish it from data-oriented siblings like today_news or live_conditions, though it never names an alternative 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?

There is no statement of when to call this versus siblings such as today_news, travel_faq, or get_answer, and no preconditions or exclusions are given. The geographic scope hints at the domain but leaves the routing decision entirely 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?

No annotations exist, so the description carries the full burden, and it does real work: it discloses the returned payload (publication/source dates, citations, revision identity), and explicitly excludes historical articles and live road/ski status. It omits any statement about auth, rate limits, or fallback behavior when nothing is eligible.

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, front-loaded with the core scope statement followed by two boundary clarifications. The wording 'same accepted news release as the website' is slightly awkward but every sentence carries scoping 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?

A simple one-parameter read tool with no output schema, and the description compensates by describing what comes back and what is excluded. Nothing an agent needs in order to decide to call it is clearly missing, though routing to live_conditions stays 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?

Schema description coverage is 100% and the single 'limit' parameter already documents its 1-5 range and default of 1. The description adds no ordering or selection semantics for which 'recent stories' are picked, 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+resource: reads currently eligible reports matching the website's accepted news release, with dates, citations and revision identity. An agent can tell this is a news/report retrieval tool, but the phrase 'same accepted news release as the website' is idiosyncratic and doesn't name the sibling it differs from.

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 live road or ski status' and 'Historical articles remain in the archive' implicitly bound when to use it and when not to, but the alternatives (live_conditions for live status, an archive path for old articles) are never named. Usage is inferable rather than stated.

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

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

With no annotations supplied, the description carries the full behavioral burden and does much of it: it discloses the return shape (quoted guide text plus source page), the failure mode (states plainly that no guide covers the question), and the staleness caveat. It does not cover volatility, ambiguity handling, or response size, which keeps it off 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?

Three short sentences, front-loaded with purpose, then output contract, then the delimiting caveat. Every clause earns its place and nothing is restated from the schema.

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

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

For a one-parameter read-only tool with no output schema, the description supplies the missing return-value contract and the negative-result behavior, which is the important gap. It leaves open question granularity and how ambiguous or multi-destination questions are handled, so it is strong but not exhaustive.

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?

There is a single required parameter whose schema description is complete, so the schema does the heavy lifting. The description does add one constraint the schema lacks — the question is expected to concern one of four named destinations — but that is the only semantic gain.

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 (answer a travel question) and pins the exact scope geographically (Queenstown, Milford Sound, Wanaka, Te Anau) plus the source basis (published guides). The closing line "Not live information" carves it apart from sibling live_conditions and today_news without needing the schema opened.

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 four-destination scope and the "from published guides / not live information" boundary tell an agent clearly when this tool applies and when it does not. It stops short of naming the alternative tool (live_conditions) explicitly, so routing still requires a small inference.

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