STR Host Tools

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a side-effect-free calculation. The description adds the business framing (payout parity across a fee-structure change) but does not say whether anything is persisted or whether the result is a recommendation versus a synced price, and it restates defaults that the schema already carries.

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 scenario constraint up front and the two default rates parenthetically embedded — no waste. It loses a point only because the sentence is grammatically a fragment, which makes the intended action harder to parse quickly.

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 five-parameter, zero-required calculation tool with full schema coverage and a read-only annotation, the description covers the domain adequately. However, with no output schema it never indicates what the agent should expect back (a single repriced figure, a comparison, or a drop amount), which is the main missing piece.

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 mode, price, new_rate, guest_fee, and old_host_rate, including their defaults; the baseline is therefore 3. The description supplies context for why the two fee rates exist (old vs new regime) but adds no syntax, units, or constraints 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?

The description identifies the domain precisely (an Airbnb repricing calculation tied to the split-fee to host-only-fee transition), but it is a noun phrase with no verb — it never says whether the tool computes and returns a price, updates a listing, or merely compares scenarios. It also never contrasts itself with the sibling vrbo_reprice, leaving the Airbnb-vs-VRBO distinction to the tool name alone.

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?

No when-to-use guidance appears in the description; the only mode guidance (pass vs absorb) lives in the schema. No alternatives or prerequisites are mentioned, and the sibling vrbo_reprice is not referenced as the tool for the competing platform.

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 (readOnlyHint=true, openWorldHint=false), and the description adds real context on top: the mechanism is keyword rules rather than AI, output is deterministic per-line, and it is not legal advice. It could go slightly further (e.g. how partial/messy input is handled), but this is solid added value.

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 instruction to paste the text is front-loaded, followed by scope, output shape, and caveats in dense, low-waste sentences. The middle sentence is long but each clause carries distinct information, so nothing feels padded.

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 single-input tool with no output schema, the description covers input expectation, what gets flagged and why, the shape of the return (per-line flags with reasons, rewrites, a suggested list, a guest note), and its limitations. An agent has everything needed to call it and interpret results.

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% for the single `text` parameter, and the schema already states 'one task per line'. The description reinforces the input expectation ('Paste...') but adds no new format or syntax detail, 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?

The description names a specific verb and resource ('Paste Airbnb checkout instructions... Flags tasks that go past Airbnb's simple checkout asks') and enumerates the exact task categories it catches. It is instantly distinguishable from the unrelated sibling tools (claim_deadlines, price_match, vrbo_reprice).

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 usage context ('Paste Airbnb checkout instructions') and scope boundaries ('keyword rules, not AI', 'Not legal advice'), which tells the agent what the tool is for. There are no competing sibling tools to route against, so the absence of explicit when-not guidance is a minor gap rather than a real one.

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=true and openWorldHint=false, so safety is covered. The description adds real value beyond them: the governing rule windows, the Terms revision date (Feb 5, 2026) which signals rule versioning, the returned fields, and a 'Not legal advice' disclaimer. It does not contradict 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?

Two dense sentences with the trigger condition front-loaded, followed by outputs and a disclaimer. No filler or redundant restatement of the name.

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 payload and does so ('dates, days left, status, and an evidence checklist'). Combined with annotation-covered safety and 100% schema coverage, an agent has everything needed to invoke 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 description coverage is 100%, so tz, today, checkout, and reservation are already documented in the schema; the description only echoes the checkout-date input. No syntax, default, or interaction details are added, 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 domain action: computing Airbnb Host Damage Protection deadlines from a checkout date, with the concrete rule set (14-day guest payment, 30-day Airbnb filing). This is clearly distinguishable from siblings like checkout_check or lead_window, which concern checkout/lead mechanics rather than claim deadlines.

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 by the 'from a checkout date' framing and the explicit output list, but the description never states when to reach for this tool versus checkout_check or lead_window, nor any exclusions. Adequate but leaves routing 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful behavioral note that the returned text contains [BRACKETS] placeholders that must be filled before execution, but says nothing about unknown-id behavior or response shape.

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 short sentences, front-loaded with the action and resource, followed by the one operational caveat. 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 single-parameter read tool with no output schema, the description covers what is returned (full text), where the input comes from, and what to do with the result. Nothing an agent needs 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 id parameter already carries an example, so the baseline is 3. The description earns above baseline by stating where the id comes from ('from list_prompts'), provenance the schema does not supply.

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?

Specific verb plus resource plus scope: 'Get the full text of one host prompt by id.' The parenthetical '(from list_prompts)' immediately distinguishes it from the sibling list_prompts, so an agent can route 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?

It clearly implies the workflow (fetch an id from list_prompts, then retrieve its body) and adds an actionable next step: fill in the [BRACKETS] before running the prompt. It stops short of explicit when-not guidance or error handling for an invalid 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?

The annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful domain context (the 30-day default derives from industry reports of Vrbo's terms), but says nothing about what is actually returned or how missing optional inputs are handled.

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 compact sentence with no filler, and the key constraint (default 30 days) is included rather than buried. The fragment phrasing ('...and whether it is inside the window') is slightly loose but efficient.

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 three optional parameters and no output schema, the description carries the burden of explaining the return shape, yet it is ambiguous whether the result is the day count, the boolean verdict, or both. Adequate but leaves gaps for a tool whose entire purpose is a computed answer.

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 three parameters; baseline 3 applies. The description only restates the 30-day default for 'days' and adds no date-format, ordering, or interaction detail 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?

The description states a specific computed quantity (days from first Vrbo contact to a direct booking) plus a derived verdict (inside the 30-day window), so an agent can grasp the tool's output. It is clear but does not differentiate itself from the siblings airbnb_host_only, price_match, or vrbo_reprice.

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 statement of when to call this tool, what precondition triggers it, or which sibling to prefer instead. The agent must infer the use case entirely from the name and title.

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=true and openWorldHint=false, so the safety profile is covered. The description adds the useful facts that the result set is exactly 30 items and what fields each item carries, but says nothing about pagination, auth requirements, or ordering. With annotations doing the heavy lifting, this is adequate but not rich.

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, front-loaded with the core purpose and return shape. The trailing enumeration of the eight category values duplicates the schema enum, which is mild redundancy, but overall there is very 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 compensates by naming the returned fields (id, category, title, what it does, url), which is exactly what an agent needs. A read-only, single-optional-param list tool is nearly fully covered; only pagination/ordering details are 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 description coverage is 100% and the enum is fully defined in the schema, so the baseline is 3. The description merely repeats the same eight enum values verbatim, adding no new meaning such as matching behavior, case sensitivity, or how the filter combines with the fixed 30-item limit.

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 ('List the 30 copy-paste prompts for short-term rental hosts') and even enumerates the returned fields, so an agent immediately knows this is a bulk listing operation distinct from the singular get_prompt sibling. It stops short of explicitly naming get_prompt as the single-item alternative, so differentiation is implied 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?

The text marks category as 'Optional' and lists the valid values, which implies when filtering is useful, but it never states when to use this tool versus get_prompt or what happens when no category is supplied (presumably all 30). Usage is implied rather than spelled out.

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=true and openWorldHint=false, so the safety profile is covered. The description adds almost nothing beyond the title: it does not say the tool is a pure local calculation, does not mention that channel fees are applied via defaults, and gives no hint about the shape of the result. It essentially restates the title with three channel names.

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 compact sentence with zero filler, and the key qualifier ('same take-home per night') is front-loaded. It loses a point only because the fragmentary phrasing omits the action verb that would make it self-contained.

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 four parameters, the description carries the burden of explaining the return shape and the role of net as the target value, and it does neither. An agent cannot tell from the description whether it receives three prices, a single matched price, or a fee breakdown, nor that all parameters are optional with fee defaults.

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 four parameters (net, vrbo_rate, airbnb_rate, direct_rate) including their default values are already documented in the schema. The description adds no syntax, units, or interaction detail beyond what the 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 names the concrete concept: prices on Direct, Airbnb and Vrbo that all yield the same host take-home per night, which does differentiate it from vrbo_reprice and airbnb_host_only. However it is a noun phrase with no verb (compute/calculate) and never states that 'net' is the input driving the calculation, so the agent must infer that this is a solver, not a lookup or a listing. Purpose is implied 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?

There is no when-to-use guidance, no prerequisites, and no mention of the sibling tools (vrbo_reprice, airbnb_host_only, lead_window) that an agent must choose between. Nothing indicates the scenario that selects this tool over simply repricing one channel.

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 readOnlyHint=true and openWorldHint=false, correctly framing this as a safe local computation. The description adds useful context beyond that: the 12% flat fee mechanic, an effective date (Oct 29, 2026), and that rates are expressed as decimals. It does not describe what the returned structure contains or what happens when inputs are omitted.

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?

It is a single, front-loaded sentence with no filler, leading with the result (new prices) and the fee rationale. The trailing parenthetical date and the decimal note are compact and earn their place, though the sentence packs several distinct facts together.

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 six-parameter compute tool with zero required parameters and no output schema, the description should clarify expected inputs and results. It conveys the fee model and unit format but leaves the return shape and the behavior of omitted parameters 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?

Schema description coverage is 100%, so the schema already documents all six parameters, including the pass/absorb modes and the old_rate fee schedule. The description only echoes the covered fields and adds the decimal-unit convention, so the baseline 3 is 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 states a specific resource (Vrbo nightly, cleaning, and pet prices) and the transformation applied (grossing up to preserve host take-home after Vrbo's flat 12% fee). The 'Vrbo' scope also implicitly separates it from the Airbnb-oriented sibling airbnb_host_only. However, it is phrased as a noun phrase ('New ... prices') rather than an explicit verb, and it never names a sibling it is not.

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, when-not-to-use, or alternative-tool guidance. Usage is only implied by the intent clause 'keep host take-home the same after Vrbo's flat 12% fee,' and the pass/absorb choice is documented in the schema's mode parameter rather than the description.

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