Sauna Guide Quotes

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

Annotations already cover readOnly/idempotent/non-destructive/closed-world, so the bar is lower, and the description still adds genuine policy: omitted scope is treated as unclear and never assumed included, unpriced work makes the projected range incomplete, and the tool refuses fairness verdicts. These are real interpretive behaviors an agent could not infer. It stops short of saying what the response object actually contains.

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 tight sentences with the core action and privacy posture front-loaded; no filler. Phrasing is slightly telegraphic ('Report unpriced risks; the projected range is incomplete when unpriced work remains'), which costs a bit of readability but not space.

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 signal the return shape, and it does: a projected range plus questions to ask the seller plus flagged unpriced risks. The 25% schema coverage and undocumented productType/sizeClass keep it from being fully complete.

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 only 25% — just the nested scope object is documented. The description mentions 'total' and 'scope' but says nothing about productType or sizeClass, and given two bare enum params with no description, it does not fully compensate for the coverage gap.

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: checking a quoted total plus scope for missing costs, and produces questions for the seller. That is clearly distinct from estimate_sauna_total_cost or compare_sauna_brands, but the description never names those siblings, so the 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 by 'check a quote' (you must already have a quote) and bounded negatively by 'does not declare a seller fair or overpriced,' plus the no-upload note. But there is no explicit 'use this instead of estimate_sauna_total_cost when...' routing, which is the key ambiguity given six sibling tools in the same domain.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds material context beyond them: it enumerates what is returned (editorial fit, caveats, price scope and dates, warranty, recalls, sponsorship disclosures) and gives a domain caveat that brand ranges may be heater-only or portable rather than installed-sauna prices. This is exactly the kind of presentation constraint an agent could otherwise get wrong.

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 cardinality, then the return payload, then the slug source and the pricing caveat. No filler; the dense return enumeration is justified because 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?

With no output schema, the description must describe return values and does so explicitly, and with a single simple array parameter the input side needs little more. The added warning about heater/portable price scope closes the main remaining ambiguity for an agent summarizing 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 description coverage is 0%, so the burden falls on the description, which does compensate meaningfully: it specifies that slugs must be exact Sauna Guide slugs, constrains cardinality to two or three brands, and names the tools/directories that produce valid slugs. It does not restate the lowercase-hyphen pattern, but that is visible in 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 ('Compare two or three brands') plus the exact identifier type needed ('exact Sauna Guide slug'), which immediately separates it from find_sauna_brands (discovery) and estimate_sauna_total_cost (pricing math). The cardinality constraint (two or three) is stated up front.

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 the agent to find_sauna_brands or the brand directory for obtaining slugs, which is the key prerequisite. It does not, however, state when to prefer estimate_sauna_total_cost or check_sauna_quote instead, so no sibling exclusion beyond the slug source.

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, the description discloses output content (missing unpriced work and a data confidence signal) and sets expectations that the returned range is not a contractor quote, national average, or guarantee. It doesn't state pricing basis, region coverage limits, or what happens when a required boolean is unknown.

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 short front-loaded sentences with the capability first, then prerequisites, then caveats; nothing is padded. The final line about an "add-ons-only result" is cryptic in isolation and costs a little clarity for its brevity.

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 7 required parameters, the description covers the essentials: currency/region, benchmark source, output contents, and trust caveats. It still leaves the agent guessing how unknown site facts should be encoded and roughly how wide a returned confidence band can be.

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?

Only 1 of 7 parameters carries a schema description (14% coverage), so the schema does little work. The description partially compensates by framing all inputs as "site assumptions" that must be confirmed with the user before selection, but it adds no meaning for productType, sizeClass, permitRequired, panelUpgradeNeeded, foundationNeeded, or deliveryIncluded.

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 first sentence states a specific verb (estimate), resource (planning costs in USD), method (Sauna Guide price benchmarks and installation ranges) and geography (US). It is clearly a planning-range tool rather than a quote check or brand comparison, though it never names a 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?

"Explicit site assumptions are required; ask before choosing them" gives a concrete procedural directive, and the closing line rules out mislabeling an add-ons-only result as a total. What's missing is routing against the obvious alternatives (check_sauna_quote, prepare_sauna_quote_request) so the agent must infer the sequence.

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, and the description adds real context on top: a cap of three results, what each brand entry contains (cheapest qualifying model, seat label, dated price, source), explicit caveats that seat labels are the seller's and that electrical fit and delivery are unconfirmed, and the trust signal that sponsorship does not affect selection.

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 the action and inputs, then the result shape, then caveats — a sensible order with no filler. The middle sentence is long and packs several clauses together, which costs a little readability.

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 correctly spends words on what comes back (price sources, tradeoffs, checks still needed) and on what is explicitly not validated. It does not say what happens when nothing matches or whether results can be fewer than three, a minor 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 50% (heatType and placement enums are undocumented), and the description compensates by clarifying the budget as 'sauna-only USD' and by explaining the non-obvious semantics of `people` — that each brand surfaces its cheapest model rated for at least that many people. The enum values themselves are still unexplained, though they are largely self-evident.

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 concrete verb and resource ('Shortlist up to three sauna brands') plus the exact inputs used for selection, so the agent knows this is a filtered shortlist generator rather than a comparison or quoting tool. It never names compare_sauna_brands, so the boundary with that sibling is inferred from 'shortlist up to three' 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?

'No contact details required' clearly positions this as the early-research step before prepare_sauna_quote_request / submit_sauna_quote_request, and 'checks still needed' signals it is not a final quote. However, no sibling is named and no explicit 'use X instead when' routing is 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?

Annotations already provide readOnlyHint=true and destructiveHint=false, and the description adds concrete behavioral context: no data storage, no email sending, no provider selection, no contact sharing. This helps set expectations beyond the annotation flags, though it does not describe the validation output format.

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 two sentences with no wasted words. The core purpose is front-loaded, and the read-only clarification is concise and useful.

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 tool with 13 parameters, the description relies appropriately on the rich input schema and output schema. It communicates the essential selection information: validation, missing-detail identification, and no side effects. The only minor gap is not explicitly tying it to the submit workflow, but that is not critically 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 all 13 parameters are already documented in the schema. The description adds no parameter-specific meaning, but given the high schema coverage, the baseline score of 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 names a specific verb ('validate'), a specific resource ('a draft sauna project request'), and the intended outcome ('identify missing details'). It also clearly distinguishes itself from the submit sibling by stating it is read-only and does not send email or select a provider.

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 clearly frames this as a pre-submission validation step and explicitly lists what it does not do, which helps an agent avoid using it for final submission. However, it does not explicitly name submit_sauna_quote_request as the alternative or state 'use before submitting', so the routing guidance is slightly implicit.

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 structurally. The description adds the useful caveat that results are planning estimates rather than code/wiring approval, but says nothing about precision, rounding, or what the returned kW figure represents.

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 short sentences, front-loaded with the computation and then the unit convention and disclaimer. Every sentence contributes, though "Ask for actual measurements" is a directive that sits slightly awkwardly among descriptive content.

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 does state the output unit (kW) and the planning-estimate framing, which is enough to call the tool. It stops short of describing the shape of the result or any recommendation it may return, but nothing needed to invoke 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 0%, yet the description names essentially every input: room dimensions, glass area, wall insulation and supply voltage. It also adds meaning the schema cannot express — unit values map to meters/square meters versus feet/square feet — which is exactly the compensation needed at zero coverage. Minor gap: it doesn't explain the insulated vs uninsulatedOrLog distinction or the 208/240 V choice.

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 ("Estimate electric heater kW") plus the exact inputs it derives from, which immediately separates it from the sibling quote/cost/brand tools. An agent knows from the first sentence what this tool computes.

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 usage context ("Ask for actual measurements") and an explicit exclusion: it is a planning estimate, not approval of wiring, clearances or a particular heater. It does not name the sibling it hands off to for quoting or costing, so routing 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?

The description adds useful side-effect context beyond annotations: it stores a request, sends confirmation/internal emails, and explicitly excludes newsletter subscription and provider contact sharing. However, it does not elaborate on the destructiveHint=true annotation, such as whether the prepared request is consumed or whether submission is irreversible.

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 with no filler: function first, then the call conditions, then the privacy guarantees. Every sentence carries distinct useful 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?

For a 15-parameter tool with a full schema and output schema, the description covers the essential call sequence and consent requirement. The only notable gap is the meaning of destructiveHint=true, which is left to the annotation without explanation.

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 each parameter (including confirmRequest and requestId) is documented in the schema. The description adds no parameter-level detail, 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 a specific action ('Store a complete sauna project request') and its side effects ('send confirmation and internal notification emails'). It also situates the tool relative to its only sibling ('after prepare_sauna_quote_request'), so an agent can tell submit from prepare.

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?

Provides explicit preconditions: call only after prepare_sauna_quote_request and only after the user explicitly approves submission. This clearly tells an agent when the tool is appropriate and when it is premature.

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