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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so side-effect concerns are covered. The description adds the return payload contents, which annotations cannot express, but says nothing about computation caveats (defaults applied silently, confidence rating, market data dependency) that a caller should know.

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 compact sentences, front-loaded with purpose and outputs before the usage hint; there is no filler. The only marginal waste is the usage clause, which largely repeats the name.

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

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

With 10 parameters, a nested assumptions object, and no output schema, the description does the important work of listing return values and framing the tool as a full underwriting run. It stops short of noting required inputs (purchase_price, monthly_income) or the confidence-rating mechanics, but an agent has enough to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including nuanced documentation for scenario, interest-basis, and the expense default, so the schema carries the parameter burden. The description adds no parameter guidance of its own (e.g., which fields are required or how source fields affect confidence), making the baseline 3 appropriate.

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

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

States a specific verb and resource ('Analyze a multifamily real estate deal') and enumerates the concrete outputs (cap rate, cash-on-cash, DSCR, IRR, DFP Score, max offer price, projections), which tells an agent what it gets back. It does not, however, differentiate itself from the sibling score_deal, which presumably also produces the DFP Score.

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 usage sentence gives trigger phrasings ('analyzing a property, evaluating a deal, running the numbers'), but those are essentially restatements of the tool name rather than real selection criteria. With siblings reverse_calc, market_data, and score_deal present, no exclusion or alternative routing is offered, so the agent must infer boundaries.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=false, covering the safety and world-awareness profile. The description adds the specific return fields (flood zone, income relative to state median, job growth rate), which is useful context beyond annotations. However, it does not describe any additional behavioral nuances such as data freshness, rate limits, or edge cases (e.g., missing data for some addresses). Given the annotations handle the core safety traits, a score of 3 is appropriate.

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

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

The description is two sentences with zero wasted words. It leads with the primary action ('Look up market intelligence for a property address'), then lists the specific returned data, and finally gives usage guidance. Each sentence earns its place; there is no redundancy or 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 simple read-only lookup with no output schema, the description adequately covers what the tool does, what it returns, and when to use it. The parameter schema fully documents inputs. However, it doesn't mention potential caveats such as data availability for certain addresses or any limitations on geographic coverage. While not critical, this leaves a small gap in completeness for an agent that might need to handle edge cases. A score of 4 reflects this minor omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% — both 'address' and 'zip' have descriptive text in the schema (address includes full property address example, zip mentions auto-extraction). The description does not add any parameter-specific semantics beyond what the schema already provides. Baseline 3 is correct when the schema carries the full parameter documentation.

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

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

The description clearly states the verb 'look up' and the resource 'market intelligence for a property address', and explicitly lists the specific data returned (flood zone, neighborhood income relative to state median, job growth rate). This distinguishes it from sibling tools like analyze_deal, score_deal, and reverse_calc, which focus on deal analysis and calculations rather than property market data.

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 provides explicit usage guidance: 'Use this when someone asks about a market, neighborhood, or location.' This gives a clear trigger for when to invoke the tool. It does not explicitly mention alternatives or when not to use it, but the context of siblings (deal analysis, scoring, reverse calc) makes the distinction implicit. A clear usage trigger without exclusions earns a 4.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and closed-world, so the safety profile needs no restating. The description adds only the general 'back-solves' framing; it does not disclose output shape, what happens when no target is reachable, or how conflicts among multiple targets are resolved — notable for a nested, constraint-solving 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?

Three sentences, front-loaded with the core purpose, then the mechanism, then the trigger phrasing. No filler and no repetition of the title.

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

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

For a 6-param tool with a nested targets object, the description gives enough intent-level framing and the schema covers semantics in full. With no output schema, the description could say more about what comes back (e.g., a max price plus the binding constraint), which is the only real 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 100%, including the nuanced 'at least one' constraint on targets and the scenario defaults, so the schema carries the parameter burden. The description repeats the target metric names but adds nothing about scenario, price_per_unit, or assumption overrides, so baseline 3 applies.

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

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

States a specific verb and resource ('calculate the maximum offer price for a multifamily deal') and names the mechanism ('back-solves from your desired cap rate, cash-on-cash, DSCR, and/or IRR'). This cleanly separates it from sibling tools analyze_deal and score_deal, which read as forward analyses rather than a price solve.

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 trigger phrases ('what should I offer?' / 'what's the max price?') that map an intent directly onto the tool. It stops short of naming alternatives or stating exclusions — e.g., when to prefer analyze_deal or score_deal instead — so it lands at 4 rather than 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds that it returns a DFP Score plus 'key metrics' and that it is faster, but says nothing about how the confidence rating is affected, what 'key metrics' includes, or how missing optional data degrades the score.

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 short sentences, zero padding, with the core purpose and scale front-loaded and the speed/screening guidance last. Every sentence carries distinct 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 8-parameter tool with a nested assumptions object and no output schema, the description covers the headline return value but leaves 'key metrics' undefined and does not warn that omitting property_address understates the market component — a caveat that only appears buried in the schema. Adequate against a fully documented schema, but not 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 description coverage is 100%, so every parameter including the nested `assumptions` object is documented in the schema itself. The description adds no parameter-level meaning of its own (no mention of the required purchase_price/monthly_income pair or that property_address drives the market component), so the baseline 3 applies.

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

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

States a specific verb and resource ('Quick-score a multifamily deal') plus the output scale ('DFP 0-100'), which is concrete enough to distinguish it from generic analysis tools. It differentiates itself from full analysis by calling itself 'quick', but never names the sibling `analyze_deal` that is the actual alternative.

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?

'Faster than full analysis — use this for quick screening' gives a clear usage context and implicitly routes deep work elsewhere. It never states an explicit when-not-to-use condition (e.g. when assumptions other than interest basis are needed, which the schema hints at via `analyze_deal`).

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