deal-analysis

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses important behaviors: all rates are fractions not percents (a critical gotcha), omitted operating inputs are auto-filled with documented defaults that appear in assumptions.estimated_fields, and the tool is free with no API key required. It also discloses that a shareable report link is returned. This covers key behavioral traits well despite no 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?

The description is information-dense and reasonably organized, front-loading the core purpose and outputs before detailing strategies and formatting gotchas. Every sentence earns its place. It's slightly long but each element (strategy list, fraction convention, defaults behavior, free/no-key, report_url instruction) adds necessity.

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 complex tool with nested inputs, six strategies, and no output schema, so the description carries substantial burden. It addresses the critical gaps: default-filling behavior, fraction formatting, minimum required inputs, and cross-referencing list_strategies for schemas. It could be more complete by briefly describing the report_url or mentioning what assumptions.estimated_fields contains, but it covers the essential completion points for an agent to use it effectively.

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

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

The description adds significant value beyond the schema. It clarifies that rates/percents are fractions, specifies the minimum acceptable inputs ('price + the income driver' with enumerated driver options per strategy), and points users to list_strategies for the full per-strategy schemas. The schema describes the two parameters well (100% coverage), so the baseline is 3, but the description's fraction-handling and minimum-input guidance raise it above baseline.

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 uses a specific verb ('Underwrite') plus a clear resource ('real-estate investment deal') and enumerates the concrete outputs: 0-100 score, verdict, cash flow, cap rate, DSCR, stress tests, break-even thresholds, and a shareable report link. It distinguishes itself from siblings by listing all six strategies and their codes, clearly differentiating from list_strategies, pull_comps, solve_max_offer, str_market_data, and best_use.

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

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

The description clearly states the tool analyzes/deals with specific strategies (ltr, str, brrr, multifamily, flip, newc), and points to list_strategies as the reference for parameter schemas. It includes explicit instructions like 'call list_strategies for each strategy's schema' and 'Give the report_url to the user.' However, it doesn't explicitly state when NOT to use this tool versus siblings like solve_max_offer or pull_comps, though the strategy enumeration and output list imply clear 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?

With no annotations provided, the description carries the full burden. It discloses several behavioral traits: it ranks results by deal score, skips strategies with missing inputs with reasons, fills omitted operating inputs with documented defaults listed in assumptions.estimated_fields, and states it's free with no key. The fraction-format warning (0.0675 = 6.75%) is especially valuable. It could go further on determinism or output structure, but this is strong given no 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?

Well-structured and front-loaded with the core question; every sentence carries behavioral value (ranking, skipping behavior, fraction format, defaults, cost). Slightly dense with the long field list, but efficient overall.

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 the nested-input complexity and no output schema, the description addresses the key concerns: what qualifies strategies, how missing inputs are handled, how omitted fields are defaulted and reported, and cost/auth (free, no key). It does not describe pagination or result size limits, but for a strategy-screening tool this is reasonably complete.

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

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

Schema coverage is 100% but only documents a single 'inputs' object parameter with a generic description ('one property's inputs'). The description adds substantial meaning by enumerating sample fields (price, marketRent, adr, occupancy, rehabBudget, arv, units) and clarifying that rates are fractions. This compensates well for the schema's shallow 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?

Description clearly states the verb+resource ('Screen ONE property across every strategy') and the precise question it answers ('what is the best use of this property?'). It also distinguishes itself from siblings by comparing multiple strategies and ranking by deal score, versus analyze_deal (single deal) or list_strategies (enumeration).

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 explicitly explains when to use it ('what is the best use of this property?'), tells the user to provide a superset of inputs, and explains behavior for missing inputs ('strategies missing inputs are skipped with reasons'). This differentiates from siblings that screen a single strategy.

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 reporting burden. It discloses the tool is 'Free, no key' (no authentication required) which is useful behavioral context. Since this is a read-only listing operation with zero parameters, there is limited behavioral surface to disclose; the description covers the key aspects (no cost, no auth, no inputs). It could have noted the output format, but for a catalog/listing tool this is reasonably complete.

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 zero wasted words. It front-loads the core action, then adds the usage trigger ('call this first when unsure'), then notes the free/no-key property. Every sentence earns its place and contributes 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?

As a zero-parameter listing tool with no output schema, the description is well-rounded. It explains what it returns (strategy list with required/optional fields), when to use it, and its cost/auth profile. The only minor gap is not describing the return structure (e.g., whether strategies are returned as a flat list or grouped), but given no output schema exists, this is a modest omission rather than a critical 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?

The tool has zero parameters, so there is nothing to document. Per the rubric, 0 params warrants a baseline of 4. The description effectively communicates that the tool takes no inputs and serves as a self-contained reference, which is meaningful given no schema required. No parameter ambiguity exists to resolve.

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 'lists every supported strategy with its required and optional input fields,' which is a specific, concrete purpose. It distinguishes itself from sibling strategy-execution tools (analyze_deal, best_use, pull_comps, solve_max_offer, str_market_data) which are operations on strategies rather than metadata about them. The verb+resource+scope structure ('list... strategy... with fields') is exemplary.

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: 'Call this first when unsure which inputs a strategy needs.' This gives the agent a clear decision rule for when to invoke this tool versus alternatives, positioning it as a discovery/prerequisite tool before strategy execution. The 'Call this first' phrasing is particularly helpful.

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 add genuine value: discloses the API key/auth requirement, notes it consumes a monthly property-comp allowance (a cost/quota implication), and clarifies it returns licensed data. This is notably more transparent than an empty description would be; it surfaces cost and entitlement constraints the agent would otherwise not 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 sentences, dense with useful information and no filler. The key facts (what data, auth requirement, quota impact) are front-loaded. Could arguably be split for readability, but it's efficient and earns each clause.

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 moderately complex tool with 6 parameters, no output schema, and no annotations. The description meaningfully compensates: it names return types (sale comps, rental comps, ZIP stats), covers the auth/entitlement requirement, and flags the quota cost. For a data-fetching tool without an output schema, this is reasonably complete, though it could note error cases (e.g., invalid address, quota exhausted).

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 67%, with 3 params (zip, rentCount, saleCount) lacking descriptions while 3 (street, city, state) have them. The description top-line mentions the tool returns rental and sale comps and market stats, which loosely maps to the sales/rental count parameters, but doesn't add defaults or format details beyond schema. It adds some context but doesn't fully compensate for the uncovered parameters (particularly zip, which is unclear about format).

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 pulls 'REAL sale + rental comparables and market stats for a subject address from licensed data.' The verb 'pull' plus the specific resource (sale/rental comps, ZIP market stats) makes the purpose clear. It doesn't explicitly distinguish from siblings like str_market_data or analyze_deal, but the scope (comparables via licensed data) is fairly distinctive.

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

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

The description gives clear context: requires a REIzer API key (Investor plan or higher), counts against monthly property-comp allowance, and returns the data types. It doesn't explicitly state when-not-to-use or name alternatives, but the resource prerequisites and constraints are clearer than typical. Sibling tools like analyze_deal and str_market_data are not referenced as alternatives.

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

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

No annotations are provided, so the description carries the full burden and mostly delivers: it discloses output structure, defaults for targets (CoC 8%, DSCR 1.20, cash flow ≥ 0, flip margins), fraction format requirement, omitted-input defaults, and free/no-key status. However, it doesn't disclose whether inputs are validated, what happens on infeasible targets, or any side effects/limits. Notably it does describe the estimated_fields listing in assumptions, adding real behavioral context beyond schema.

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

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

The description is dense but packed with necessary operational detail — defaults, strategies, input handling, fraction format, output contents. It front-loads the primary purpose and returns the important info efficiently. Slightly long but every sentence carries information value, and no filler is present.

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

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

For a complex tool with nested objects (inputs), five strategies, default targets, and no output schema, the description covers the essential ground well. It explains what's returned, how inputs anchor price, how to override targets, and the fraction convention. Given no output schema exists, it would benefit from a bit more on the output/return shape and edge cases (e.g., infeasible targets), but it is largely complete for practical use.

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 67% — the targets and strategy params have descriptions, but the inputs object only says 'Deal inputs (price optional — arv/asking anchors the defaults)'. The description substantially compensates: it explains strategy enum choices, that price is optional, target override format, and the fraction convention. For the three parameters, the description adds meaning beyond the raw schema, especially for the fractional-rate convention and override syntax.

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 this tool reverse-solves the Maximum Allowable Offer — the highest purchase price meeting return targets. It names the returned outputs (MAO, binding constraint, per-target ceilings) and lists the five strategies, which distinguishes it from the sibling analyze_deal (which presumably analyzes at a given price) and best_use.

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 explicitly instructs to provide deal inputs WITHOUT committing to a price, using arv or asking price as reference — clear when-to-use guidance that differentiates it from analyze_deal. It also explains target overrides, default rate/percent fraction formatting, omitted-input defaults, and 'free, no key' availability. Though it doesn't name the specific alternative tool for priced analysis, the guidance is explicit enough.

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?

Despite no annotations, the description discloses that it counts against the account's monthly STR-comp allowance and requires a licensed data source and specific API key plan. This is strong behavioral context for a tool with zero 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?

A compact 3-sentence description that front-loads the core purpose, then adds key usage constraints. Every sentence carries information; no 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 5-param tool with low schema coverage and no output schema or annotations, the description covers the purpose, auth requirements, and data source but leaves gaps: no return format, no clarity on what the bedrooms/baths/guests filters do beyond the single default noted, and no mention of how many results are returned or how to interpret quartiles.

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 20% (only bedrooms has a description, and even that is minimal: 'Bedrooms filter (default 2)'). The description explains latitude/longitude as geocode prerequisites, but baths and guests get no elaboration at all. The description does explain the coordinate parameters' semantic role ('Needs coordinates — geocode the address first'), which adds value.

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+resource: 'Short-term-rental market data for a location' returning ADR/occupancy/revenue quartiles. It distinguishes itself from siblings like pull_comps and analyze_deal by being location-focused market data, though it doesn't explicitly name alternatives.

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

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

Explicitly states it 'Requires a REIzer API key (Investor plan or higher)' and that it 'Needs coordinates — geocode the address first.' This gives clear prerequisites but doesn't discuss when to prefer this over sibling tools like pull_comps for comps.

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