Camping Australia

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

The description extensively discloses behavioral traits beyond annotations: it is 'SERVER-DRIVEN and stateful', requires session_key reuse, returns 'added' or 'question_pending' statuses, and mandates asking the user EXACTLY one question at a time. This adds significant value over the minimal annotations (all false). It does not cover error handling or auth, but the essential stateful behavior is well explained.

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 dense but every sentence earns its place. It opens with the purpose, then uses bullet points to separate the two call flows, ending with a critical warning about session_key. The structure is clear and front-loaded with the most important information, making it easy to parse despite the complexity.

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 tool's complexity (10 params, nested objects, no output schema), the description covers the key aspects: how to start, how to continue, and what responses to expect. It does not describe the contents of an 'added' response, but that is not essential for invocation. The reference to bk_operator_availability provides prerequisite context. It is reasonably complete, though a bit more explanation of the response structure would make it fully self-contained.

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

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

With 100% schema coverage, the baseline is 3, but the description adds substantial meaning. It explains the role of session_key (omit on first add), pending_token for subsequent answers, the answer object structure, and that quoted_price comes from bk_operator_availability. It also clarifies the parameter groups for the two call modes, which is not evident from the schema alone.

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

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

The description clearly states the tool's core function: 'Add a product to the Bookeasy booking cart, OR answer a booking question.' It specifies the two distinct use cases and distinguishes itself from sibling cart tools like bk_cart_checkout and bk_cart_promo. The verb 'add' and resource 'booking cart' are explicit.

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 workflow context: when to omit session_key for a new cart, how to pass initial parameters, and how to handle the question_pending flow by reusing session_key and pending_token. It references bk_operator_availability as the source for quoted_price. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to know when to use this tool versus others.

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?

Despite annotations marking destructiveHint=true and readOnlyHint=false, the description adds substantial behavioral context: the two-step confirmation flow, that no payment link is issued without confirm, payments occur on Bookeasy's page, and the booking is pending until paid. This goes well beyond the 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?

The description is longer than average but tightly structured with numbered steps and bolded key instructions. Every sentence contributes meaningful guidance, though a few phrases could be trimmed without losing clarity.

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 compensates by explaining what each call returns (summary vs payment link), when to call, and what not to do. It fully covers the human-in-the-loop complexity and integrates prerequisites, making it complete for an agent to invoke correctly.

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

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

Schema coverage is 100% and the confirm parameter description already explains withholding the link. The tool description adds value by clarifying that the first call returns summary+total and the second call returns the secure link, deepening understanding of how the parameters drive behavior.

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 ('Finalise') and resource ('Bookeasy cart'), clearly stating the tool returns a SINGLE checkout URL. It distinguishes this from sibling cart tools like bk_cart_add and bk_cart_promo by focusing on finalization and payment, not modification.

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

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

Provides explicit two-step usage instructions with a critical human-in-the-loop rule: call without confirm first, then only with confirm=true after the traveller explicitly agrees. It also states preconditions ('cart is ready', lead guest set) and warns against using when pending questions, making alternatives and timing clear.

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 annotations (which only indicate non-read-only, non-idempotent), the description reveals key behaviors: omitted fields are prefilled from the customer's account, explicit values override, and the tool is a prerequisite for booking issuance. It adds meaningful context about the prefill/override mechanism, which is not obvious from the schema alone.

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 concise and well-structured: it starts with the core purpose, then provides necessary context about Bookeasy's requirements and prefill behavior, and ends with precise usage timing. Every sentence contributes useful information without redundancy.

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?

The tool has no output schema, so the description does not need to explain return values. It covers the essential aspects: what the tool does, when to call it, and the prefill/override behavior. It could mention error cases or response content, but for a cart-attachment step the current description is sufficiently 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% with descriptions for all five parameters. The description augments this by clarifying that first_name, surname, and email can be omitted for signed-in customers (prefilled from account), and that explicit values override prefilled ones. This adds value beyond the schema's basic field labels.

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 tool's function: 'Attach the lead guest's contact details to the Bookeasy cart.' It specifies the resource (Bookeasy cart) and the specific action (attaching contact details), distinguishing it from sibling tools like bk_cart_add and bk_cart_checkout.

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 explicit timing guidance: 'Call once the cart has items and before bk_cart_checkout.' It also explains how the tool behaves for signed-in customers, giving a clear usage pattern (call with just session_key to confirm prefilled details or pass explicit values to override). It does not explicitly name alternatives but the workflow context is clear.

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 indicate readOnlyHint=false, so the mutation is already known. The description adds behavioral detail beyond annotations: it explains the removal capability via remove=true, and the timing effect on the discounted total before checkout. It does not contradict the annotations and provides useful operational context about how the cart total is affected.

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 concise sentences, front-loaded with the main purpose, then usage context, and a parameter-specific note. Each sentence adds essential information without redundancy or filler, making it easy to parse and act upon.

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 tool with 3 simple parameters, no output schema, and minimal annotations, the description covers the core aspects: what it does, when to use it, and how removal works. It is well-integrated with sibling context via the checkout ordering hint. The only minor gap is not mentioning potential error handling or invalid codes, but the description is complete enough for straightforward 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 input schema covers all three parameters with descriptions, so the baseline is 3. The description restates the remove parameter ('Set remove=true to take a code off') but does not add substantial meaning beyond the schema. No additional parameter details are needed due to 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 clearly states the tool's function with a specific verb and resource: 'Apply (or remove) a promo / discount code on the Bookeasy cart.' It explicitly distinguishes from sibling tools by mentioning the correct timing relative to bk_cart_checkout and the removal option, so the purpose is unambiguous and differentiates among cart-related operations.

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 usage context: 'Use when the user gives a promo code; call before bk_cart_checkout so the discounted total shows.' This gives an explicit when-to-use and an ordering guideline. It does not explicitly state when not to use or name alternatives, but the context is sufficient for an agent to select this tool appropriately among 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 idempotentHint=true. The description adds the 'LIVE' nature of the data and the return structure, which are useful behavioral details beyond the annotations. No contradictions 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?

The description is two sentences with no filler. It front-loads the core action ('Get LIVE...') and compresses the return format and workflow into a tight, readable structure.

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 read-only availability tool with no output schema, the description provides the essential return shape (product list with price, max_guests, available flag) and the pipeline position (after operator search, before cart add). This is sufficient context for an agent to 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 each parameter's purpose is already documented. The description adds meaningful context for operator_id by directing the agent to source it from bk_search_operators, and it aligns check_in/check_out with 'specific dates.' This goes slightly 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 opens with the specific verb 'Get' and clearly identifies the resource: 'LIVE products, pricing and availability for a Bookeasy operator for specific dates.' It also names the exact return fields (product_id, price, max_guests, available flag), making it unambiguous and distinct from sibling tools like bk_search_operators and bk_cart_add.

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 explicit workflow context: 'using an operator_id from bk_search_operators' and 'before bk_cart_add.' This clearly indicates when to use the tool in the sequence, though it does not explicitly name exclusions or alternatives beyond this implied chain.

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, covering the safety profile. The description adds useful context that the search goes through Bookeasy and that content is not in the local directory, which helps set expectations about data source and scope. It does not mention return format or specific error behavior, but the annotations plus description are fairly transparent for a read-only search tool.

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

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

The description is three sentences, each carrying distinct value: action/resource, usage guidance, and exclusions. It is front-loaded with the verb and resource, uses dashes for readability, and avoids redundant 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 simple read-only search tool with only two well-documented parameters, no output schema, and strong annotations, the description provides complete context: purpose, content type, usage, and explicit exclusion. Combined with sibling tool names, the agent can select and invoke this tool with confidence.

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 both 'query' and 'limit' fully described including an example. The tool description reinforces the query style (e.g., 'things to do near X') but does not add new parameter details beyond what the schema already provides. Baseline 3 is appropriate because the schema is self-sufficient.

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 ('Search curated tourism content') and enumerates content types (attractions, things to do, local experiences, events). It explicitly distinguishes from sibling tools by noting this is NOT for campsite/accommodation booking and references 'the other bk_ tools', making it clear what this tool does not do.

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 explicit usage guidance: use it for 'what's on / things to do near X' style questions, and explicitly says NOT for campsite/accommodation booking, pointing to the other bk_ tools as alternatives. This gives clear when-to-use and when-not-to-use instructions.

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 valuable behavioral context beyond these: it highlights the 'real-time inventory' from the Bookeasy platform and mentions that returning operator_id values are needed by other bk_ tools. This gives the agent insight into the data source and downstream dependencies without contradicting the 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?

The description is four sentences, each with a distinct purpose: stating what the tool does, when to use it, how it differs from a sibling, and example user triggers. It is front-loaded with the core purpose and every sentence contributes to the agent's decision-making. 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?

For a search tool with 4 parameters and no output schema, the description covers the key aspects: purpose, usage triggers, relationship to other tools, and return value (operator_id). It could mention the default/max limit or pagination, but these are already in the schema. Overall, it provides sufficient context for an agent to invoke it correctly, though a note about output structure would have made it more 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% for all 4 parameters (latitude, longitude, limit, within_km), so the schema already explains the parameters. The description does not add additional parameter semantics beyond stating the search is 'near a location', which is already implied by the lat/long parameters. Baseline 3 is appropriate since the description does not add meaning beyond the schema, but it doesn't need to.

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 tool's function: 'Find LIVE-BOOKABLE accommodation operators near a location via the Bookeasy booking platform (real-time inventory).' It uses a specific verb ('Find'), identifies the resource ('LIVE-BOOKABLE accommodation operators'), and explicitly differentiates from the sibling 'search_campsites' by noting the distinction between real-time inventory and the directory. This makes it unambiguous and distinguishable.

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 explicit when-to-use guidance: 'Use this when the user wants to actually BOOK and needs live availability/pricing' and 'Prefer this when the user says things like "book", "reserve", "is it available", or asks for real prices for specific dates.' It also names the alternative 'search_campsites' and clarifies the difference, giving the agent clear situational 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context such as the data source (National Public Toilet Map), sorting by distance, the fields returned, and the fallback behavior when no toilets are within radius. This goes beyond the annotations and helps set expectations.

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 efficiently structured: first sentence states the core purpose, followed by use-case examples and return details. The second paragraph addresses a key ambiguity around location handling. No redundant or filler content exists; every sentence serves a purpose.

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?

The tool is relatively simple with no output schema, but the description covers return fields, sorting, and filtering behavior. It also addresses the common 'near me' scenario. Minor gaps exist such as error handling for invalid coordinates or exact pagination, but overall this is sufficiently complete for effective use.

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 parameters are already documented. The description adds extra semantic value by explaining how latitude/longitude should be derived from user context or conversation, and notes default values for limit and radius. This supplements the schema descriptions meaningfully.

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: 'Find the nearest PUBLIC TOILETS to a location'. It clearly distinguishes from sibling tools like search_campsites or get_campsite_details by focusing on toilets. The example queries further clarify the tool's purpose.

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 states when to use the tool ('Use this for questions like...') and provides concrete example phrases. It also gives guidance on how to handle 'near me' queries, either passing known context or asking for location. It lacks explicit exclusions or comparisons to alternatives, but the context is clear enough for correct selection.

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 provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds useful context beyond annotations by specifying the exact return fields (pricing, capacity, amenities, vehicle access info) and the 'all' scope, which helps set expectations without contradicting the 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?

The description is a single, well-structured sentence that front-loads the core purpose before adding examples and return details. Every clause adds value, and there is no redundancy or fluff.

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?

The tool is simple with one parameter and a clear read-only intent. The description includes what the tool returns, which is sufficient given there is no output schema. It does not explain pagination or response format, but for a list operation this is acceptable.

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 schema documents the single parameter entity_id with a description matching the tool description. Description adds no new meaning beyond the schema, so with 100% schema coverage, 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 the tool lists accommodation types for a specific entity, with concrete examples (powered sites, unpowered sites, cabins, hotel rooms). It also lists the returned info, distinguishing it from sibling tools like get_campsite_details by focusing specifically on accommodation types.

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 clearly indicates when to use the tool: when you have a specific entity_id and need the accommodation types offered by that entity. It does not explicitly name alternatives or exclusion criteria, but the context is clear enough for an agent to select it over siblings that do different things.

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 context beyond this: the user finishes booking on DriveAway's site (no payment taken here), the tool returns a single booking_url, and it is Australia-only. This clarifies the external-redirect nature and geographic scope.

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 only two sentences, front-loaded with the core purpose, followed by essential usage notes and a constraint. Every sentence adds value with no redundancy.

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 tool's simplicity, the description covers purpose, usage, return value, payment handoff, and geographic scope. The schema documents all params, and annotations cover safety. Missing details like error handling or unsupported cities are minor for this use case.

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. The description adds minimal parameter context ('pickup city and dates') but does not elaborate on optional parameters like driver_age or passengers. The schema already provides sufficient detail for all 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 explicitly states the tool gets a DriveAway booking deep-link for campervan/motorhome hire given a pickup city and dates. It uses a specific verb ('Get') and resource ('DriveAway booking deep-link'), and distinguishes from sibling search tools by noting 'no search needed'.

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 usage context: use this once dates are chosen to provide a 'book now' link, and it explicitly says 'no search needed' to prevent misuse. It does not name a specific alternative tool, but the sibling list contains relevant search tools, making the guidance practical.

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, so safety is covered. The description adds valuable context by enumerating the returned data (features, address, photos, rating, etc.), which is not present in the schema or annotations. This clarifies what the agent can expect from the response.

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, well-structured sentence. It begins with the action and resource, then lists the key return fields without superfluous wording. Every part adds value, making it appropriately concise.

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, one-parameter read-only getter with no output schema, the description provides sufficient context by naming the main response content. It does not discuss error cases or edge scenarios, but the low complexity and safe annotations make this acceptable. A small gap is that 'accommodation' is included but not elaborated, though 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 schema fully describes the only parameter (entity_id) with a clear description: 'The unique entity ID of the campsite'. The description's mention of 'by its ID' adds no new semantics. Since schema coverage is 100%, the baseline of 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?

The description clearly states the verb 'Get' and the resource 'full details for a specific campsite or accommodation by its ID', distinguishing it from search-oriented siblings like search_campsites and list-type tools like get_features. The scope (by ID) is explicit and unambiguous.

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 clearly conveys when to use the tool: when you have an entity ID and need complete details for a specific campsite or accommodation. It does not explicitly name alternatives or exclusion criteria, but the context is strong enough that an agent can infer this is the detail-by-ID endpoint.

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 idempotentHint=true, so the safety profile is known. The description adds that it returns a 'full list' and is for filter clarification, but it does not elaborate on return structure, ordering, or edge cases. This is adequate given the annotation coverage, but no extra behavioral depth 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?

The description is two sentences, front-loaded with the main action and resource, and the second sentence gives a practical use case. 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?

For a simple read-only list tool with one optional parameter and no output schema, the description is adequately complete. It covers purpose, usage context, and relies on annotations for safety. Minor missing details like exact return format are not critical at this complexity level.

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 single optional parameter feature_type has a clear schema description ('Filter by feature category'), providing 100% coverage. The tool description does not add meaning beyond the schema; it merely implies the filter behavior when mentioning 'full list'.

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 action ('Get the full list') and resource ('available features/amenities that campsites can have'). It distinguishes this tool from sibling tools like get_accommodation_types and get_regions by focusing specifically on campsite feature filters.

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 when to use the tool: 'Use this to help users understand what filters are available or to clarify what a feature means.' It provides clear context but does not name alternative tools or explicitly state when not to use it, so a minor gap remains.

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

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

Annotations already cover read-only and non-destructive behavior. The description adds return format ('Returns region names with entity counts') and the optional state filter, which goes beyond the annotations but not extensively. No contradictions.

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

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

Two sentences, front-loaded with action, and every clause earns its place. No fluff or redundancy.

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 list tool with one optional parameter and no output schema, the description covers purpose, usage context, and return content, making it fully self-contained. No additional details are needed.

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 the state parameter already having a description and enum. The description merely reiterates 'optionally filtered by state' without adding new semantic detail, so it meets the baseline but adds no extra value.

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') and clearly identifies the resource ('camping/accommodation regions'), while also stating optional filtering and return content. This distinguishes it from sibling tools like search_campsites or get_campsite_details.

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

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

Provides clear when-to-use context: 'Use this when the user wants to browse by area or doesn't have a specific location.' This gives a strong usage signal, though it does not explicitly mention exclusions or alternatives, missing the full top score.

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

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

Annotations already declare readOnly, idempotent, non-destructive. The description adds valuable behavioral context: automatic GPS lookup for campsite_name via Neo4j, and the return fields (max/min temp, rain chance, etc.). Does not contradict annotations, and adds 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?

The description is well-structured: purpose first, then input options, then return data. Every sentence adds value, no redundancy, and it is appropriately sized for the tool's complexity.

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 3 optional parameters and no output schema, the description fully covers what the tool does, when to use it, how to invoke it, and what it returns. It is complete for an agent to select and use 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 covers 100% with descriptions for each parameter. The description adds relational semantics: 'You can provide EITHER campsite_name OR latitude+longitude', clarifying the mutual exclusivity and how each mode works. This goes beyond the schema's individual parameter descriptions.

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: 'Get a 14-day weather forecast for a campsite or location.' It clearly describes the tool's function and the types of data returned. No sibling tool provides weather, so differentiation is implicit but the scope is well-defined.

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

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

Explicitly states when to use: 'Use this when the user asks about weather, temperature, rain, wind, or UV conditions at a campsite or destination.' It also provides guidance on the two input modes (campsite_name vs latitude/longitude), making it clear how to choose between them.

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, so the safety profile is covered. The description adds behavioral context by explaining how recommendations are derived from campsite features (e.g., fishing → fishing gear, 4WD → recovery equipment), which goes beyond the 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?

The description is three sentences, each earning its place: purpose, examples, and usage guidance. It's front-loaded with the primary action and avoids any 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 simple tool with 2 parameters and full schema coverage, the description is complete. It explains the tool's purpose, provides illustrative examples, and gives clear usage guidance. No output schema is present, so return values are not required to be described.

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 input schema already covers both parameters with complete descriptions (entity_id is 'The campsite entity ID to recommend gear for'; limit is 'Max products to return'). The description doesn't add parameter-specific details beyond what the schema provides, so 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 tool's purpose: 'Recommend relevant products and gear for a specific campsite based on its features and type.' It uses a specific verb ('recommend') and resource ('camping gear'), and provides concrete examples that distinguish it from sibling tools like search_products.

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 when to use the tool: 'Use this when a user asks what to bring or buy for a particular campsite.' It does not explicitly name alternatives or when-not-to-use, but the context is clear that it's for campsite-specific recommendations, not general product searches.

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 description discloses meaningful behavioral traits beyond annotations: it is a live search via DriveAway, returns specific fields (brand, name, sleeps/seats, 4WD, AUD pricing), and includes a booking_url deep-link. It also explains that each result is already complete, preventing redundant follow-up calls. This substantially supplements the readOnly/idempotent 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?

Three sentences that front-load the core action, follow with usage context, and finish with return-value details. Every sentence earns its place; there is no redundancy 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?

Given there is no output schema, the description fully describes the return contents and the booking link, which is essential for an agent to know what to expect. It also covers the geographic scope, the live nature, and the distinction from sibling tools, making the description complete for practical 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 descriptions already cover all 5 parameters with examples and ranges, so the baseline is 3. The description adds contextual semantics: 'Australia only' clarifies pickup_city validity, 'AUD price' implies currency expectations, and 'nightly and total' clarifies what the price amounts represent, going slightly beyond the raw 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 opens with a specific verb+resource: 'Search live campervan / motorhome hire availability and pricing' for a pickup city and travel dates. It explicitly distinguishes itself from sibling tool search_campsites, stating it is for RENTING rather than camping.

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 provides explicit guidance: 'Use this when the user wants to RENT a campervan, motorhome or RV' and contrasts directly with search_campsites. It also notes 'Australia only' as a hard constraint and clarifies that no separate resolve step is needed, helping the agent decide when to invoke this tool.

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 annotations (readOnly, idempotent, not destructive), the description discloses critical behavioral traits: 'results never mix countries', 'Only campsites that have ALL requested features will be returned', and the pet policy with 'NEVER recommend a campsite with No Pets'. This adds substantial context not present in 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?

The description is quite long but well-structured with clear section headers (COVERAGE, IMPORTANT, CRITICAL). It front-loads the purpose in the first sentence. The length is justified by the need to explain feature names and pet policy, but it still could be trimmed without losing essential info.

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 10 parameters, no output schema, and no required params, the description is remarkably complete. It explains country coverage, feature filtering behavior, pet policy, entity types, and provides coordinate examples for near_latitude/longitude. No critical gaps remain for an agent to misunderstand tool usage.

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 schema already provides 100% parameter descriptions, so the baseline is 3. The description adds extra semantic depth through the AVAILABLE FEATURE NAMES list, the pet-policy mapping, and entity_type examples (free camping, caravan parks, etc.), which go beyond the schema's per-parameter descriptions.

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 'Search for campsites, caravan parks, or accommodation by location, features, and other criteria' — a specific verb+resource. It also distinguishes itself from sibling tools with the directive 'Use this when the user asks to find a place to stay, camp, or explore.'

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 'Use this when...' sentence provides clear contextual guidance, and the coverage section explains when to set the country parameter. However, it does not explicitly mention alternatives or exclusions (e.g., 'use search_campervans for campervans'), so it lacks fully 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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to restate safety. It adds 'available in the Camping Australia store' (scope limitation) and the 'what to buy/bring' use case, which are useful behavioral cues. However, it doesn't add further details like response format or filtering 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 sentences, front-loaded with the action and resource. The second sentence is a direct usage trigger. No wasted words or repetition of schema details.

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

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

For a read-only search tool with three well-documented optional parameters and no output schema required, the description is sufficient. It tells the agent what the tool searches and when to use it. The annotations cover safety, and the schema covers parameters, so no critical 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?

Input schema covers 100% of parameters with descriptive text for each (limit, query, product_type). The description's list of product types ('gear, outdoor products, accessories') loosely maps to query/product_type but adds no syntax or format details beyond what the schema already 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?

The description uses a specific verb ('Search') and resource ('camping gear, outdoor products, and accessories available in the Camping Australia store'). It clearly distinguishes itself from sibling tools like search_campervans and search_campsites by focusing on store products and gear.

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

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

Provides explicit when-to-use guidance: 'Use this when a user asks about gear, equipment, products, or what to buy/bring.' It does not mention when not to use it or name alternative tools, so it misses the top bar but still gives clear context.

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