Campiamo Campsites

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), so the description's real contribution is behavioral detail it adds beyond them: it returns not just availability but pricing (total price, amount due at checkout) and explains negative results by reason (fully booked, minimum stay, adults only, no dogs). That is genuinely useful for interpreting an empty result, though it says nothing about rate limiting or how 'live' data may change.

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 dense sentence with the purpose front-loaded and the explanatory parenthetical at the end; every clause carries information about scope or output. It is long and slightly run-on, but no sentence is 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 carries the return-value burden and does so adequately, enumerating the result categories and the reason codes for non-availability. It stops short of covering error conditions (bad slug, check_out before check_in) but covers what an agent needs to interpret a normal response.

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 seven parameters (including the age-policy nuance for children and the infants constraint) are already documented in the schema. The description adds only the word 'party' and echoes the dog/adult restrictions as exclusion reasons; it contributes no format, default, or interaction detail beyond the schema. 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 ('Live availability at one campsite for a stay and party') and immediately scopes it to a single campsite, which separates it from search_campsites and get_quote without naming them. It also discloses the substance of the result (accommodation types, total price, amount due), so an agent knows what it is asking for.

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

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

The phrase 'for a stay and party' implies the pre-booking check context, but the description never says when to use this versus get_quote or start_booking, nor any prerequisite (e.g. campsite slug must come from search_campsites). 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description's safety burden is low. It adds substantive context by enumerating exactly what data will be returned (accommodation types, payment terms, reviews), which helps agents predict the response shape. No contradiction with annotations.

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

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

The description is a single dense sentence that front-loads the core promise and then lists contents in a readable sequence. It is efficient and free of fluff, though a bulleted list would improve scannability slightly given the many items enumerated.

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?

Without an output schema, the description thoroughly documents the return value, covering descriptions, photos, check-in times, season, accommodation types with prices and rules, optional extras, booking questions, payment terms, and reviews. This is sufficient for an agent to correctly invoke the tool and interpret its result, leaving no critical gaps.

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

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

Schema coverage is 100% and the schema already specifies that 'campsite' is a slug from search_campsites. The description adds only minimal reinforcement that it targets 'one campsite' rather than multiple, which is a marginal semantic improvement over the structured data.

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 'Full details of one campsite' with an explicit verb-implied resource, making it clear this is a read operation for a single campsite's detailed information. The enumerated content (photos, times, prices, reviews) clearly distinguishes it from sibling tools like search_campsites, check_availability, and get_quote, which serve different purposes.

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 use when an agent needs comprehensive details about a specific campsite after obtaining a slug via search_campsites. However, it does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria, so usage guidance is only implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds useful behavioral context beyond that: a quote is non-committal and precedes booking, and it discloses that discounts and vouchers are factored in and that an 'amount payable now' (deposit-style) figure is returned.

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, zero filler, with the resource definition front-loaded and the usage guidance immediately after. 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?

No output schema exists, so the description must signal what comes back; it does ('itemised price', 'exact total and the amount payable now'). Combined with rich schema documentation and annotations, an agent has what it needs, though a note on whether the quote expires or holds inventory would close the last gap.

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

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

Schema description coverage is 100%, with every parameter and the nested extras fields documented in the schema itself, including conditional rules (infants only where age_policy allows, child age varies by campsite). The description only restates extras/discount/voucher at a high level, adding no syntax or format beyond the schema, so 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 ('An itemised price for one accommodation, stay and party') and scopes exactly what inputs are priced (extras, discount/voucher code). It implicitly distinguishes itself from start_booking by framing it as the pre-booking step, though it never names check_availability or get_campsite directly.

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

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

Gives clear context: 'Use it to show the guest the exact total and the amount payable now before starting the booking.' This states when to reach for it and where it sits in the sequence. It does not explicitly exclude alternatives (e.g. that it does not reserve inventory), leaving some inference.

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

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

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so safety is covered. The description adds a useful scope limitation (only Campiamo-affiliated sites are searched) and notes the slug output, but omits pagination, result-ordering, or cost of a date-based query.

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, zero padding, with the searchable corpus and the filtering axes front-loaded before the return-value note. 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?

There is no output schema, so the description correctly states what comes back (the slug for downstream tools). Combined with strong param docs this is nearly complete; only the limit/pagination behavior is left unexplained.

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 90% schema coverage the baseline is 3, and the description earns an extra point by explaining what free-text query matches (name, town, county, country, description) and that supplying dates triggers live availability and total stay price computed for the party.

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 precise verb (Find) and resource (campsites, glamping sites, holiday parks) and bounds the corpus to Campiamo's directory plus hosted sites. The scope statement alone lets an agent tell it apart from narrower siblings like get_campsite.

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 the use case (discovery via free text, country, amenities, and optionally dates for availability/price) but never names an alternative or a when-not condition, which matters because check_availability and get_quote overlap with the date-based mode described here.

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?

Although annotations already declare readOnlyHint=false and idempotentHint=false, the description adds context annotations cannot express: deferred commitment ('Nothing is reserved until the guest pays'), the 24-hour link expiry, the downstream use of the guest's email for confirmation, and an explicit rate limit. These are exactly the behavioral traits an agent must know before calling.

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

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

Six short sentences, each carrying a distinct fact (capability, deferred payment, eligibility, fallback path, guest prerequisites, confirmation instruction, rate limit). The most decision-relevant constraint (nothing reserved until payment) is front-loaded; there is 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?

For a 16-parameter, nested, non-idempotent mutation with no output schema, the description covers eligibility, prerequisites, guest confirmation, and the return artifact (checkout link), so return values need not be explained. It omits any instruction to verify availability/price first (e.g. via check_availability or get_quote), a workflow step an agent would otherwise have to infer.

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 94%, so the schema already documents nearly every parameter in depth. The description only restates the guest name/email requirement, which the schema already explains ('Where the confirmation is sent'), and adds nothing about extras, answers, children/age_policy, or club_membership. Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Start a booking') plus the concrete artifact produced ('a secure checkout link for the guest'), and clarifies that nothing is reserved until payment. It does not explicitly differentiate itself from the sibling get_quote, which an agent could reasonably confuse it with, so it falls short of a 5.

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

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

Explicit when-to-use conditions ('Only works at campsites that take payment online (assistant_can_book is true)'), an explicit alternative path for when it does not apply ('send the guest to the booking_url to book themselves'), plus a prerequisite ('Confirm every detail with the guest first'). This is close to textbook routing guidance.

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