Booking Bench

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuine value by naming the fields that come back (category, location, website, admission, contactInfo, source, commercial), which no output schema provides, but says nothing about not-found behavior or site scoping.

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?

One front-loaded sentence with no filler; the field list is terse but every token carries information. The trailing enumeration is slightly list-like but appropriate given there is no output schema.

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

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

For a two-parameter read-only getter whose annotations cover safety and whose schema fully documents both inputs, the description supplies the one missing piece: what the response looks like. Nothing essential to invoking it correctly is absent.

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

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

Schema coverage is 100% and both parameters carry descriptions pointing to list_sites and list_activities as sources of the values, so the schema does the heavy lifting. The description adds no additional meaning about siteSlug or activityId.

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 ("Returns one activity") and enumerates the returned fields, which is far more specific than the title's restatement. It implicitly separates itself from list_activities by saying "one activity", but never names that sibling explicitly.

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

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

There is no when-to-use guidance, no mention of the list_activities alternative, and no statement of what happens when the activity does not exist or the slug is wrong. The only cue is the word "one", leaving the agent to infer this is a single-record lookup by id.

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 destructiveHint=false, so the safety profile is covered. The description still adds real behavioral context beyond them: the fixed two-month window and the fact that prices are per night before cleaning fee and taxes. It leaves open what happens at range boundaries or for unbookable days.

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 with no waste. The return scope is front-loaded ahead of the price caveat, and every clause carries information the caller needs.

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?

All four required parameters are fully documented in the schema and the tool is a safe read, so the bar is modest and the description meets it. With no output schema present, it could have sketched the per-day record shape a bit more (e.g. booked vs available) to fully stand in for the missing return contract.

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 the baseline is 3, but the description genuinely extends the schema: it clarifies that year/month denote the START of a two-month window and that propertyId refers to a single unit, neither of which the schema states on its own.

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 verb and resource ('Returns day-by-day availability and nightly price for one unit') and pins the scope precisely ('two consecutive months starting at the given month'). That scope makes it clearly distinct from get_property (metadata) and get_quote (priced quote) without needing to open a 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?

There is no explicit when-to-use guidance and no named alternative, even though get_quote is an obvious overlap given this tool also returns prices. The note that prices exclude the cleaning fee and taxes hints that get_quote is needed for totals, but the agent must infer that routing itself.

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 destructiveHint=false, so safety is covered. The description adds value by specifying that the response contains the *full* record across all those fields, which is behavioral context not in the annotations. It omits error behavior for a nonexistent event and whether siteSlug scopes or merely routes the lookup.

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 return-field enumeration is dense but every item is meaningful since no output schema exists. The trailing field list reads slightly like a raw dump, which keeps it from a 5.

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 a two-parameter, fully described schema, complete annotations, and no output schema, the description covers the essentials: it establishes the single-record scope and enumerates the returned data. Error handling and the siteSlug/eventId relationship are the only real 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 description coverage is 100%; both eventId and siteSlug are documented in-schema, including their patterns and provenance (list_events, list_sites). The description says nothing about either parameter, so baseline 3 applies — no meaning is added 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?

"Returns one event" names a specific resource and cardinality, and the enumerated fields (description, dates, location, admission, ticketUrl, contactInfo, source, commercial) make it clear this is a full-record fetch rather than a list. The list_events sibling is implicitly distinguished by cardinality, but the description never names it, so it falls short of explicit sibling differentiation.

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

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

Usage is only implied: an agent must infer that this is the tool to call when it already has an eventId obtained from list_events. There is no explicit when-to-use, no statement that list_events should be used first to discover IDs, and no guidance for what happens with a stale or unknown ID.

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 readOnly/idempotent annotations it discloses substantive behavior: the nightly rate is a cached value up to 6 hours stale and not a price, photos are truncated to 5 with imageCount carrying the true total, only the 3 newest reviews are returned and are quoted guest text, and street address plus coordinates are deliberately withheld. These truncation and staleness caveats are exactly the kind of detail an agent cannot infer from the 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 content is packed into two long sentences that are dense but front-loaded with the resource and its fields before the caveats, so the most important information lands first. It is close to a field dump, but every clause carries a real constraint, so nothing is obviously wasteful.

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

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

With no output schema and only two simple parameters, the description carries the full burden of explaining return values and does so field by field, including truncation limits and omitted data. An agent can call this tool and correctly interpret its response without further documentation.

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 each of the two required parameters is already documented in the schema as coming from list_sites and list_properties respectively. The description adds no additional meaning about siteSlug or propertyId, so the baseline of 3 applies; the intake path is already fully covered by 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 opens with a specific verb and resource ('Returns one unit') and enumerates the fields returned, so the agent knows exactly what it retrieves. It implicitly contrasts with list_properties by being singular, but never names the sibling explicitly, and the title ('Get one unit's details') differs from the name get_property, leaving a small ambiguity about whether it is a unit or a property record.

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

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

It gives a clear usage boundary for the rate field: indicativeNightlyRate is a cache-derived guide and 'get_quote returns the price for dates', which routes the agent to the correct alternative for pricing. What it does not state is when to call this versus list_properties for a broader sweep, so guidance is strong on one axis but not exhaustive.

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, openWorld and non-destructive, so the safety profile is covered; the description adds genuinely useful behavior beyond that, notably that totalPrice excludes taxes and other fees, that taxesIncluded flags this, that eventsDuringStay is capped at 5 with a total count, and the full enumeration of unavailability reasons.

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?

Dense but front-loaded: the success payload is listed first, then the failure shape. Slightly list-heavy and could be split for scannability, 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 full burden of explaining return values and does so in detail for both success and failure paths; the only gap is that it does not describe caching/volatility of a 'live' quote or how pricing varies by guest count.

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 all five parameters are already documented with patterns and bounds; the description adds no per-parameter meaning beyond implying that dates and guests drive the quote, which the schema already makes obvious.

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?

Opens with a specific verb and resource ('Returns a live quote for one unit and stay') and immediately contrasts with what sibling tools like get_property would return, so an agent can tell it is the pricing call rather than a static detail lookup.

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

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

The description implies usage through the bookable/not-bookable framing and names the failure reasons an agent will hit, which helps it interpret results, but it never states when to call this versus get_property or get_calendar, nor that siteSlug must come from list_sites first (that hint lives only in the schema).

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 establish read-only, idempotent, non-destructive, closed-world behavior, so the description is not burdened there. It goes beyond them by disclosing result ordering, the exact fields returned, and the meaning of two trust-relevant fields: source (property_manager = the site's own manager) and commercial (paid placement), which matters for how an agent weighs results.

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, front-loaded with the action and scope before the field inventory and the response shape. The middle sentence is a long enumeration of fields, but each item (source, commercial) carries meaning rather than padding.

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 takes on the return-value job and does it: it names the record fields and the envelope (total, per-category counts, nextCursor). Given full schema coverage, a single site-scoped list tool is adequately covered, with only minor gaps such as default limit or pagination mechanics.

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 parameter meaning is already carried by the schema, making 3 the baseline. The description adds nothing parameter-specific beyond noting the site scoping and that nextCursor comes from the answer, which only lightly reinforces the cursor parameter.

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 ("Lists things to do near one Booking Bench site"), plus scope (single site) and ordering (alphabetically), which separates it from get_activity. It does not explicitly contrast with list_events, so the sibling boundary is only inferable from the resource noun.

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: the agent needs a siteSlug (documented in the schema as coming from list_sites) and this is a browse/list operation. There is no explicit when-to-use vs get_activity or list_events guidance, and no statement about when not to use it.

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, closed-world and non-destructive, so safety is covered. The description adds real value beyond that: sort order, the pagination envelope (total, per-category counts, nextCursor), and domain semantics for 'source' (property_manager = site's own manager) and 'commercial' (paid placement) that an agent could not infer elsewhere.

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, front-loaded with the core action and ordering before the field inventory. The field list is dense but each item carries meaning; no filler or repetition of the title.

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, and the description compensates by enumerating returned fields and the response envelope. Combined with fully documented parameters and annotations covering the safety profile, an agent has what it needs to call this correctly; only the default time window is left implicit.

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

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

Schema description coverage is 100%, so every parameter is already documented with format patterns and constraints. The description concentrates on return fields rather than adding parameter meaning; its only param-adjacent contribution is reinforcing cursor round-tripping and category keys, which the schema already states.

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 ('Lists upcoming events'), plus the scope ('near one Booking Bench site') and ordering ('earliest first'). It is clearly distinct from get_event and get_calendar, though it never names those siblings explicitly.

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

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

Usage is only implied: 'upcoming' plus a single-site scope tells the agent roughly the context, and the schema ties siteSlug to list_sites. There is no explicit guidance on when to use this versus get_event (single lookup) or get_calendar, and no stated exclusions or 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?

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: availability is up to 5 minutes stale, more than 10 matches return the best 5, totalMatchesAtLeast signals partial checking, refinements and notes are returned, and a used default for guests is reported. It even discloses that no result is ranked by payment, which is useful trust 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?

Front-loaded with purpose, then parameters, then return shape, with no filler sentences. It is dense for a single paragraph and interleaves input and output details, which slightly hurts scannability, but every clause carries information an agent needs.

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 fully carries the return contract: propertyId, name, city, state, sleeps, bedrooms, bathrooms, averageNightlyRate, plus returned, totalMatches/totalMatchesAtLeast, nextCursor, refinements and notes. For a 12-parameter search tool this is complete enough to call correctly on the first attempt.

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 the baseline is 3, but the description adds real meaning: sort=fit is defined as smallest unit that sleeps the party, then bedrooms, then name; amenities must ALL be listed; guests default and its reporting; and averageNightlyRate is scoped to per night over the stay before cleaning fee and taxes. It does not elaborate on limit/cursor interplay, which keeps it from a 5.

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 ('Lists the units on one Booking Bench site that can be booked for a stay') and immediately scopes it by availability rules and guest capacity. It is clearly distinguishable from get_property (single unit), list_sites (sites, not units) and get_quote (live pricing), so an agent can select it 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?

Gives concrete usage context: checkIn and checkOut are required, guests defaults to 2, and it names the optional filters and sort options. It also routes the agent to get_quote when live availability/pricing is needed, but it does not explicitly state when to prefer get_property or list_sites instead.

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), and the description adds substantial behavior beyond them: nearest-first ordering, five per page, straight-line whole-mile distances measured between town centers, daily-rotation tie-breaking, and totalMatches/nextCursor pagination. The fallback behaviors for ambiguous city names and misspellings are disclosed rather than left to discovery.

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 what the tool returns and its ordering, then the parameter caveat, then the result shape, then edge cases. Every clause carries operational information; nothing is repeated from the schema or title.

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 must carry the return contract, and it does: it enumerates every result field, the totalMatches count, and nextCursor for continuation. For a five-parameter read tool with full annotation coverage, nothing an agent needs in order to call it or interpret the answer is missing.

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

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

Schema coverage is 100%, so the schema already documents each parameter and the baseline would be 3. The description still adds meaning: it fixes the semantics of `city` as the destination, not the caller's location, and supplies a default page size of five that the schema itself does not state for `limit`. It does not clarify the interaction between `state` and `city` beyond noting that multi-state names return candidates.

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 ("Lists live Booking Bench sites that have rental units") plus scope (in or near a US destination city), ordering (nearest first) and page size (five per page). An agent can tell this apart from list_properties, which returns units rather than sites, without opening either 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 explicit context for the ambiguous case: "`city` is the destination the traveler names, never the traveler's own location," which is the main way this call could be misused. It also explains the multi-state and misspelling outcomes. It stops short of naming a sibling or stating when-not to use it, so it does not reach the top band.

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