TF Rooms

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavior: it queries all twelve properties live at call time, applies each property's live minimum stay (1 night for single/double, 7 for studio), returns nightly rates for sub-week stays, and refuses 30+ night stays up front.

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 and answer-first, but wordy and narratively styled with all-caps emphasis (CAPACITY, not vacancy). The 30-night cap is stated twice in consecutive sentences, and the minimum-stay sentence is dense enough to slow parsing.

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 carry return expectations, and it partially does (availability per property, nightly rates for sub-week stays). It is silent on the response shape for studios, multi-week stays, or properties with no vacancy.

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 this is baseline 3 territory, but the description adds the semantics behind the fields: omitting dates means tonight, and roomtype ties to the differentiated minimum-stay rules per room category. That meaning goes beyond the terse schema strings.

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 resource and scope: live room availability across the twelve named New Leaf properties in Twin Falls for given nights. It also implicitly separates itself from rate feeds by explaining that published feeds carry capacity, not vacancy, so an agent can tell it apart from get_rates and quote_stay.

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 conditions: supply dates, call without dates for tonight, and a hard exclusion (stays over 30 nights are refused). It does not explicitly route the agent to siblings such as quote_stay for a firm price or list_properties for inventory descriptions.

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 annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety is covered. Beyond that the description adds genuinely non-obvious domain behavior: an 8% Idaho lodging tax, a 30-day cap, a weekly-only studio rule, and the fact that $1,000 is never a monthly rate — context an agent could not get from structured fields.

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 core ('What a room costs across the portfolio, by the night and by the week') is front-loaded, which is good. But the whole thing is a single run-on sentence with a colon list that ends on the cryptic 'why $1,000 is never a monthly rate', which reads as trivia rather than actionable context.

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 parameters and no output schema, the description should at least hint at the return shape, and it does so only conceptually (per-night, per-week, plus rules). It is adequate for a simple read tool but leaves the response structure and the sibling routing question unanswered.

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 tool takes zero parameters, so there is no parameter semantics to document and the baseline is 4. Nothing in the description misleads about inputs.

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 conveys the resource — nightly and weekly room costs across the portfolio plus the stay rules (minimum stay, sub-week pricing, 30-day cap, studio rule, lodging tax). What it lacks is any differentiation from the sibling quote_stay, which plausibly overlaps on 'how a stay under a week is priced', so an agent cannot tell from the description which tool to reach 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?

There is no explicit when-to-use or when-not-to-use guidance, and no routing to alternatives. Given a sibling named quote_stay, the absence of any line like 'use quote_stay for a dated price' leaves the most important selection decision to 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 readOnly, idempotent, non-destructive and closed-world, so safety is covered; the description adds the important behavioral boundary that results are static catalog facts, not live availability. It does not discuss permissions, rate limits, or refresh/caching of the static data, so it stops short of full disclosure.

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: the first front-loads the payload, the second front-loads the scope limit and the redirect. No filler or redundant restatement 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?

For a small, bounded, read-only catalog tool with no output schema, the description supplies the returned fields, the dataset size, and the critical limitation versus live availability. Nothing an agent needs in order to call it correctly 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% and the single optional roomtype filter is fully documented in the schema, so the baseline applies. The description mentions room types only as a returned field, adding no filtering semantics such as behavior when roomtype is omitted or invalid.

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 plus the exact payload: the twelve New Leaf properties with name, address, phone, room types sold online, rates and booking URL. An agent can distinguish this inventory listing from the availability/rate siblings 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 bounds the scope ('static facts only — it says nothing about whether a room is free tonight') and names the alternative, find_rooms, for that need. When-to-use and when-not-to-use are both stated outright.

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 read-only/idempotent annotations, it discloses that the property is queried live, that the answer is returned verbatim from the booking form, and that a refusal is propagated when a stay cannot be sold. That is genuine behavioral context, though nothing is said about latency or failure modes other than refusal.

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 what the tool returns and then the usage boundary. Slightly wordy in the 'word for word, so the figure is the one its booking form uses' clause, but every sentence 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?

With no output schema, the description carries the burden of describing the return value and does so concretely (nights, tax, amount paid at property), plus the refusal case. Nothing an agent needs to call this four-required-parameter tool correctly 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 property, roomtype, checkin and checkout are already documented in detail, including slug/short-name handling and room-type aliases. The description only restates that these four inputs are required, adding no new meaning, which is the baseline 3 case.

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 opening clause states a specific resource and result: the total for one stay at one property, broken into nights, tax and pay-at-property. It also explicitly separates itself from find_rooms by declaring that it returns a price, not availability.

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 positive precondition ('once the property, room type and dates are known') and an explicit alternative with the condition that selects it ('use find_rooms to see which properties have a room free'). No inference is required to choose between the two.

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