OkeyStay

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the return contents and the 93-day range limit, but says nothing about what happens when the range is exceeded, whether unavailable nights are omitted or flagged, auth requirements, or rate limits.

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 resource, the returned fields, and the range constraint are all packed in 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?

For a simple three-parameter read tool with no output schema, the description covers what is returned and the range cap. It is nearly complete, though edge-case behavior (over-93-day requests, invalid slug) is not addressed.

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 67%: 'from' and 'to' are only labeled 'YYYY-MM-DD' and 'slug' has no description at all. The description adds genuine meaning by capping the from/to window at 93 days and implying slug identifies a single stay, but it does not compensate for the undocumented slug semantics.

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 (day-by-day availability) plus the returned fields (nightly price, minimum stay) and a hard scope (one stay, up to 93 days). The 'one stay' framing implicitly separates it from the bulk search_stays, but no sibling is named explicitly, so differentiation is inferred rather than stated.

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: call this when you need daily prices/availability for a specific stay over a bounded window. The 'up to 93 days' cap gives an implicit limit on the date range, but there is no explicit when-to-use versus get_stay/search_stays, and no stated prerequisites.

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 does disclose one conditional behavior — that passing dates adds total price and availability to the response — which is genuine beyond-schema context. It says nothing about error behavior for unknown slugs, locale fallback, permissions, or response size, so the disclosure is 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?

A single front-loaded sentence that leads with the scope ('Full listing of one stay') and then lists contents; no filler. It is a long run-on enumeration, but each item earns its place by telling the agent what to expect back.

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 4-parameter read tool with no annotations and no output schema, the description effectively substitutes for the missing output schema by enumerating the returned fields, and it covers the conditional effect of dates. The gap is sibling differentiation — an agent choosing between this and get_availability gets no routing 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 coverage is 75%, with locale/checkIn/checkOut documented but slug left bare. The description adds real meaning the schema lacks: checkIn/checkOut are not just date strings but a switch that turns on total price and availability computation, and it frames the call around a single identified stay. It does not clarify the slug format or locale's effect on the enumerated fields.

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 (retrieve the full listing of one stay) and enumerates the returned content — description, highlights, FAQ, capacity, times, registration number, distances, price/availability. An agent can tell this is a detail-lookup tool rather than a search. It does not, however, name or distinguish itself from siblings like get_availability or search_stays, which overlap on the availability/price content.

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: use this to get everything about a single stay, and supply dates if price and availability are needed. There is no explicit when-to-use versus get_availability or search_stays, and no stated prerequisite (e.g., that a slug from search_stays is required).

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 well: it discloses that the tool only checks and prepares a link, that the traveller confirms and pays externally, that the price includes cleaning, and that card details must not be collected in chat. It omits failure behavior (what happens when dates are not free) and any rate-limit or error context.

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, front-loaded with the core behavior and followed by the essential agent instruction about the booking link and card details. No filler; 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 5-parameter tool with no annotations and no output schema, the description usefully enumerates what is returned (total price, cancellation policy, booking link). It leaves the 'slug' input and the locale parameter unexplained, which is the main remaining 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 coverage is 60%, so the description needs to compensate. It mentions 'dates and guests' generically but never defines the required 'slug' (the stay identifier is only implied by 'a stay') and never mentions the 'locale' parameter at all. It adds little meaning beyond what the partially-documented schema already provides.

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

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

The description states a specific verb and resource (check availability, return price/policy/booking link) and names the concrete outputs, so an agent knows exactly what it gets. It does not differentiate itself from the sibling get_availability, which appears to also check free dates, so sibling differentiation is missing.

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

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

The description gives strong post-call workflow guidance ('give the link to the traveller', 'never ask for card details'), but never says when to choose this over get_availability, get_stay, or search_stays. Usage is implied by the booking-link framing but no explicit selection criteria are given.

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 what each result contains (registration number where legally required, town derived from coordinates, measured beach/airport distances) and explains the conditional pricing behavior. It omits pagination/result caps, rate limits, and whether an empty result is possible, which are the remaining 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?

Four sentences, front-loaded with the core purpose before the filter and pricing details. The listing-attribute sentence is informative rather than filler, though slightly verbose in its phrasing ('its real town worked out from the map coordinates').

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 explain returns, and it does: listing attributes plus the two distinct price models depending on whether dates are supplied. For a five-parameter, all-optional search tool with no annotations, this covers everything an agent needs to call it correctly.

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

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

Schema coverage is 80%, so the schema already documents place, locale, and the date formats. The description adds real meaning beyond that: checkIn/checkOut jointly switch the price semantics from nightly-lowest to total-stay-including-cleaning, and omitting place returns destinations rather than listings. The guests parameter remains unexplained in both places, keeping this at the schema-driven baseline.

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 holiday rentals') and enumerates the filters (town, dates, guests), so the agent knows exactly what operation this performs. It does not name the sibling tools (get_stay, get_availability, prepare_booking) to draw the boundary explicitly, so differentiation is inferred rather than stated.

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 concrete usage recipes: pass checkIn/checkOut to get total stay price, omit dates to get the lowest nightly price over the next 60 days, and omit place entirely to discover available destinations. It lacks explicit guidance on when to prefer this over get_availability or get_stay, but the parameter-level guidance is strong.

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