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

With no annotations, the description carries the full burden and does so: it discloses the default detail level and what each level returns (summary returns a caveats list; full adds thresholds, all suggestions, assumptions), instructs the agent to quote `summary` as one self-contained paragraph, flags provenance limits ('third-party-compiled rules', 'Amazon's own measurement governs'), and explains how ambiguous unit inputs are interpreted and echoed back.

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-loads the value proposition and return content before the input contract, and the density is largely justified by 15 parameters at zero schema coverage. It is nonetheless a long block with some terse shorthand that an agent must parse carefully, so it stops short of ideal crispness.

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?

An output schema exists so return values need not be re-specified, yet the description still tells the agent which field to quote and how detail level changes the payload. Combined with the v0.1 class limitation, the fee-provenance caveat, and near-total parameter coverage, an agent has everything needed to call and interpret this tool.

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 description must compensate, and it does for nearly every parameter: dims accepts three formats with an example, weight accepts numbers or unit-suffixed strings with a default-units rule, and it documents dims_unit, weight_unit, dims_sigma, weight_sigma_oz, ship_date, margin_in, margin_pct, max_shrink_pct, min_dims, and detail (with default). Only include_fuel_surcharge and units_per_month are left unstated.

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 an explicit routing statement ('START HERE for "what FBA tier and fee is this product?"') and enumerates exactly what one call returns: size tier, dimensional/shipping weight, fulfillment fee, nearest limit with margin, risk class, and best shrink cut. It also names the sibling tools (fba_tier_headroom / fba_size_tier / fba_fee_estimate) and scopes them as detail-only alternatives, so the agent can distinguish it without opening any 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?

States when to use it ('START HERE'), when to prefer the alternatives ('Use fba_tier_headroom / fba_size_tier / fba_fee_estimate only when you need that detail'), and adds a scope limit ('Only product_class "standard" is modelled in v0.1'). This is explicit use/alternative/exclusion guidance.

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 burden well: it discloses verdict logic, that confidence is 'never high', that uncertainty softens 'likely' to 'possibly', that the verdict 'never claims Amazon is wrong', and the 90-day reimbursement window started by charge_date. It does not explicitly state the tool is read-only/non-mutating, but the 'audit aid' framing makes this inferable.

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?

Purpose and the 'not dispute evidence' caveat are front-loaded, then the naming/unit conventions, then the verdict behavior. It is dense and long, but 19 parameters with 0% schema coverage justify most of the length; a few clauses (e.g. the verdict wording rules) could be tightened.

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 complex 19-parameter analytical tool with no annotations, the description supplies the input conventions, the conditional-requirement rule, verdict semantics, and the 90-day window. An output schema exists, yet the description still previews the key return fields, making it fully sufficient to invoke and interpret.

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 description must do the work and it largely does: it defines dims, dims_unit, dims_sigma, weight, weight_unit, the amazon_* family, price, charge_date, ship_date, units_sold_since_charge, units_per_month, fee_includes_fuel_surcharge, and detail='full', including formats ('12 x 9 x 3 in', '1.4 lb', bare number = POUNDS) and defaults. Only weight_sigma_oz is left undocumented.

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 comparison action ('Compare what Amazon has on file/charged against your own measurement') and an explicit outcome ('say whether a remeasurement request looks worthwhile'). It also distinguishes itself from sibling fba tools by declaring it is 'a design-time and audit aid, NOT dispute evidence', so an agent can tell it apart from fba_draft_remeasure_request 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 clear usage context ('design-time and audit aid') and a when-not ('NOT dispute evidence'), plus the input condition that selects it ('Give at least one of: amazon_dims..., amazon_tier..., or amazon_fee'). It never names the alternative sibling tools to route to, so it stops short of full routing guidance.

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 and does so thoroughly: it discloses data provenance (third-party compiled sources), what 'verified' vs 'unverified' means, staleness thresholds (90 days / past review date), the 90-day reimbursement window, and a direct caution that rows are estimates. This is exactly the failure-mode context an agent needs before quoting fees.

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 and the call-site trigger, followed by parameter and return detail. Sentences earn their place, though the long parenthetical enumerations of return fields are dense and could be trimmed given an output schema exists.

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 status tool, the description covers purpose, timing, input semantics, provenance caveats, and confidence levels. It even enumerates return fields despite an output schema existing, so nothing an agent needs 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% and the schema gives no description for `date`, so the description must compensate. It specifies the format (ISO), the default (today), and the meaning ('the day to check'), plus what the date affects (peak vs non-peak fees). Minor gap: it does not clarify behavior if the date lies outside the effective range.

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+resource: reporting which FBA rules dataset is in force and how much to trust it. It is clearly distinguishable from sibling fee/size tools (fba_fee_estimate, fba_size_tier) because it positions itself as the trust/metadata check rather than a calculation.

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 an explicit trigger: 'Call this before quoting a fee, or when another fba tool's `caveats` point here.' That is a concrete when-to-use condition tied to sibling tools. There is no explicit when-not guidance or named alternative, so it falls short of a 5.

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 so: it discloses the letter's stance (seller-provided hand measurements, no claim that a scan proves anything), the [ADD: ...] placeholders that must be replaced, the warnings that may be returned, and the 'Amazon's own measurement governs' caveat. This is unusually rich behavioral context for a mutation-adjacent drafting tool.

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 and required inputs, then behavior, then returns. Dense and mostly waste-free, though a few sentences are long and the middle paragraph could be split for faster scanning.

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?

Despite an output schema, the description still names the key return fields (subject, body, checklist, warnings, channel, deadline) and states submitted is always false. For a 10-param tool with a prerequisite dependency, 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 0% across 10 params, but the description explains audit, asin/sku/fnsku, seller_name, amazon_dims_text/measured_dims_text (with the format example '18.5 x 12 x 3 in'), measurement_method, and the tone values. Only request_reimbursement is left implicit, so the coverage gap is nearly closed.

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+resource with scope: 'Draft (never send) a Seller Support remeasurement request.' It also names fba_audit_listing as the source of the audit dict, so an agent can place it precisely relative to siblings like fba_audit_listing and fba_measure_package.

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 a clear entry condition (pass the dict returned by fba_audit_listing as audit) and a hard constraint (never send; submitted is always false). It stops short of explicitly contrasting alternatives such as fba_tier_headroom or fba_fee_estimate, so it is strong context rather than full routing guidance.

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 so richly: it discloses the peak-table window (2026-10-15 to 2027-01-14), the 3.5% fuel/logistics surcharge from 2026-04-17 and how to disable it, the error for unsupported product_class values, and the fee_available=false fallback when a fee row is missing. It also flags calibration risk (unverified third-party rates, compare with Fee Preview) and what is deliberately excluded.

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?

Purpose is front-loaded, then inputs are grouped, then returns, then provenance caveats — a sensible progression for a complex computational tool. It is dense but every paragraph corresponds to a real schema/behavioral need; nothing is padding, though the returns paragraph is long.

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?

An output schema exists, so the description need not fully explain return values, yet it still usefully summarizes them plus the fee_available fallback and detail modes. Combined with the thorough input and provenance coverage, the only real omission is the undocumented sipp_enrolled parameter.

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?

With 0% schema description coverage, the description does the heavy lifting, documenting acceptable forms and defaults for dims/dims_unit, weight/weight_unit (bare number = pounds), price and its fee bands, ship_date, include_fuel_surcharge, dims_sigma, weight_sigma_oz, units_per_month, product_class, and detail. One parameter, sipp_enrolled, is never mentioned, leaving a real gap for a 13-param tool.

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 the US Amazon FBA per-unit fulfillment fee in USD for a packaged unit'), including currency and scope, so the agent knows exactly what is produced. It does not, however, name or distinguish itself from siblings like fba_size_tier or fba_analyze, so routing still requires inference from the sibling list.

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 implies usage through the input narrative (fill dims/weight/price, set ship_date to pick peak vs non-peak, include_fuel_surcharge=false to exclude the surcharge) and states the product_class='standard' restriction. But it never says when to choose this tool over fba_size_tier, fba_analyze, or fba_tier_headroom, which is the main guidance gap.

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 so richly: it states reliability ceilings ('LiDAR is never reported better than 0.2 in'), a hard limitation ('items thinner than 1.5 in cannot be certified'), confidence rules for relative/monocular/assumed-intrinsics depth, that a scan cannot weigh, and that Amazon's own measurement governs. These are exactly the traits an agent needs before calling.

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 long and dense, but front-loaded with the purpose first and then explicitly partitioned into 'Inputs' and 'Returns' plus a closing caveat, so an agent can navigate it. Given 13 parameters at 0% schema coverage and zero annotations, the length is largely earned 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?

For a 13-parameter tool with an output schema and no annotations, the definition covers input formats, unit detection, filtering, the return payload, and confidence/limitation semantics. Nothing an agent needs in order to call it correctly is missing, and the return summary adds interpretive value beyond the schema.

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% across 13 parameters, yet the description supplies deep semantics for nearly all of them: file/unit/up-axis detection and override aliases ('Scaniverse writes METERS, units="cm" works as an alias'), weight formats and default units, pixel-space rules for bbox/point, the reference schema, and detail="full" behavior. Only the 'units' output-formatting parameter goes unmentioned.

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 sentence gives a specific verb and a sharply scoped resource: 'Measure the PACKAGED unit (the box or bag as it ships) from 1 to 5 scans of the same package.' The parenthetical and the multi-scan framing distinguish it from generic siblings such as measure_object and kitchen_measure_vessel without the agent 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?

The description gives strong in-scope guidance (1 scan via path vs 2-5 same-pack scans via paths, when to override scan_units/up_axis, when reference is needed) and cross-references measure_list_reference_objects. It stops short of naming when to prefer this over measure_object/kitchen_measure_vessel, so the when-not case is left 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?

With no annotations, the description carries the behavioral load and does so well: it discloses the dimensional-weight divisor (139), the 2-inch floor, shipping-weight banding rules, risk classes, and that the result is an estimate from third-party rules where 'Amazon's own measurement governs.' Some of the 'Returns...' enumeration overlaps with the output schema rather than adding behavior, keeping it at 4.

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 dense but front-loads the purpose and separates 'Inputs:' and 'Returns:' cleanly. The long Returns sentence partially restates the available output schema, which is the main source of avoidable length given a 9-parameter tool that genuinely needs input detail.

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 9-parameter, 0%-coverage tool with an output schema, the definition covers all inputs with format rules, states the estimate/disclaimer caveat, and explains detail-dependent return content. Nothing an agent needs to call it correctly appears to be 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 0% across 9 parameters, so the description must compensate and it does: dims formats, dims_unit default/cm/mm, weight formats and the pounds-unless-unit-given rule, weight_sigma_oz, as_of dataset selection, detail modes, and that only product_class "standard" is modelled. Every parameter is given meaning beyond the bare 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 ('Classify a packaged unit into its US Amazon FBA size tier') and names the tier bands. It also names the sibling fba_analyze and clarifies the division of labor, so an agent can distinguish it from the other FBA tools without opening 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?

The parenthetical pointing to fba_analyze for 'the usual question, tier plus fee plus nearest limit' implies when to prefer this tool (tier-only). It also gives a clear usage condition for dims_sigma ('omit for exact tape/caliper values'). No explicit when-not statement or prerequisites, so it falls just short of 5.

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 so richly: it defines 'risky' vs 'critical' bands, the dimensional-weight crossover rule, default margins and shrink caps, the peak/non-peak fee dependency, and the crucial caveat 'Estimate only; Amazon measures the packed unit itself and its measurement governs.'

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 purpose sentence and organized into 'Inputs:' and 'Returns:' blocks, which makes a long body navigable. The Inputs paragraph is an unusually dense run-on that could be broken up, but given 15 parameters the length is largely justified.

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?

Despite an output schema existing, the description still summarizes return fields, and it compensates for absent annotations and 0% schema coverage with defaults, semantics and an estimation caveat. For a complex 15-parameter tool, nothing essential for correct invocation 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 description coverage is 0% across 15 parameters, so the description must compensate and largely does: it gives accepted formats and unit semantics for dims, weight, price, dims_sigma, weight_sigma_oz, margin_in, margin_pct, max_shrink_pct, min_dims, ship_date, units_per_month and detail, including the 'bare number is POUNDS unless weight_unit says otherwise' rule.

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 (show headroom to FBA tier/weight/fee-band thresholds) plus the actionable outcome (what to shrink to pay less). It explicitly contrasts itself with fba_analyze as the 'one-call version with the single best suggestion', so an agent can tell the two apart without opening 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?

Names the closest alternative (fba_analyze) and implies the selection condition (full threshold picture vs. single best suggestion), and points to fba_measure_package for the sigma value. However it never addresses fba_size_tier or fba_fee_estimate directly, and gives no explicit when-not-to-use guidance.

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?

No annotations are provided, so the description carries the full burden and does so unusually well: it discloses supported input families, that units/up-axis are auto-detected and where the result is reported, that capacity is BRIMFUL measured to the inner surface, the confidence grading rules (never 'high' for relative/monocular/guessed intrinsics), and explicit error codes (NO_DEPTH, VESSEL_FIT_POOR).

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?

Every fact is relevant, but the description is a dense wall of run-on sentences with embedded parentheticals and backticks that is hard to scan. Several sentences enumerate return fields (summary, vessel, measurements, capacity, fill_guidance, nearest_preset, quality, warnings) that an output schema already conveys, so some length is not earning 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 12-parameter tool spanning several capture formats, this covers everything an agent needs to attempt a correct call: required capture geometry, format support, disambiguation of the vessel among several, unit/axis overrides, fallback behavior, and how to interpret the estimate. The output schema handles return structure, so the description's completeness is more than sufficient.

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 description must compensate and largely does: path formats, rgb_path (EXIF focal length), bbox/point pixel coordinate spaces (photo vs depth-map), vessel_type and material enums, wall_thickness_mm's effect on the allowance, reference's credit-card corner structure with a cross-reference to measure_list_reference_objects, scan_units (file units, Scaniverse=meters) and up_axis signs. Only depth_source goes unexplained.

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 statement: capacity of a named set of vessels (bowl, baking dish, cake pan, sheet pan, pot) from one depth capture or 3D scan, with the motivation (scaling a recipe). It is clearly distinguishable from kitchen_vessel_from_dimensions (typed dimensions) and kitchen_scale_recipe (downstream consumer), which it names.

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 capture preconditions (camera 45 degrees or steeper, whole rim in frame, vessel upright on a table) and explicitly routes around the failure path: a plain photo returns NO_DEPTH with an ordered hint list, and typed dimensions via kitchen_vessel_from_dimensions 'always work'. It even names measure_depth_info as the way to check installed capabilities.

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 and does so well: unnumbered lines stay unscaled and surface in warnings, eggs scale to whole/half/measured, factors outside 0.5-2.0 and Bundt/angel-food/cheesecake pans trigger warnings, and fill height/bake notes are explicitly flagged as guidance rather than measurements.

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 goal is front-loaded in the first sentence and every sentence carries information, but the parameter documentation is packed into a single dense block without visual separation, which slightly hurts scannability. No filler content is present.

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 10-parameter tool with 0% schema coverage and no annotations, the description is complete: it covers inputs, defaults, inference rules, warnings, and even summarizes the return payload despite an output schema existing. 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 0%, so the description must define all 10 parameters, and it effectively does: input formats for ingredients, accepted vessel forms, the recipe_kind vocabulary, mode semantics, fill_fraction range (0.05-1.0), rounding steps, detail levels, and the purpose of the original bake/temp 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 opening sentence gives a specific verb and resource: 'Scale a recipe written for one pan to another vessel, with kitchen-friendly amounts.' It is clearly distinguishable from siblings like kitchen_measure_vessel and kitchen_vessel_from_dimensions, which it explicitly identifies as sources of vessel objects rather than scaling tools.

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 names alternatives for obtaining vessel objects (kitchen_measure_vessel, kitchen_vessel_from_dimensions) and lays out conditions that select behavior: mode auto uses AREA unless the target is shallower or the recipe is a soup (then VOLUME), recipe_kind is inferred when omitted else defaults to batter_heavy, and vessels_resolved should be checked with the user. Guidance on when each option applies is explicit.

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 so richly: measurements are INSIDE rim-to-floor, outside sizes require wall_thickness, slant needs bottom_* bounded by the rim, unknown names return candidates, and it states the preset resolution fields (resolved_to, match exact|alias|parsed|default|fuzzy) plus warnings. It also identifies the downstream consumer (kitchen_scale_recipe).

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 core purpose and the either/or rule before the detail; the length is justified by 15 undocumented parameters. Some phrasing is instructional filler ('tell the user', 'quote it'), but overall every line carries usable semantics.

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 zero-annotation, 15-param, 0%-schema-coverage tool, this covers input modes, units, geometry conventions and the returned fields. Since an output schema exists, the return list is a bonus rather than a necessity, making the definition complete enough to invoke 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 0% across 15 params, so the description must compensate and largely does: it documents dims string/array/dict forms with ordering, named fields (diameter, length, width + depth), dims_unit values, bottom_*/tube_diameter/wall_thickness/corner_radius, and profile cylinder|frustum|cap semantics. Only 'shape' goes unmentioned, which is a minor 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 — 'Build a vessel and its capacity' — plus the two input modes ('a standard pan name or typed dimensions'). The phrase 'no photo, always works' implicitly separates it from a photo-based sibling like kitchen_measure_vessel, so an agent can route 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 states the input-mode rule: 'Pass EITHER preset OR dimensions (both is an error)', and gives abundant concrete preset and dims examples so the agent knows what to supply. It stops short of naming the photo-based alternative it contrasts against, so the routing is implied ('no photo') 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?

With no annotations, the description carries the burden and does so well: it discloses supported input formats and, crucially, the semantics of accuracy='relative' (needs a reference object) and intrinsics_origin='assumed' (FOV is a guess, sizes capped at low confidence with wide +/-). This is genuine behavioral context. It does not cover permissions or rate limits, but those are not relevant to a local file inspection tool.

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 purpose is front-loaded in the first sentence, with format details and field semantics following. It is dense but every clause adds information; the only mild redundancy is restating the output fields that the output schema already carries.

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?

An output schema exists (so return values needn't be spelled out) yet the description still enumerates the returned fields and explains the ambiguous ones, which makes it complete for an agent deciding whether to trust the file before measuring. The duplicated field listing is the only minor inefficiency.

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% and the single 'path' param is undocumented in the schema, so the description must compensate. It does so by listing exactly what path accepts (HEIC/HEIF, TIFF, 16-bit PNG, NPZ, JPEG, or a capture-app bundle passed as a folder or .zip), which is the key ambiguity for this 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?

The description opens with a specific verb and resource: 'Check what a photo or depth file contains BEFORE measuring from it.' It clearly distinguishes itself from the measure_* siblings as a pre-flight inspection step, and it enumerates supported formats (HEIC/HEIF, TIFF, 16-bit PNG, NPZ, JPEG, capture-app bundle).

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?

'BEFORE measuring from it' gives explicit timing guidance that places this tool upstream of the measurement tools, and 'A file with no depth is a plain photo: see advice for the options' tells the agent how to proceed in the degenerate case. It stops short of naming specific sibling tools to switch to, so it is context-rich but not fully explicit about alternatives.

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 and does so well: it discloses the return shape (summary, confidence, measurements, warnings), an accuracy caveat (depth file without intrinsics capped at low with wide +/-), a failure mode (glass/mirror/black surfaces yield NO_DEPTH_AT_POINT), and a precision floor (points under 3 cm are within noise). Only auth/rate-limit style context is absent, which is largely irrelevant for a read-only measurement.

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 purpose statement followed by compact parameter notes and then return/edge-case behavior. Dense but every clause carries distinct, useful information; no filler sentences.

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 tool with no annotations and 0% schema coverage, the description covers inputs, coordinate semantics, formats, failure modes, accuracy caveats, and return hints. An output schema exists so return values need not be elaborated, yet the brief mention is a bonus rather than a 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 description coverage is 0%, so the description must compensate and it does: it documents all six parameters, including accepted path formats (LiDAR/Portrait HEIC, bundle, TIFF, 16-bit PNG mm, NPZ), that point_a/point_b are [x, y] in photo pixels, that rgb_path supplies EXIF focal length, and that units accepts metric|imperial|both.

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+resource ('Straight-line distance between two pixels of a depth capture') and even grounds it with examples ('a doorway width, a shelf gap'). The scope is unambiguous, but no sibling tool is named to differentiate it from measure_object or room_check_doorway.

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 through the input context ('depth-map pixels when there is no photo', 'with a plain photo the two points must lie on the reference's surface') and it routes the reference parameter to measure_list_reference_objects. However, it never explicitly states when to choose this tool over alternatives like measure_object, so guidance remains inferential rather than directive.

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 and largely meets it: it discloses the default search directories, that folder lookup is direct children with no recursion, the limit range, and the recognized file formats plus returned depth metadata. It does not explicitly confirm read-only/non-mutating status or mention any failure modes, leaving a small gap for an annotation-free tool.

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?

Purpose is front-loaded, followed by the usage scenario, parameter notes, formats, and return fields — a logical progression. It is dense but each line earns its place; the final return-value sentence slightly overlaps the existing output schema, and the paragraph flow is a touch unconventional, keeping it at 4 rather than 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?

For a two-parameter, zero-required discovery tool with an output schema, the description is fully sufficient: it covers what it finds, where it searches, how to use it when no path exists, parameter behavior, and recognized formats. 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 0%, so the description must compensate — and it does fully. It explains folder semantics ('look only there, direct children, no recursion') with concrete defaults, and limit semantics ('1-100, default 20'), covering both parameters beyond what the bare schema 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?

States a specific verb and resource clearly: 'List recent measurable files on this computer, newest first, with what each contains.' An agent immediately knows this is a file-discovery tool. It does not, however, name or contrast itself against discovery-adjacent siblings like measure_open_capture or measure_depth_info, so it lands at 4 rather than 5.

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 an explicit, concrete usage scenario: when the user references 'this photo' or 'the scan I just took' with no file path, ask them to save to ~/measure-mcp-inbox or AirDrop to Downloads, then call this tool. This tells the agent both when to invoke it and what preparatory step to take, which is unusually actionable guidance.

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 behavioral burden and does disclose non-obvious traits: the disc vs. card corner convention ('discs: bbox'), the clockwise-from-top-left ordering, and the downstream effects on depth, field of view, and footprint measurement. It is a read-only listing call with no parameters, so little risk remains undisclosed.

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; the enumerated keys are front-loaded so an agent immediately learns what the tool returns. The middle sentence is dense with inline JSON and a parenthetical, which slightly slows parsing but every clause 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?

For a zero-parameter listing tool with an output schema and full schema description coverage, the description covers everything an agent needs: what the list contains, where the physical object must be placed, and why the reference is required. Return-value details are correctly left to the output schema.

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?

This tool takes zero parameters, so the baseline is 4. The description goes further by documenting the shape of the `reference` argument the returned keys feed into (type plus four pixel corners, or bbox for discs), which is genuinely useful context even though it technically belongs to a sibling tool's 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 ('List everyday objects of known size') and enumerates the exact keys returned (credit_card, us_quarter, us_letter, a4, half_sheet_pan, dollar_bill). The purpose — supplying a metric scale reference for measurement tools — is unambiguous and clearly distinct from siblings like measure_object or measure_depth_info.

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 states when the returned reference matters ('Needed for relative depth; it also fixes a guessed field of view, and measures a flat object's footprint in a plain photo') and gives the physical precondition ('lay it flat on the same surface ... fully visible'). It does not name alternative sibling tools or when a reference is unnecessary, so it falls short of a full 5.

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 and does so: it reports where units/up-axis detection results land (scan block), how confidence is computed (worst of the edges, same rule as fba_measure_package), the grading rules (never 'high' for relative/monocular depth or missing intrinsics), and a hard reliability floor (under 1.5 cm is unreliable). It also warns that the scan 'nearest the middle' is selected and that rgb_path/bbox/point/reference do not apply to scans.

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-loads the one-line purpose, then flows into dense, mostly run-on prose. Given eight undocumented params the length is justified, but there is no bulleted structure to scan and the closing summary of return fields partly duplicates the existing 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?

Covers the acceptance surface (file types), unit/axis overrides, coordinate frames for bbox/point, the reference-based rescaling path, accuracy caveats, and the flat-object fallback — everything needed to call it correctly. Return-value detail is redundant given the output schema but is accurate.

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%, so the description must document all 8 params and largely does: scan_units (m|cm|mm|in with the units alias), up_axis (x|y|z, signs allowed), rgb_path (EXIF focal length; pixels are the bbox/point coordinate frame), bbox/point formats and pixel basis, units (metric|imperial|both), and reference (type credit_card with 4 corners). This meaning is entirely absent from 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 ('Size (length, width, height) of one object standing on a flat surface') plus the input domain (depth capture or 3D scan). It actively distinguishes itself from siblings, explicitly routing vessel-capacity questions to kitchen_measure_vessel and reference setup to measure_list_reference_objects.

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 when/when-not guidance across every branch: which file formats qualify (LiDAR/HEIC, bundle, TIFF/16-bit PNG/NPZ, Scaniverse/Polycam/3D Scanner App OBJ/PLY), when to override scan_units/up_axis, when rgb_path/bbox/point/reference apply, and the flat-photo fallback with a rectangular reference. It names alternatives for adjacent needs.

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?

No annotations, so the description carries the full load. It discloses the return fields (summary, depth_size, source=lidar, accuracy, valid_fraction, depth_range_m, intrinsics), which tells the agent what the operation yields. However it omits mutation/read-only framing, error behavior for an invalid path, and any permission or size constraints, leaving real 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?

Two sentences, front-loaded with the core action and file inventory, then the pipeline instruction. The field list is dense but each item is informative; nothing reads as 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?

An output schema exists, so detailed return-value documentation is technically not required, yet the description still front-loads the key outputs. Combined with the downstream-tool instruction, an agent has enough to call this correctly as the pipeline opener.

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% and there is one param, but the description adds meaning beyond the bare 'path' string: the bundle may be 'a folder or .zip' and the same path is reused by downstream measurement tools. That clarifies accepted input forms and lifecycle usage, which the schema does not.

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+resource: 'Describe a capture bundle from the measure-mcp iOS app (a folder or .zip)', and enumerates the bundle contents (depth.tiff, confidence, colour image, capture.json). It doesn't explicitly differentiate itself from siblings like measure_depth_info or measure_find_files, but the workflow framing implies it's the entry-point tool.

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 contextual routing: 'Pass the same path to kitchen_measure_vessel, measure_object, measure_distance_between_points to measure.' This positions it as the first step of a measurement pipeline. No explicit when-not-to-use or comparison against measure_depth_info/measure_find_files, so it stops short of a 5.

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?

No annotations are present, so the description carries the full burden, and it discloses notable behavioral traits: accepted query variants (aliases, plurals, typos, size hints), what each match contains (value, cross-sheet range, alternatives, 7 lb/cu ft weighted value, re-verification status), and an explicit exclusion ('never includes prices'). It stops short of covering performance, limits, or confirmation behavior, but for a read-style lookup this is solid.

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?

Well front-loaded: purpose first, then usage triggers, then accepted input, then output shape, ending on a terse exclusion. Every sentence adds information, though it runs a little long and could tighten the output enumeration now that an output schema exists.

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 lookup tool with an output schema present, the description needn't restate return values yet does so usefully, and it covers purpose, usage, and input flexibility. The main gap is undocumented non-query parameters, which no other structured field fills.

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% across 4 parameters, so the description must compensate. It does so thoroughly for the required 'query' parameter, explaining accepted input forms, but leaves 'room', 'limit', and 'units' (which has an enum) completely undocumented in both schema and description.

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 precise verb and resource: 'look up how many cubic feet (and pounds) the movers' cube sheet assigns to an item'. The scope (cube-sheet reference values, not estimates) is clear enough to separate it from the moving_estimate_* siblings. An agent can tell this is a catalog lookup, not a computation.

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 two concrete usage contexts ('why 50 cu ft for my sofa?' and 'find the right catalog name before building an inventory'), which is richer than generic context. However it names no explicit alternative or when-not-to-use condition relative to the many moving_* siblings, so it stops short of a 5.

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 it does disclose the substance of the response (versions, dates, URLs, verified/unverified counts, staleness warnings) plus the set of files covered. It says nothing about authentication, refresh cadence, or failure behavior, so it is informative but not complete for a no-annotation tool.

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 enumerations are dense but each item is substantive output detail 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?

For a zero-parameter read-only reporting tool with an output schema present, the description covers what the tool is about and what it returns; return-value specifics are legitimately left to the output schema. Only the when-to-use dimension is thin.

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 per the rubric the baseline is 4; there is no parameter surface that the description could clarify or neglect.

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 pairs a specific verb ('Report') with a clearly scoped resource ('the moving data files') and enumerates the exact fields reported (versions, as-of dates, source URLs, row counts, staleness warnings). This implicitly distinguishes it from the FBA/measure/room siblings by domain, but it never names an alternative the way a top-tier definition would.

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 versus alternatives such as moving_cube_sheet_lookup or the estimate tools; the data-provenance use case is only inferable from the field list. No prerequisites or exclusions 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 available, the description carries the full burden and does real work: it discloses that unmatched items land in 'unresolved' and are excluded from the total, and that assumed sizes surface in 'needs_review' with an instruction to ask the user. That is exactly the kind of behavioral disclosure that prevents a silently wrong estimate. It does not describe determinism or stability of the estimate, and the unresolved/needs_review guarantees are the only failure modes covered.

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?

Roughly four sentences, front-loaded with the outcome (volume and weight), then input format, then edge-case behavior. The parenthetical examples ('3x', 'two', 'a dozen', 'Bedroom:') are dense but each one illustrates a distinct parsing capability 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?

The output schema covers return values, so the unresolved/needs_review mention is bonus context rather than a required gap-fill, and a pure estimator needs no auth or rate-limit disclosure. The remaining gap is the four undescribed input parameters — for a six-parameter tool with 0% schema coverage, an agent cannot confidently set units, detail, or include_recommendations from this description alone.

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% across six parameters, so the description must compensate, and it only covers two of them: inventory_text (accepted as one block or a list of lines, with quantity/plural/typo/'Bedroom:' header handling spelled out) and items (structured alternative). units, detail, default_room, and include_recommendations — two of which are enums with non-obvious behavioral consequences — receive no explanation at all.

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 with concrete output metrics: 'Estimate the volume (cu ft / m3) and weight of a move from a list of belongings.' The 'from a list of belongings' framing implicitly separates it from moving_estimate_from_scan and moving_estimate_object, but no sibling is named outright, so an agent must infer the boundary rather than read it.

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 tells the agent what to supply ('Give inventory_text ... and/or structured items') and gives one operating instruction ('ask the user about them rather than hiding them'), which implies the right context. It never states when to prefer this tool over the sibling estimators or what input shape rules out the alternatives, so usage is only implied.

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 meets it: it discloses mapping behavior (furniture to cube-sheet sizes), fixture exclusion semantics, the `coverage_warning`/`needs_review` signals, and the critical failure mode that a raw point cloud yields `no_furniture_recognised` rather than a number. These are behavioral traits no structured field conveys.

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 purpose is front-loaded and every sentence carries operational content, with caps used to flag the IMPORTANT caveat. It is dense but not padded; a mild readability hit from packing the middle into one long block.

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?

An output schema exists, so return values need not be spelled out, yet the description still names key response fields and edge-case outcomes. Combined with input guidance and failure-mode coverage, it is nearly complete for a 10-parameter tool, with only several parameter meanings left unstated.

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 description must compensate. It clarifies `path` vs `paths`, the `fixture_policy="include_all"` value, and that `extra_items` uses the same format as moving_estimate_from_inventory, but leaves `units`, `detail`, `room_names`, `size_method`, and `include_recommendations` unexplained across 10 parameters.

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 and resource ('Estimate a move from a RoomPlan room scan') and names the accepted input formats. This clearly separates it from inventory-based siblings such as moving_estimate_from_inventory without needing to open 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 gives concrete routing guidance: use `path` for one merged scan vs `paths` for one file per room, and points to `extra_items`/`contents_allowance` as fallbacks when small items are missing. However it stops short of an explicit 'use moving_estimate_from_inventory instead when...' rule, leaving the sibling choice partly 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?

With no annotations, the description carries the full burden and delivers substantial behavioral context: the 0.75 bounding-box fill factor, the resulting low-to-medium confidence, auto-detection/reporting of scan units and up axis, supported formats (Scaniverse/Polycam/3D Scanner App OBJ/PLY, zipped OBJ+MTL), and how the target object is picked ('nearest the middle of the scan'). It omits any error/precedence behavior when both dims and path are supplied.

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-loads the purpose, then walks input formats, unit handling, fill-factor math and return plumbing with no filler sentences. It is dense prose without formatting for a 9-param tool, but nearly every clause carries information the 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?

An output schema exists so return values need not be spelled out, and the description still summarizes them usefully. For a 9-parameter, 0%-coverage tool with three near-name siblings, though, the gaps around name/room/units/reference and the missing explicit sibling routing leave the agent under-informed for edge cases.

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% across 9 params, so the description must compensate; it does well for the hard ones (dims accepted shapes and 10 m edge limit, path formats, scan_units semantics, up_axis signs). However it says nothing about name (the sole required param), room, units, or reference, so about half the parameters remain opaque.

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+resource+scope: 'Volume of one oddly shaped object from measured size'. An agent can tell this is the single-object estimator versus the bulk siblings moving_estimate_from_inventory and moving_estimate_from_scan. Sibling differentiation is only implied through the input description, not stated outright.

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?

Describes the input pathways (dims, depth-capture path, or 3D scan export) and where the result flows next (inventory_item for moving_estimate_from_inventory/from_scan). It never states when to prefer this tool over the two moving-estimate siblings or when it is inappropriate, leaving selection 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?

With no annotations, the description carries the full burden and does so richly: it explains that html carries print CSS, markdown/csv/json return inline when small, files only land in MEASURE_MCP_OUTPUT_DIR, output_name cannot contain folders and never overwrites, the result's ``path`` records the location, and the output includes a "Not counted" section plus a not-a-quote disclaimer.

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?

Purpose is front-loaded in the first sentence and every subsequent sentence adds operational detail rather than filler. The dense backtick-laden middle is information-rich, though it could be trimmed slightly.

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 7-param export tool with an output schema, the description covers the important behavioral surface (formats, file handling, non-overwrite, output path, caveats). The remaining gap is undocumented behavior for group_by, title, and include_weights.

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?

With 0% schema coverage the description must compensate, and it explains estimate_id, the estimate dict, the four format behaviors, and the output_name constraints (plain file name, extension follows format). It leaves title, group_by, and include_weights entirely undocumented, so coverage is substantial but incomplete.

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: turns an estimate into a printable/shareable inventory list. The direction (estimate -> inventory list) inherently distinguishes it from the sibling moving_estimate_from_inventory, so an agent can tell the two apart 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?

Provides clear context on how to feed the tool: pass ``estimate_id`` from moving_estimate_* or the full dict from detail='full'. However it never states when NOT to use this tool or explicitly contrasts it with moving_estimate_from_inventory, so guidance stops short of explicit alternatives.

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 burden and does so well: it explains hard weight limits for dense loads, the weight_binding flag semantics, the returned plan shape, and a data-provenance caveat (PODS capacities unverified, confirm with provider) plus 'No prices'. Only lacks finer caveats like error/edge behavior.

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-loads purpose, then adds behavior and caveats in tight sentences with a concrete return example. Slightly dense but every sentence adds information; nothing is redundant.

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?

An output schema exists, so return values needn't be explained (it explains them anyway). But for a 10-parameter tool with no annotations and 0% schema coverage, the description leaves the input contract substantially undocumented, deferring to a sibling.

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% across 10 parameters, and the description documents none of them directly, deferring entirely to 'Input as in moving_recommend_truck'. The weight/volume phrasing hints at some fields but leaves parameters like estimate, estimate_id, efficiency, box_fraction, and families unexplained.

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 ('Pick') plus concrete resource ('portable moving containers (PODS 8/12/16 ft, U-Haul U-Box)') for a load, scoped by volume AND weight. It is clearly distinguishable from siblings like moving_recommend_truck and moving_recommend_storage without opening any 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?

Frames the context (choosing containers for a load, with a weight-binding caveat) and points to 'Input as in moving_recommend_truck', but never states explicitly when to choose this over the truck/storage recommenders. 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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: the sizing algorithm (floor area × ceiling height), the 0.65-0.80 usable fraction with the aisle adjustment, and that it additionally reports the next smaller unit and two-unit combinations. It does not mention permissions or error conditions, but for a computation-only tool those are minor.

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 core action and sized reasonably for the amount of computational context needed. The volume/usable-space sentence is dense but 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?

An output schema exists, so return values needn't be detailed, and the description usefully previews the smaller-unit and two-unit outputs. However, for a 7-parameter tool with 0% schema coverage and no annotations, deferring most parameter meaning to moving_recommend_truck leaves the definition under-complete on its own.

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% across 7 parameters, so the description must compensate and only partly does. It explains ceiling_ft (8 ft typical) and efficiency (0.65-0.80), but leaves units, estimate, estimate_id, volume_cuft, and box_fraction entirely unexplained, defaulting to 'Input as in moving_recommend_truck' which gives no local meaning.

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: pick a self-storage unit size (5x5 up to 10x30) for a load. An agent can distinguish it from siblings like moving_recommend_truck or moving_recommend_container. It doesn't explicitly say why you'd choose storage over truck/container, but the resource is unambiguous.

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. 'Input as in moving_recommend_truck' points to an input-format reference in a sibling, but that is not a usage condition. No prerequisites or alternative routing 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 well: it discloses the packing-efficiency model (0.70-0.85, override via efficiency), that U-Haul payloads are unpublished so weight is not checked and a known_payload_alternative is offered, that capacities are approximations, and that no prices are returned. It stops short of stating read-only/non-mutating behavior explicitly, but the operation is clearly a computation.

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-loads the core purpose in the first sentence, then layers constraints and special cases. Dense but every clause (input modes, efficiency, U-Haul caveat, deprecated alias, no prices) adds real 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?

Returns are covered by the output schema, and the description still flags noteworthy output behavior (size_range, known_payload_alternative, 'payload not published' summary). Mutually exclusive inputs and unit ambiguity via schema are addressed; only the undocumented units/providers/weight_unit parameters 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 coverage is 0% across 10 parameters, so the description must compensate. It explains estimate_id, estimate, volume_cuft, weight, box_fraction, efficiency, and the weight_lb alias, but leaves units, weight_unit, and providers undocumented in either place. Useful but incomplete against 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 ('Pick the smallest rental truck or van for a load, by volume AND payload') and names the providers considered. It is clearly distinguishable from siblings like moving_recommend_container or moving_recommend_storage.

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 states the accepted input modes ('Pass estimate_id (or the dict) from moving_estimate_*, or bare volume_cuft / weight / box_fraction') and the mutual exclusion ('not both an estimate and volume_cuft'), which routes the agent correctly. It does not, however, say when to choose this tool over moving_recommend_container, leaving sibling selection 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?

With no annotations the description carries the full burden and does so richly: it names the NOT_A_DOORWAY error and what it contains, explains the lower-confidence behavior for gap_unknown, that open passages get no leaf allowance, the default door_intrusion_m of 4 cm, the 'tight' verdict near zero margin, and explicitly excludes approach path and turns from evaluation.

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 question is front-loaded in sentence one, and given 12 parameters and zero schema coverage the length is largely justified. It is dense and reads as a wall of text, but sentences earn their place by disambiguating parameters and edge cases.

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 complex analysis tool with an output schema, the description supplies the operating model, error behavior, and limitation scope an agent needs. Remaining gaps are the unexplained required `path` and the units/detail toggles.

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?

At 0% schema coverage the description must compensate and largely does: it gives three concrete dims formats, dims_unit, opening_id provenance, door_state semantics, door_intrusion_m default, allow_roll, and allow_legs_removed, plus load_options. However the required `path` parameter and the units/detail/item_name params are never explained, leaving real gaps.

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 question — 'Can this item go through that door or open passage?' followed by 'Tests a rigid box through the clear opening, turning it any way it can go' — states a specific verb, resource, and method. It is clearly distinguishable from the sibling room_check_fit (which it references for the dims format) 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 tells the agent where opening_id comes from (room_list_openings), that windows are refused, and what edge cases mean. There is clear usage context but no explicit statement of when to prefer room_check_fit over this tool, so it stops short of full alternative routing.

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 delivers: it explains that verdict (fits/tight/probably_not/does_not_fit) is margin divided by scan uncertainty, that a 1 cm margin on a drifty scan is 'tight, never fits', that it respects doors, swings, windows and existing furniture, and that ambiguous references return an error hinting all walls with ids and lengths. It also flags the self-blocking case and the return of placements with footprints.

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 core question and purpose before any parameter detail, and nearly every sentence carries usable information. It is long and parenthetical-heavy, which costs some 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?

For a 14-parameter spatial computation tool with an output schema, the description covers the decision logic (verdict thresholds, orientation-gated references), the edge cases (ignored objects, self-blocking, error hints) and which sibling to reach for on follow-up. Only the unexplained path/units/rotations_deg/respect_door_swing parameters keep it short of perfect.

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 description must compensate, and it does for most parameters: three accepted dims formats with unit conventions, dims_unit default, item_name, target (wall ids, natural-language wall references, region objects), clearance presets and object form, windows policy, ignore_objects, max_results 1-10, detail summary|full, and delegation of load_options to room_summary. However, path, units, rotations_deg and respect_door_swing are never explained anywhere.

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 concrete question ('Will this item fit?') and states the exact operation: checking an item's footprint against a wall's free run or the whole room, returning a verdict with margin. This cleanly separates it from sibling checks such as room_check_doorway and from measurement/listing tools like room_list_walls.

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 strong conditional guidance: when compass-wall references are valid ('ONLY when the scan defines an orientation'), what happens on an unclear reference, and when to list items in ignore_objects. It cross-references room_load_scan, room_list_walls, room_summary and room_floor_plan_svg, but never states explicit when-not conditions versus room_check_doorway.

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 so: it discloses the persistent side effect (SVG ALWAYS written to MEASURE_MCP_OUTPUT_DIR with the exact default path), filename sanitization (folders stripped, .svg enforced, default 'floor_plan'), the reply shape (path, plus inline svg only under ~30 KB), and label escaping. These are exactly the behavioral traits 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?

Front-loads what is drawn, then parameter semantics, then output/side-effect behavior — a logical order with no filler sentences. It is dense and slightly long, but each sentence (placement provenance, filename rules, size threshold) conveys actionable 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 an 11-parameter, no-annotation tool this is substantially complete, and the existence of an output schema means return values need not be repeated. Remaining gaps are the required 'path' argument and the rendering booleans (show_labels, show_dimensions, px_per_m), which an agent must guess at.

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% and there are 11 parameters, so the description must compensate. It meaningfully explains placement (source and optional 'verdict' key), dims/item_name (label-only), units (dimensions written in requested units), output_name (sanitization and default), and load_options. It leaves path (required!), px_per_m, dims_unit, show_labels, and show_dimensions unaddressed, so coverage is strong but incomplete.

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 ('Draw the room as a floor plan SVG') and enumerates exactly what is rendered (walls with dimension lines, doors with swing arcs, windows, furniture, optional item), which separates it from sibling exporters like room_summary. An agent can identify its output artifact 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 clear integration context: 'placement' should be one entry of 'placements' from room_check_fit, and load_options behaves 'as in room_summary'. This routes the agent from the fitting/check step to the rendering step. It lacks explicit when-not guidance or a named alternative renderer, so it stops short of a 5.

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 still carries useful behavior beyond the schema: category provenance (Apple categories on RoomPlan scans vs 'unknown' on raw point clouds), case-insensitive filtering, and the important capping rule with detail="full" escalating to a complete list. It omits any statement of read-only/side-effect profile, but 'List' implies it.

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?

Purpose is front-loaded in the first sentence, with behavioral caveats following in compact sentences. Dense but each clause earns its place; slight clutter from the parenthetical category examples.

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?

An output schema exists, so return values need not be re-explained, and the description is sufficiently complete for a bounded listing tool. The main gap is units and path semantics, which remain undocumented given 0% schema coverage.

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%, so the description must compensate. It adds real meaning for category (case-insensitive filter) and detail (full vs capped), and cross-references load_options to room_summary, but says nothing about units or path, leaving half the parameters to be inferred from enum values alone.

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 (List) and resource (furniture and appliances found in the scan) and enumerates the returned attributes. It is trivially distinguishable from siblings like room_list_walls and room_list_openings, which list different resources.

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: the description notes filtering, capping, and that load_options works 'as in room_summary', but never states when to reach for this tool versus room_summary, room_load_scan, or measure_object. An agent can infer the context but gets no explicit when/when-not or alternative routing.

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 it delivers a genuinely useful caveat: RoomPlan door sizes may be leaf size rather than clear opening, so tight doors should be tape-measured. It also discloses the downstream compatibility rule for check_doorway. It does not state permissions or output scope, but for an obvious read-only list tool that gap is minor.

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-loads the return content in sentence one, then filters and caveats. Every sentence carries information (filters, cross-tool constraint, measurement warning). The mid-sentence parenthetical '(see room_check_fit)' and the run-on filter sentence make it slightly denser than ideal.

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?

An output schema exists, so return values need no explanation, and the description instead spends its space on the things structured data cannot carry: the door-size caveat, the natural-language wall_id behavior, and the check_doorway compatibility rule. Nothing an agent needs to invoke this 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 description coverage is 0%, so the description must compensate, and it does for the two non-obvious parameters: ''kind'' enumerates all four valid values, and ''wall_id'' is revealed to accept natural-language phrases ('longest wall', 'wall behind the sofa') with examples, which the schema cannot convey. ''load_options'' is delegated to room_summary; ''path'', ''units'' and ''detail'' are left to self-explanatory enums, so it is strong but not fully compensating.

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 ('List doors, windows and open passages') and immediately enumerates the returned attributes (width, height, sill, head height, wall, position, swing side), so an agent knows exactly what this returns versus room_list_walls or room_list_objects. The scope is unambiguous 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 filtering guidance ('filter by kind or wall_id') and a real cross-tool constraint: only door/opening/gap_unknown entries are usable with room_check_doorway. It points to room_check_fit for natural-language wall references. It never states when NOT to use this tool (e.g. use room_list_walls for wall geometry), so it stops short of a 5.

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 disclose real data-model behavior: free_segments exclude door/opening spans with a 5 cm jamb margin, windows do not cut a wall, min_free_length_m filters by longest free run, and long listings are capped. It omits any read-only/permission framing, but for a room-scan query that is minor.

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 what is listed, then layered with the free-segment rules and the filter parameter. It is dense and slightly long, but nearly every sentence encodes a non-obvious rule, so little is wasted.

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 moderately complex listing tool with an output schema and no annotations, it covers the field semantics, the filtering parameter, and the free-segment computation rules, which is enough for correct invocation. The only gaps are the undocumented units/path parameters and no explicit safety framing.

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 description must compensate and it largely does: min_free_length_m is explained precisely (hides walls whose longest free run is shorter), detail's "full" behavior is noted, and load_options is cross-referenced to room_summary. The units and path parameters are left unexplained, though units is self-evident from its enum.

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 precise verb and resource ("List the walls") and enumerates exactly what each entry carries (label, id, length, height, direction, free segments, objects along the wall). This clearly differentiates it from siblings like room_list_openings and room_list_objects, since it is scoped to walls specifically.

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 use cases: "find a wall for a bed, sofa or bookcase" and "map 'the wall behind the sofa' to an id." That is strong context, but it names no alternative tool or when-not condition (e.g., vs. room_list_openings or room_summary).

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 so well: it discloses that units and up-axis are detected from geometry and 'never trusted from file metadata', that raw scans are less precise and carry +/- and confidence, that corrupt/empty files return an error with a code and hint, and that no option is remembered. These are exactly the behavioral traits structured fields do not provide.

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?

Long but dense and front-loaded: purpose first, then path, then per-parameter guidance, then a STATELESS block and caveats. Most sentences earn their place, though the format-support sentence is somewhat sprawling and could be tightened.

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?

An output schema exists, so return values need not be re-explained, and the description covers the remaining complexity for a 7-parameter loader: detection heuristics, override vs auto semantics, calibration, error behavior, and cross-tool handoff. Nothing essential 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 0%, so the description must compensate, and it explains most parameters: path, scan_units/up_axis as overrides, north_deg with its frame convention, and known_dimension with a concrete object shape. The supported-format prose implicitly maps the format enum. The 'units' parameter (metric/imperial/both) is never explained, leaving one 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+resource ('Read a room scan') and enumerates exactly what it reports (walls, doors, windows, objects, size, detected units and up axis). It also situates itself relative to siblings by naming room_list_walls and referring to 'the other room_* tools', so an agent can tell it is the loader rather than a query tool.

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 operational context: pass scan_units/up_axis 'only to override', use known_dimension to calibrate, and note that scans with no compass cannot resolve 'north wall' references. The STATELESS note tells the agent to carry load_options forward to other room_* tools. It stops short of an explicit when-to-use/when-not statement versus room_summary or the other room_* readers.

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 so well: it discloses that each measurement carries a value, ~95% tolerance, confidence and display string, that detail="full" adds names/sources and lifts list caps, and that nothing is remembered across calls. Return-format detail is partially redundant with the output schema, keeping it below a 5.

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 primary purpose is front-loaded in the first sentence, followed by dense but informative parameter and output notes. Some output-format detail overlaps the existing output schema, which is minor waste, but nothing is 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?

Given a 4-parameter tool with an output schema and no annotations, the description covers inputs, output shape and cross-tool state (room_load_scan) thoroughly enough to call it correctly. The only shortfall is the absence of selection guidance relative to the many sibling tools.

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%, so the description must compensate, and it does: path is the scan file, units drives the display string, detail="full" expands measurement metadata and lifts caps, and load_options is defined as room_load_scan's non-empty return object. All four parameters get meaning beyond their bare titles, though enum values are not individually unpacked.

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 opener states a specific resource and enumerates what the summary contains: footprint shape and vertices, floor area, ceiling height, volume, wall lengths, openings and objects. An agent can grasp what it returns without opening the schema. It does not, however, explicitly distinguish itself from siblings like room_list_walls or room_list_openings.

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 statement or named alternative. Usage is only implied, mainly through the conditional note that load_options should be passed only if room_load_scan returned a non-empty object, which hints at the intended workflow but not at tool selection.

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