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 meaningful behavior: it uses the HIGH (conservative) cost estimate, the exact ROI formula, and the 15% default threshold. It does not disclose the return shape (pass/fail boolean vs numeric ROI) or any edge-case 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-loaded with the purpose, then the formula and default, then the argument list. Slightly duplicative in restating parameter names, but each sentence carries useful information.

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

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

For a no-annotation, no-output-schema tool with 4 parameters, the description covers inputs and computation logic well but never states what the tool returns (a boolean clearing the threshold, the ROI value, etc.), which an agent needs to interpret the result.

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: each of the four parameters is annotated with its meaning (high-end cost estimate, current rent, target rent, minimum ROI percentage), and the formula clarifies how they interact.

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 ('check whether a renovation plan clears the minimum ROI threshold') and adds the formula and default threshold, so an agent knows exactly what is computed. It does not name or differentiate itself from sibling estimation tools, so it falls short of a 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?

Usage is only implied: the description makes clear it is a threshold check on a renovation plan, but gives no explicit when-to-use versus the many estimate_* siblings, and no prerequisites or exclusions.

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. It usefully discloses internal behaviors that affect the output (sqft drives size category thresholds, bathrooms act as a cost multiplier, year_built triggers risk flags), but says nothing about permissions, determinism, failure modes, or the shape of the returned line-item breakdown beyond naming 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?

The one-line purpose is front-loaded, followed by a clean arg list where each entry earns its place. It is slightly long, but the length is justified by nine undocumented parameters 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 nine-parameter tool with no annotations and no output schema, the description covers the input surface thoroughly. The remaining gap is decision support: it does not help an agent choose this tool over the many similarly named sibling estimators, nor does it describe the returned breakdown's contents.

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 entirely, and it does: every one of the nine parameters is documented with added meaning, including size-category thresholds, the bathroom multiplier, cost ranges per scope_level, and concrete finish_tier examples. The schema alone provides only bare titles, so this is genuinely additive.

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 per-unit renovation cost with line-item breakdown.' The 'per-unit' qualifier meaningfully scopes it against the sibling estimate_full_property. However, it never distinguishes itself from close siblings like estimate_scope or estimate_from_deal, so an agent has no basis for choosing among them.

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: 'per-unit' suggests this is the single-unit variant versus a full-property or deal-level estimate. There is no explicit when-to-use/when-not statement and no named alternative, leaving routing among the ten sibling estimators 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 supplied, the description must carry the full behavioral burden, and it partially does: it discloses error behavior ('problem dict' with error_type on the not_implemented guard) and the index-aligned return contract. It never states whether the operation mutates state or what permissions/inputs it needs, leaving the safety profile unaddressed.

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 transformation is front-loaded in the first sentence, which is good, but the trailing 'slice B PR 3' release note adds noise an agent cannot use. Size is otherwise reasonable.

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?

Because there is no output schema, the description usefully spells out the {estimates, renovation_programs} return shape and the index-aligned mapping. It is still incomplete on the input side (opaque deal_dict) and on side effects, so it is adequate but not fully self-contained.

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% for both parameters, and the description only gestures at 'deal + scenarios' and index alignment with scenarios_list. deal_dict is an opaque additionalProperties object whose relevant fields are never explained, so the description does not compensate for the schema 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?

The description names a concrete pipeline (deal + scenarios → per-scenario ScopeRequests → estimates → renovation_program dicts), which is more specific than a bare restatement of the name. However, it leans on internal jargon ('slice B PR 3', 'project back') and never distinguishes itself from siblings like estimate, estimate_scope, or estimate_full_property, so an agent cannot easily route between them.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no named alternative among the many sibling estimators. The only contextual remark ('Per-type dispatch lands in slice B PR 3') is a development roadmap note, not actionable usage direction.

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 supplied, so the description carries the full behavioral burden, and it is silent on side effects, whether anything is persisted or registered, determinism, auth requirements, or cost/latency. The only behavioral hint is the exterior_items default ('default: all'), which is input semantics rather than tool 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?

One front-loaded sentence gives the purpose, then a tight Args list; no filler, no repetition of the name, and every line carries information the agent needs to construct the call.

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-parameter computational tool with no annotations and no output schema, the input side is well covered but the output side is entirely absent — the agent is not told the shape of the returned estimate, whether it is per-unit and per-exterior-category, or in what currency/units. Usage context relative to the many sibling estimators is also 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%, and the description compensates well: it names every parameter and adds meaning absent from the schema, including the nested unit keys (unit_id, sqft, bedrooms, bathrooms, scope_level, finish_tier) and enumerations the schema lacks ('B' or 'C', 'dallas' or 'birmingham', the seven exterior categories). It stops short of defining allowed values for scope_level/finish_tier or the units of sqft.

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: 'Property-level estimate rolling up unit costs + exterior CapEx.' It is clear what is produced, but it never distinguishes itself from near-identical siblings such as estimate_property_from_model, estimate_scope, or estimate_from_deal, so an agent cannot route confidently among them from the description alone.

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

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance anywhere in the text. The Args block documents inputs but leaves the agent to infer the scenario (whole-property renovation budgeting) and gives no hint about when this beats estimate_property_from_model or estimate_scope.

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 behavioral burden. It documents the input shape thoroughly but says nothing about what the tool returns, whether it has side effects, authentication needs, cost, determinism, or error behavior for an estimation/compute operation.

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 front-loaded with the tool's identity and then uses a structured Args block. The length is justified by the zero-coverage nested schema, though the opening sentence could be tightened 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?

Given a complex nested input and no output schema, the description adequately covers the request shape but omits any description of the response or failure modes. For an estimation tool with multiple sibling alternatives, this leaves a meaningful 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% and the sole parameter is an untyped nested object, so the description is the only source of parameter meaning. It fully enumerates required and optional keys, their types, and the structure of unit_mix, which is exactly what an agent needs to construct a valid call.

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 (estimate) and resource (property-level estimate) plus the underlying model (Property entity model). It signals preference over loose kwargs but does not differentiate itself from siblings like estimate_full_property or estimate_from_deal, so an agent still needs schema inspection to choose among the estimation 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?

The phrase 'preferred API for Plat — replaces loose kwargs' gives an implied usage cue, but there is no explicit when-to-use/when-not guidance or named alternative. The agent must infer that this is the modern entry point over unspecified older calls.

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 full burden, and it does disclose two useful traits: it persists (request, estimate), revealing a write side effect, and it names the error return shape (ValidationProblem dict). It omits auth requirements, idempotency/upsert semantics, and what 'persist' means for repeated calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the primary action and side effect, then the return contract. No filler; it is terse rather than padded, though the terseness comes at the cost of omitted 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?

No output schema and no annotations, so the description must do more work than it does. It does name the return values, which partially compensates for the missing output schema, but the nested, undescribed request object remains a black box, which is the critical gap for a tool whose only input is that object.

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?

There is a single parameter at 0% schema description coverage, and it is an open object with additionalProperties=true, so the schema conveys nothing about its contents. The description names 'ScopeRequest' but supplies no field, type, or example, leaving the agent unable to construct a valid argument.

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 verb ('estimate') and a domain resource ('ScopeRequest') and claims to be the 'Canonical entry point', which hints at precedence. However, 'ScopeRequest' is never defined and the description does not distinguish this tool from the many sibling estimates (estimate, estimate_full_property, estimate_property_from_model, estimate_from_deal), so an agent cannot confidently pick 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?

'Canonical entry point' is the only routing hint, but there is no explicit statement of when to use this versus estimate, estimate_from_deal, or estimate_property_from_model, nor any prerequisite or exclusion. No when-not guidance at all.

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. It usefully discloses detection thresholds (30%+ above benchmark, vague lump sums, unrealistic timelines), which is genuine behavioral context. However it says nothing about permissions, reversibility, or what the evaluation returns, leaving an agent partially informed about a 10-parameter 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 and flag summary are front-loaded and efficient. The Args block, however, largely restates parameter names already in the schema, adding only the enum values and the bid_line_items shape. It is defensible but partly redundant 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 10-parameter tool with no output schema and no annotations, the description covers inputs acceptably but never describes the shape of the returned evaluation or the flag output. Given the absence of an output schema, more detail on what an agent receives back would be expected.

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 enums are absent from the schema, so the description does real work: it explains bid_line_items expects dicts with 'description' and 'amount', notes timeline_days is None when unspecified, and supplies the enum values for scope_level ('light'/'standard_value_add') and finish_tier ('basic'/'upgraded'). These are essential details not present in the structured 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: 'Evaluate a contractor bid against the internal cost estimate.' An agent can immediately tell this assesses a bid rather than producing an estimate, which is what most siblings do. It stops short of naming a sibling to route against, 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?

The description never says when to reach for this tool versus alternatives like estimate_scope or check_renovation_roi, nor does it state prerequisites (e.g. whether an internal estimate must already exist). The flag criteria hint at intended use but no explicit selection guidance is given.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses what is produced ('material specs, quantities, and quality standards'), but says nothing about side effects, whether the document is persisted, authentication needs, or cost — notable gaps for an unannotated generation 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-loads the verb and output in two tight sentences, then lists args compactly. No redundancy, though the arg annotations are terse and could be slightly more informative.

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

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

With no output schema and no annotations, the description does describe the return document's content and fills the enum gap. However, it omits persistence/side-effect behavior and sibling differentiation, leaving meaningful gaps for a 7-parameter unannotated 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?

With 0% schema description coverage and no enums declared in the schema, the description compensates by enumerating the allowed values for scope_level ('light' or 'standard_value_add') and finish_tier ('basic' or 'upgraded'), which the schema omits entirely. The remaining params largely restate titles, keeping it short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Generate a detailed scope of work (SOW)') and clarifies the audience and output ('contractor-ready document'). An agent can distinguish it from estimate-style siblings, but the description never explicitly contrasts it with close siblings like estimate_scope or evaluate_contractor_bid.

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 phrase 'for contractor bidding' hints at a scenario but provides no when-to-use vs when-not guidance and names no alternative tool. With siblings such as estimate_scope and evaluate_contractor_bid, the agent gets no help choosing between them.

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. It does disclose the return shape (list of dicts of triples) and the empty-list edge case, which is genuinely useful behavioral detail, but it says nothing about permissions, whether the history is ordered/complete, or pagination for a read tool with no annotation coverage.

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 tight sentences with zero filler, front-loading the return contract and then the edge case. The tuple notation is dense but compact and informative.

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

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

With no output schema and no annotations, the description does the important work of describing the return structure and the empty case. What remains missing is ordering/recency semantics and any usage context relative to the estimate siblings.

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 parameter property_id is undocumented in the schema. The description implies scoping 'for a property' but never names or explains property_id's format, so it only marginally compensates for the coverage gap; with just one obvious parameter, this is acceptable but thin.

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 ('Return') and resource ('property history') and even names the exact tuple structure returned. It does not explicitly contrast with siblings like estimate_scope or generate_scope_of_work, but the resource is distinct enough that confusion is unlikely.

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 guidance on when to use this versus the many estimate/scope siblings, nor any prerequisite or context for calling it. The agent must infer usage entirely from the name.

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 well: it discloses the exact return structure (renovation_program, roi_result, ready_to_underwrite) and the failure behavior including the path_to_pass guidance in roi_result. It stops short of stating side effects or auth/compute-only nature, but failure-mode and output disclosure is genuinely informative.

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 a compact pipeline summary, a bulleted return block, the ROI-failure behavior, and an args list. Slightly long but every section adds distinct value; the only minor redundancy is restating the pipeline flow in prose after the purpose line.

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

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

For a 15-parameter tool with no output schema and no annotations, the description is substantively complete: it covers purpose, returns, failure path, and most argument semantics. Remaining gaps (no side-effect safety statement, no note on whether it writes files) are minor given the compute-style pipeline it describes.

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: it explains that unit_sqft drives the size category, gives the 'YYYY-MM' format for start_month, enumerates valid values for scope_level, finish_tier, property_class and market, notes year_built triggers risk flags, and gives defaults for downtime_days and threshold_pct. The few undocumented params (bedrooms, rent figures) are self-evident, though this stops short of a full 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States specific verbs and resources: estimates unit cost, validates ROI, and produces an underwriting-ready renovation program. The three-stage pipeline (estimate → ROI gate → bridge dict) is concrete. However, it never names or contrasts with siblings like check_renovation_roi or estimate_scope, so an agent must infer this is the composite wrapper rather than the single-purpose 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?

The phrase 'Runs the full pipeline' implies this is the end-to-end option versus the granular siblings, but there is no explicit when-to-use or when-not-to-use guidance. The ROI-failure branch is described, but the choice against check_renovation_roi + estimate_scope 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 zero annotations, the description carries the full burden and does it well: it discloses idempotency, the identity key (external_alias), the property_id minting, the FloorPlan dedup key, and the create-on-miss side effect, plus a behavior-change note about previously dropped floor plans. Missing only auth/permission requirements and a fuller return description, which the absent output schema would otherwise require.

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 single most important fact ('Idempotent property registration') and keeps supporting detail tight. The trailing sentence recounting 'the previous behavior silently dropped it' reads as changelog rather than call guidance, costing a bit of economy.

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 write tool with no annotations, no output schema, and an opaque nested parameter, the description covers behavior and idempotency well but leaves gaps: the structure of the Property dict, required fields, and error/failure behavior are not addressed. It is adequate but not fully self-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 coverage is 0% for a single nested property_data object (additionalProperties=true), so the schema is effectively opaque. The description compensates by naming the payload shape ('Property-shaped dict') and the optional inline floor_plans key, but it never enumerates the required Property fields or the floor_plan fields, so an agent still can't construct a valid payload from the definition 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+resource ('property registration') and immediately qualifies it as idempotent, plus names the concrete effects (mints property_id, dedupes floor_plans). No sibling is a registration/write tool, so differentiation is not the binding constraint here, but the description never explicitly contrasts with the estimation siblings.

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 guidance and no alternative tool is named. The idempotency and dedup explanation implies repeat-call behavior but leaves the agent to infer when registration (vs. estimation) is the right call.

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