Posadita – direct-booking holiday rentals

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds real value: the 62-day-per-call limit, the per-night fields returned, and the meaning of priceCents=null when the place takes no online booking.

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 tight sentences, front-loaded with the core question and the 62-day cap, then return shape, then the sibling pointer. No wasted text, though slightly dense.

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

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

No output schema exists, so the description carries the return-value burden and does so by enumerating each night's fields. Limits and pricing caveats are covered; only minor gaps remain, such as ordering or error 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 coverage is 100%, so from/to/slug are already documented in the schema. The description adds only the 'both inclusive' range clarification and reinforces that prices are nightly; baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb+resource: determining which nights are free between two dates for a given place. It distinguishes itself from the pricing sibling by explicitly naming get_quote for whole-stay prices, so an agent can tell it apart without opening the schema.

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

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

Explicitly routes whole-stay pricing to get_quote and clarifies that nightly prices exclude fees/discounts. Clear usage context for that alternative, though it does not mention search_stays or get_property or state when-not to call this.

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 only declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false; the description adds substantial behavioral context beyond them — no reservation or hold is created, nothing is sent to the host, the returned link expires after 24 hours, anyone else may book the nights in the meantime, and there is a per-caller rate limit. This is exactly the disclosure an agent needs for a non-idempotent, non-holding link-generation call, and it contradicts nothing in 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 front-loaded with the core action and return value, and the negative guarantees are stated up front where they matter. It is slightly redundant in places ('reserves NOTHING and books nothing: no nights are held, the host is not told, no e-mail is sent'), but that emphasis is defensible for a tool whose failure mode is an agent falsely telling a guest they are booked.

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 nine-parameter tool with a nested guest object and no output schema, the description covers what is returned (checkoutUrl), who must act on it (the guest), its expiry (24 hours), the booking race condition, and rate limits. Nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters, including that guest/contact details and message are optional and pre-fill the form. The description restates this ('contact details are optional and only pre-fill the form, which the guest can change') but adds no syntax, format, or constraint detail beyond what the structured schema provides, so 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 states a specific verb and outcome — preparing a stay for the guest to confirm and pay, returning a checkoutUrl — and immediately bounds the scope with what it does NOT do (reserves nothing, books nothing, no email). It also distinguishes itself from the siblings by naming the required prerequisite step ('Quote first', i.e. get_quote), so an agent can place it in the workflow without opening schemas.

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

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

It gives clear sequencing guidance ('Quote first') and explicit when-not-to-act instructions ('Never tell the guest they are booked, and never try to complete the booking for them'), plus a rate limit. It does not explicitly name the alternative sibling tools by name, which keeps it just short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description earns credit for going beyond them: address rounding when the host keeps it private, fixed amenity ids plus labels, and the meaning of bookable:false. It still doesn't cover pagination or return format, but the added domain context is substantive.

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

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

The return-field inventory leads, followed by two compact sentences on bookable:false and bookingMode. Dense but each sentence carries useful information with little waste.

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 helpfully enumerates what a single-property fetch returns, and annotations handle the safety profile. Behavior for the key edge cases (private address, unbookable listing, booking modes) is disclosed, leaving only minor gaps like pagination/error 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%, so the schema already documents both slug and locale (including the enum and default). The description adds no further parameter syntax or format detail, making the baseline 3 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 names a specific resource — a single holiday rental — and enumerates the fields it returns (capacity, amenities, house rules, check-in/out, cancellation policy, photos, from-price). It clearly implies a single-property detail lookup, but it never explicitly distinguishes itself from siblings like search_stays or get_quote.

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

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

It gives a when-not caveat ('bookable: false ... do not quote or prepare a checkout for it'), which steers the agent away from create_checkout/get_quote for unbookable listings. However, it does not say when to reach for get_property versus search_stays or check_availability, so usage is only implied.

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, idempotent, non-destructive, but the description goes further: amounts are integer cents, the failure envelope is spelled out (ok:false with unavailable/min_stay/no_checkin_day/no_checkout_day/max_guests/no_rates/invalid_range), and 'A quote holds nothing' confirms no persistence. This is substantive behavioral context an agent cannot get from 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?

Front-loads the core purpose, then layers units and the failure taxonomy in three tight sentences with zero filler. The parenthetical breakdowns are efficient rather than 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?

With no output schema, the description carries the return-value burden and does so for the failure path and the breakdown components. It stops short of the success envelope shape (field names/currency) and any auth or rate-limit context, but is otherwise complete for a read-only quote tool.

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

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

Schema coverage is 100% – all five params (slug, checkIn, checkOut, adults, children) are documented in the schema itself, including format notes like 'that night is not included'. The description adds no parameter-level syntax or constraint beyond that, 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 operation (total price of one stay for a party) with an enumerated breakdown (nights, length discount, extra-guest fee, cleaning) and clarifies it is 'the same calculation that charges the guest'. An agent can immediately separate this pricing tool from check_availability or create_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?

Usage is implied rather than stated: the error reasons (min_stay, no_checkin_day, max_guests) indirectly reveal booking constraints, but the description never says when to prefer this over check_availability or that a quote should precede create_checkout. No explicit alternatives or exclusions are named.

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 read-only, idempotent, non-destructive, closed-world, so the burden is low; the description nonetheless adds substantial behavior: pricing semantics with vs without dates, that totalCents matches get_quote, result ordering with bookable places first, and the from-price-per-night fallback. These are outcome-shaping facts an agent cannot get from 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?

Four dense sentences, front-loaded with the scope constraint and then the pricing behavior; each sentence carries information an agent needs. The middle sentences are long and clause-heavy, which costs a little readability without adding waste.

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, 8-parameter search with no output schema, the description covers the important return facts (totalCents, from-price, bookable flag, ordering) and the collection-resolution path. It omits pagination/result-count behavior and any mention of the filtering parameters (amenities, minBedrooms), which leaves a small gap an agent may have to probe for.

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 75%, so the baseline is 3. The description adds real meaning for `collection` (slug origin, posadita.com/s/{slug}, /llms.txt) and for the date pair (pricing behavior), but says nothing about minBedrooms, propertyType, availableOnly, or the all-of-not-any amenity semantics — the latter is only carried by 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 and resource ('Search ONE collection – a host's portfolio, a residential community or a destination') and explicitly bounds the scope with 'There is no search across all of Posadita.' That boundary alone lets an agent distinguish it from sibling tools like get_property and check_availability without opening any schema.

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

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

Gives clear conditional usage: with dates and guests every place is priced for that stay and bookable ones sort first; without dates you get from-prices. It also names the downstream gate ('Only places with bookable:true can be quoted or checked out') and names get_quote as the equivalent figure. It stops short of an explicit 'use X instead when Y' routing statement for get_property/check_availability.

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