RentalAnalytics rent tools

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it discloses the exact decision rule (hold inside 5%, blend 65% of gap under market, 50% over market), the illustrative rather than measured nature of turnover cost, and the failure mode when no median exists. That is unusually rich behavioral context.

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?

Dense and front-loaded: purpose first, then methodology, then the caveat and abort condition, with no filler. However, repeated references to 'the page's gap bands' and 'the page's illustrative' are ambiguous for an agent that cannot see the calling context.

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 read-only advisor with no output schema, the description explains what is computed (market rent, recommended rent, turnover cost) and the abort condition, which is close to complete. It stops short of describing the returned fields explicitly and says nothing about how bedrooms/property_type affect the recommendation.

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 carry parameter meaning. It does explain zip (drives the market rent lookup) and current_rent (basis for the 1-2 month turnover cost), but bedrooms and property_type are left completely undefined in both schema and prose.

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 ('Lease renewal advisor') and immediately defines its scope: it computes a recommended renewal rent from a ZIP-level market estimate. That is unmistakably distinct from the calculate_* and lookup_* siblings, and it even signals its dependency on estimate_rent.

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

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

Usage is implied by 'Lease renewal advisor' and by the stated abort condition ('if the rent estimate has no median, this tool stops'), but there is no explicit when-to-use-vs-alternatives guidance against siblings like estimate_rent or calculate_cash_flow. The agent must infer the scenario from the name and methodology.

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. Beyond that, the description adds a genuinely useful computational convention ('interest is rounded to the cent each month') and discloses the two output modes, which is real behavioral context not present in structured fields.

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 tight sentences with no filler; the identity/rounding statement is front-loaded and the include_schedule branch follows logically. Nothing wasted, nothing padded.

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

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

For a read-only calculator with no output schema, the description names the returned aggregate fields (payment, payoff date, total interest, total paid) and the schedule mode, which is what an agent needs. The gaps are the undocumented numeric parameters, particularly extraMonthly's behavior.

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

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

Schema description coverage is only 17% (one of six params documented), so the description must compensate. It explains include_schedule's branching semantics well but says nothing about extraMonthly (does it shorten term or lower payment?) or firstPaymentDate's effect on the schedule start.

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: it produces a 'fully amortizing mortgage schedule' with interest rounded monthly. An agent can distinguish it from the other calculate_* siblings (dscr, cap_rate, cash_flow) on domain alone, though the description never explicitly contrasts itself with 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 implied by the domain (compute a mortgage amortization schedule) rather than stated. There is no explicit when-not-to-use or named alternative, though the sibling set is functionally distinct so mis-selection risk is low.

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, and closed-world, so safety is covered. The description adds real behavioral value beyond that: the external data source (cap-rate-benchmarks.json), the Tier 2 fallback for unknown ZIPs, the 3% closing assumption for cash-on-cash, and the caveat that bands are estimated survey ranges rather than fresh comps.

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 computation is front-loaded in the first sentence and the qualifying behaviors follow in a logical order. Four dense sentences stay on topic, though the closing caveat about bands is slightly tangential for a tool-selection description.

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

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

With no output schema, the description does surface key result semantics (benchmark band comparison, fallback tier, cash-on-cash methodology). Still, for a 10-parameter calculator with 20% schema coverage and multiple undocumented financial inputs, the parameter-level picture is incomplete.

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

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

Schema description coverage is only 20% across 10 parameters, so the description bears most of the burden. It clarifies the ZIP param (tier selection only) and the financed path, but leaves interest_pct, loan_term_yrs, down_payment_pct, op_expenses_annual, annual_gross_rent, and property_type essentially undefined beyond their names.

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?

It states a specific verb and resource — a cap rate calculator — and defines the exact computation (NOI divided by purchase price) plus its benchmark comparison. This formula clearly separates it from sibling calculators like calculate_gross_yield or calculate_cash_flow without needing to open their schemas.

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 explains downstream behavior (unknown ZIPs fall back to the file's Tier 2 band; financed deals use the page's 3% closing estimate), which implies how the tool behaves. However, it never says when to reach for this tool versus alternatives such as calculate_gross_yield or calculate_dscr, 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine behavioral context by disclosing an embedded assumption ('closing costs are the page's 3% estimate') and the time basis of inputs, though it does not cover defaults, error behavior, or how missing optional inputs are handled.

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

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

Three compact sentences with the core function front-loaded, followed by output list and assumption/unit notes. Every sentence carries information, though the unit sentence is partly redundant with the schema.

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

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

With no output schema, the description usefully enumerates the computed results and flags the 3% closing-cost assumption. For a 10-parameter calculator it is reasonably complete, though it omits which optional inputs have defaults and how the two undocumented parameters (purchase, intPct) are interpreted.

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 80%, so the schema largely documents the parameters. The description's unit notes ('taxes and insurance are annual; maintenance is monthly') restate what the schema descriptions already say, and it adds nothing for the two undocumented parameters (purchase, intPct). Baseline 3 applies.

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

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

The description names a clear verb+resource ('Cash flow analyzer') and enumerates the specific outputs (itemized P&L, cap rate, gross yield, cash-on-cash, break-even occupancy), so an agent knows exactly what it computes. It fails to differentiate from siblings like calculate_cap_rate and calculate_gross_yield, which compute overlapping metrics, so it stops 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?

There is no guidance on when to use this tool versus the many overlapping siblings (calculate_cap_rate, calculate_gross_yield, calculate_opex, calculate_dscr). The purpose implies it is a full underwriting calculator, but the description gives no conditions, prerequisites, or alternatives to route the agent correctly.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the precise computation model, and the conditional behavior that omitting targetDscr leaves max loan empty. It does not discuss rounding, units, or error conditions.

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?

Five tight sentences, front-loaded with purpose and then the formulas; each sentence adds defining information with little waste. It is dense rather than bloated, though the run-on NOI sentence could be broken up for readability.

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

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

For a 10-parameter, no-output-schema calculator, the description supplies the outputs (DSCR, max loan), the derivation of each, and the conditional parameter behavior, which is enough to invoke it correctly. The main residual gap is that loanAmount and the rate/term inputs are not explicitly mapped into the debt-service or max-loan computation.

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 only 10%, so the description carries most of the burden, and it largely does: monthlyRent (rent times 12), vacancyPct (1 minus vacancy), taxesAnnual, insuranceAnnual, hoaAnnual, otherAnnual, and targetDscr (omit it and max loan stays empty). ratePct and termYears are only implied via 'fully amortizing payment', and loanAmount's role is never stated, leaving a small but real 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 opens with a specific verb+resource ('DSCR calculator') and goes further by spelling out the exact NOI, debt-service, and max-loan formulas, making its scope unmistakable against siblings like calculate_cap_rate or calculate_amortization. It stops short of naming or contrasting those siblings explicitly, so it is clear but not sibling-differentiating.

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 by the formulas and the note that targetDscr is optional and that '1.25 is not assumed' – useful signal that max loan is only returned when a target is supplied. There is no explicit when-to-use guidance and no routing to alternative calculators such as calculate_amortization or calculate_cap_rate.

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. Beyond that, the description discloses the exact rounding formula (half-up hundredths), which tells the agent the operation is a pure deterministic computation with no hidden lookups or side effects.

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, purpose front-loaded, followed by the exact formula and a single disambiguating clause. No filler; every element 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?

There is no output schema, but the embedded formula tells the agent precisely what numeric result to expect, so the return value is effectively covered. For a two-input pure calculator this is nearly complete, with only parameter units (e.g., currency) left implicit.

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 must carry parameter meaning, and it does: 'rent' is specified as monthly (annualized via *12 in the formula), and 'value' is clarified as a user-supplied figure rather than a looked-up price. It stops short of stating types or units for value, but the added semantics are substantive.

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 computation (gross yield) over specific inputs (monthly rent and value) and explicitly distinguishes itself from the sibling lookup_gross_yield by noting 'It does not look up a price.' An agent can pick between the calculate_* and lookup_* tools without reading further.

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 monthly rent and value you pass' plus 'It does not look up a price' tells the agent to use this when it already holds both inputs, routing away from the lookup variant. It gives clear context but never names the alternative tool explicitly, leaving the routing inference one step short of 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?

Annotations already declare this as read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds a genuine data-quality caveat (benchmark bands are illustrative, not a metro measurement), which is useful context beyond the annotations, though it says nothing about how the calculation handles the many input modes.

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, fully front-loaded with the core purpose followed by the important caveat. No filler, though the two caveat sentences could be tightened into one without losing meaning.

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 computation with almost no schema documentation and no output schema, the description is too thin. It explains the output concept and the benchmark caveat but leaves the agent unable to correctly map or interpret most of the required and optional parameter behavior.

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

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

Schema description coverage is only 10% across 10 parameters, so the description carries the burden but fails to compensate. It references EGI (one of the ten) but never explains taxes, insurance, maintenance, mgmt_pct, mgmt_dollars, mgmt_mode, mode, vacancy_pct, or monthly_rent, nor the interplay between mgmt_pct/mgmt_dollars and annual vs monthly modes.

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 tool produces operating-expense lines as a percent of effective gross income and compares them to national benchmark bands, which distinguishes it from the other calculate_* siblings that handle amortization, cap rate, cash flow, etc. It lacks an explicit verb ('Calculate...'), reading as a noun phrase, but the resource and output are 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 when-to-use guidance, no prerequisites, and no mention of alternative tools. The caveat that the bands are 'illustrative' and 'not a metro measurement' concerns interpretation of results rather than when or how to invoke the tool.

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

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

Annotations already cover readOnly, idempotent, non-destructive, and closed-world traits, so the bar is lower; the description still adds real behavior: the rent-sourcing order (ACS B25031 → HUD FMR) and the failure mode ('The tool does not invent one'). That last line is a genuinely useful disclosure about non-fabrication. It does not explain the calculation behavior for the other cost parameters, keeping it from 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?

It is front-loaded with the purpose sentence, and the remaining sentences each carry substantive information about rent sourcing. The sourcing sentence is long and comma-heavy, but every clause is doing work 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?

This is a 15-parameter financial calculator with no output schema and no annotations describing the result, yet the description says nothing about what the comparison returns or how the ~10 cost inputs affect it. For a tool of this complexity, the coverage of the input surface and output is well short of what an agent needs.

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. It only covers nightlyRate, occupancyPct, and monthlyRent (and touches zip/bedrooms via the sourcing logic); the other ~10 cost parameters (hoaAnnual, taxesAnnual, strMgmtPct, ltrMgmtPct, platformFeePct, etc.) are undocumented anywhere. It also refers to 'monthly_rent' while the schema field is 'monthlyRent', a minor naming mismatch.

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

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

The description states a specific comparison: short-term rental revenue (nightly rate × occupied nights) vs long-term rent. It even defines how each side is computed, which makes the tool's purpose concrete. However, it never differentiates itself from near siblings like estimate_rent, lookup_hud_rent, or calculate_cash_flow, leaving the agent to guess why this tool rather than those.

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 implied usage via the fallback logic ('if you omit it... otherwise... pass monthly_rent'), which tells the agent how to invoke the LTR side under different conditions. But there is no explicit when-to-use or when-not-to-use statement and no comparison against the sibling calculators that also deal with rent.

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

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

Annotations already cover the read-only/idempotent/non-destructive profile, but the description adds real behavioral context beyond them: the estimate is a 50th-percentile scaled/aged figure, FMR remains a 40th-percentile voucher number, ACS B25031 is a secondary anchor, and crucially a ZIP absent from both sources returns an error with no invented national fallback. That error/fallback contract is genuinely useful disclosure the annotations cannot 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?

The description is dense and poorly front-loaded, opening with a URL reference and internal artifact names (hud-50th-sample.json, BLS CPI Shelter, ACS B25031) that read like implementation notes rather than selection guidance. Several clauses describe pipeline mechanics the agent cannot act on, diluting the signal-carrying content.

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

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

For a 3-parameter estimation tool with no output schema, the description should clarify parameter meanings and what the returned estimate represents. Instead it documents data provenance and the missing-ZIP error while leaving bedrooms, the zip key, and the output value undefined. Coverage of what an agent needs to invoke it correctly is incomplete.

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 all 3 parameters, so the description carries the full burden and largely fails it. It hints that a property-type multiplier exists (partially explaining property_type) but says nothing about the zip input or the bedrooms parameter, including its default of 2 or range 0-8. Two of three parameters remain 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?

The opening sentence ('The rent estimator on /tools/rent-estimator') is essentially tautological and leads with a URL rather than the operation. Only deeper in the text does it become clear the tool returns a scaled/aged median rent estimate for a ZIP, and it distinguishes FMR (40th-percentile voucher figure) from the estimate. An agent can infer the purpose but must read past jargon to get there.

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 tool versus siblings like lookup_hud_rent, lookup_rent_to_income, or lookup_covered_market. The only routing signal is the missing-ZIP error case, which is a failure mode, not a usage condition. No explicit when/when-not or alternative selection is offered.

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, so the bar is met there; the description goes further by disclosing exactly which Form 8824 lines are produced (15, 16, 18, 19, 20, 24, conditional on 23==20) and that line 21 recapture is NOT computed, plus the non-authoritative nature of the output.

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?

Delivered as two front-loaded sentences that lead with what the tool produces and close with the scope disclaimer. The Form-8824 line jargon is dense but every clause carries information rather than 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?

With no output schema, the description usefully characterizes the return (partial, specific lines, excluded recapture), which is real value. However, it leaves the 11 input parameters essentially unexplained, and for a multi-field tax calculator that is a material 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 only 9% across 11 parameters, so the description carries the full burden here and adds nothing about any input field. Domain-familiar names like adjustedBasis and debtRelieved help slightly, but no format, units, or meaning is explained, leaving most parameters 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 resource (1031 exchange / Form 8824 illustration) with an implicit 'illustrate' verb, and the 'partial illustration' framing clearly separates it from the calculate_* siblings. It does not explicitly name any sibling, but the domain scope 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?

The only guidance is a disclaimer ('planning illustration, not a filed return and not tax advice'), which is a legal caveat rather than a when-to-use rule. There is no mention of alternatives or conditions under which an agent should prefer this over the calculate_* tools.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds real behavioral context beyond them: two parameters are required because the form has no default, and bonus_percent is sourced from tax-params.json when acquired_date and placed_year are supplied, otherwise falling back to the form's stored default. That conditional-data-source behavior is not visible in the schema or annotations, though it stops short of describing the returned worksheet.

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

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

Four short sentences, front-loaded with the identity of the tool then the required-input constraint and the bonus-percent data path. No filler; the closing disclaimer is brief and arguably earns its place for a financial estimate. Sentence 2 is slightly dense but not wasteful.

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, 9%-documented tool with no output schema, the description covers only the required inputs and bonus logic. Six parameters (recovery years, short-life year-1 percent, apply_bonus_anyway override, placed_month, basis) are unexplained, and the structure of the worksheet output is left implicit. Adequate to get a minimally correct call, but not complete.

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

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

Schema description coverage is only 9% (one of eleven parameters documented), so the description carries a heavy burden. It explains the requiredness of land_percent/cost_seg_percent and the bonus_percent resolution logic tied to acquired_date/placed_year, which is genuinely additive. But basis, placed_month, short_life_years, apply_bonus_anyway, building_recovery_years, and short_life_year1_percent have no semantics anywhere, so compensation is partial.

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: a year-1 cost segregation worksheet. No sibling covers cost segregation, so it is distinguishable by topic (calculation vs. lookup_* or calculate_* tools are orthogonal domains). However it never says it 'computes an illustration/depreciation schedule,' leaving the output shape implicit.

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

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

There is no when-to-use guidance, no exclusions, and no routing to any sibling. 'Estimates for planning; not tax advice' is a liability disclaimer, not usage guidance. The agent must infer from the name alone that this is the right tool for year-1 cost segregation.

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 establish the read-only, idempotent, closed-world profile. The description adds genuinely useful behavior beyond that: coverage is bounded by whatever cities are in the file, an out-of-file city produces an explicit 'not found' response rather than a silent failure, and the output is an estimate rather than legal advice. Return shape and formatting are left unstated, keeping this from 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?

Three short sentences with no padding; the resource definition and its coverage boundary are front-loaded, and the disclaimer closes it cleanly. Slightly more could be said about parameter usage without bloating it.

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 three-parameter tool with no output schema, the description covers the coverage limitation and the non-advisory nature but omits the two things an agent most needs: which identifier parameter to use and what a returned digest looks like. Adequate but with clear gaps.

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 only 33% (just the slug example), and the description offers no explanation of how city, slug, and state interact or in what form a city name should be supplied. With three overlapping city-identification parameters and zero required fields, the description leaves an agent guessing which to populate, so it does not compensate for the coverage gap.

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

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

The description names a specific resource (a plain-English landlord-tenant digest) and its source (regulations.json), which is enough for an agent to know what comes back. It does not, however, distinguish itself from the many sibling lookup_* tools (lookup_covered_market, lookup_hud_rent, lookup_rent_to_income), so cross-tool routing still requires inference.

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 mention of any alternative tool. 'Estimates for planning' hints at an intent but never states the conditions under which an agent should call this instead of, say, lookup_covered_market or lookup_hud_rent.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world, non-destructive), so the bar is lower. The description adds real value beyond them: it discloses data provenance (markets.json, 15-city sample), that YoY/vacancy/cap rate are the file's labeled estimates, that the 12-month illustration is FMR x CPI Shelter rate, that it is not a metro forecast, and that unknown cities error. That is substantive caveat and provenance context.

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?

Provenance is front-loaded, which is good, but the description is dense and drifts into tangential detail (the 12-month illustration and CPI Shelter rate) that reads as a run-on rather than tight scoping. Not wasteful enough to punish hard, but not crisp either.

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 read-only lookup with annotations already carrying the safety profile and no output schema, the description does a fair job of explaining what is returned and where the data comes from. It remains incomplete on the three input parameters and on when to choose it over siblings, so it is adequate but with clear gaps.

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

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

Schema description coverage is only 33% (only slug is documented), so the description must compensate for city and state, and it does not. The only parameter-adjacent hint is 'An unknown city returns an error,' which weakly implies the city parameter but adds no format or semantics. The slug listing behavior lives in the schema, not the 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?

The description specifies the resource concretely: city rows in markets.json (the 15-city sample), plus the sample median/mean those pages compute. An agent can tell what data comes back. It does not, however, differentiate itself from the sibling lookup_* tools (lookup_city_rules, lookup_hud_rent, lookup_rent_to_income), so it stops 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?

There is no explicit when-to-use guidance and no alternatives named, despite many sibling lookup tools. The only conditional behavior mentioned is 'An unknown city returns an error,' which is a behavior note, not usage routing. An agent gets no help deciding when this tool beats another.

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 read-only, idempotent, closed-world, and non-destructive behavior, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond that: a county absent from the file returns an error, which tells the agent to expect failure rather than an empty result. It does not describe the return format (number vs record), which keeps it from 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?

Three short sentences with the resource and its backing file front-loaded, and the error condition placed where it is needed. The middle sentence restates the stored-figure idea, which is slightly redundant but does serve the sibling-distinction purpose.

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 read-only lookup with no output schema, the description covers what is retrieved, where it comes from, and the one failure mode. It omits the state-parameter format and whether a state missing from the file also errors, so it is not fully closed but is adequate for its complexity.

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

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

Schema coverage is 50%: county carries a schema description (name/slug/FIPS, omit for state summary) while state is undocumented. The description adds only that a value is retrievable 'for a state or county', which does not compensate for the undocumented state parameter format. Baseline 3 fits a lookup where the schema does part of the work.

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 ('gross rent yield stored for a state or county') and names the concrete backing store (gross-yield.json). Crucially, it distinguishes itself from the sibling calculate_gross_yield by emphasizing 'The yield is the file's stored figure' rather than a computed one.

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 yield is the file's stored figure' implies this is a static lookup versus a computed tool, which is a usable signal, but the description never explicitly says when to choose this over calculate_gross_yield or what prerequisites apply. No exclusions, no named alternatives — usage 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?

Annotations already declare readOnly, idempotent, and closed-world behavior, so the bar is lower. The description still adds real value: data provenance (Section 8 extract, 40th percentile) and an explicit failure contract — when the ZIP is absent or multiple town rents exist, it reports this rather than guessing. That edge-case behavior is not in the annotations.

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

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

Three sentences, each earning its place: what it returns, what the number means, and what happens on failure. Front-loaded with the core purpose and the FY scope.

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 read-only lookup with no output schema, the description covers purpose, data source, and failure semantics sufficiently to call it correctly. It could note the return shape (single rent value plus town context), but nothing essential is missing.

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

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

Schema coverage is 100%, so both parameters are already fully documented. The description's '(studio through 4)' merely restates what the schema says (0 is studio, 4 is the max stored), adding no syntax or format detail beyond it. Baseline 3 is appropriate.

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

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

States a specific verb (lookup) and resource (HUD Fair Market Rent / Small Area FMR) scoped to a ZIP and bedroom count. It also explicitly distinguishes itself from estimate_rent by clarifying it is 'not a market-rent estimate,' so an agent can tell it apart from siblings 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?

Gives clear context (published FY2026 figures, 40th-percentile voucher rent in the Section 8 extract) and the condition that selects it over market-rent tools. It stops short of explicitly naming an alternative to use instead, but the negative framing steers the agent well.

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

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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description usefully adds the error behavior for an unknown county and the storage detail that the ratio is stored in hundredths via the site's half-up formula, which is genuine context beyond the annotations.

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

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

Three tight sentences with no filler, and the primary subject (what data is stored) is front-loaded. The 'stored hundredths / half-up formula' clause is slightly dense but earns its place by explaining the returned ratio.

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

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

With no output schema, the description carries the burden of describing returns, and it does list the fields returned (median rent, renter income, HUD limits, ratio) plus the error case. It could say more about the response shape, but it is sufficient for correct invocation.

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 both parameters are already documented as state name/abbreviation and county name/slug/FIPS with the omit-for-summary rule. The description adds little parameter-level detail beyond that, so the baseline 3 is appropriate.

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

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

The description names the specific data retrieved (Census median rent, renter income, HUD income limits) and the scope (a state or county), so the resource is clear. It does not, however, differentiate itself from the similar sibling lookup_hud_rent, leaving some ambiguity about which lookup to choose.

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 schema's 'omit for the state summary' and the description's note that an absent county returns an error hint at the two modes. There is no explicit when-to-use guidance and no comparison to alternative lookups such as lookup_hud_rent or lookup_covered_market.

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