market-data

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

No annotations or output schema exist, so the description carries the full burden — and it does disclose the return contents (rent, vacancy, home value, population, renter share, income, employment) plus an important caveat that cap-rate is 'modeled' rather than observed, and that each row includes a doorbase.app link. It omits any error behavior, data freshness, or performance expectations.

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

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

Two sentences, front-loaded with the core purpose and followed by a dense metric list. The rhetorical opener ('How do these zip codes compare...') is slightly redundant with the second sentence but sets context efficiently.

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 annotations and no output schema, the description adequately compensates by enumerating returned metrics and flagging modeled data. It leaves minor gaps around data vintage and whether scores are computed or fetched, but nothing that would cause a mis-call.

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 single parameter is fully documented in the schema (2-6 five-digit US zips), and the description's '2-6 US zips' merely restates it. Baseline 3 applies when schema coverage is complete and the description adds no format or edge-case detail beyond it.

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 verb (compare) and resource (2-6 US zip codes as rental markets) and enumerates the exact metrics returned, so the agent knows precisely what it gets. It doesn't explicitly name a sibling like get_zip_market, but the multi-zip scope implicitly separates it from single-zip lookups.

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 phrase 'as rental markets' and the 2-6 range, which signals a multi-market screening scenario. However, it never states when to prefer this over get_zip_market or search_markets, nor any exclusions or prerequisites.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses that the cap-rate band is modeled and lists the returned data categories, but it does not describe permissions, data freshness, error behavior for invalid zips, or response structure.

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 core question and then compactly lists the profile contents. It is appropriately sized for a one-parameter lookup tool with no wasted language.

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 a good job enumerating the return categories and the canonical URL. It stops short of explaining response format, data sources, or error conditions, but it is sufficiently complete for an agent to understand what the tool returns.

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 the single zip parameter is already fully documented in the schema. The description adds no syntax or format detail beyond what the schema provides, making the baseline score 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 states a specific resource and scope: a full rental-market profile for a single US zip code, and it enumerates the included data categories. It is clearly distinguishable from multi-zip or trend-focused siblings by the 'single US zip' scope, though it does not explicitly name any alternative tool.

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

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

The implied use case is clear from the opening question and the single-zip scope, but the description gives no explicit when-to-use or when-not-to-use guidance. It does not mention compare_zips, rent_trend, search_markets, or top_markets 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?

With no annotations, the description carries the full behavioral burden and does so well: it discloses data provenance (NFDI claims, FEMA NRI, storm events) and explicitly flags the geographic mismatch that NRI scores are county-level, not ZIP-level. The 'claims are history, not a forecast' warning is exactly the kind of interpretive guardrail an agent needs. It stops short of saying what happens for ZIPs with no claim history or how fresh the data is.

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 question the tool answers, followed by a tight enumeration of returned data and a single closing caveat. Every sentence earns its place and nothing is repeated.

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 must convey the return shape, and it does: claim count, payouts, recency, claims per 1,000 housing units, three NRI peril scores, and storm events. The only gap is behavior for ZIPs lacking claims data or with no recorded events.

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 only one parameter and the schema already documents it at 100% coverage with a regex pattern for the 5-digit format. The description adds no format, validation, or edge-case guidance beyond what the schema provides, so the baseline of 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 definition names a specific resource (flood, wind and wind risk for a ZIP) and enumerates exactly what comes back: NFDI flood claims, FEMA National Resilience Index county scores, and recent significant storm events. That level of specificity clearly separates it from market-oriented siblings like get_zip_market and rent_trend.

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 phrasing implies the use case (a risk question about one ZIP), but it never says when to reach for this tool rather than compare_zips for a multi-ZIP comparison, nor does it state any preconditions. The closing caveat about claims being historical is useful framing but is not usage routing.

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

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

No annotations exist, so the description carries the full burden. It does disclose a genuinely useful behavioral trait — 'Updated monthly' — and spells out the returned metrics, which tells the agent this is a low-risk read with a defined payload. It omits data source, currency/units, rank methodology, and whether small zips are suppressed, which for an unannotated tool keeps it at a middling 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?

Two tightly packed sentences with no filler: the intent question comes first, then the payload breakdown. Slightly indirect as an opening versus a direct verb statement, but nothing is wasted and it is easy to scan.

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 two-parameter read tool with full schema coverage and no output schema, the description supplies enough: what is returned, what the metrics mean, and how fresh the data is. Remaining gaps (units, rank methodology, behavior on invalid zip) are minor at this complexity level.

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%, covering both zip (5-digit pattern) and months (2-24, default 12), so the baseline is 3. The description's mention of '3-month rent growth' ranking hints at a window different from the months parameter, but it never clarifies how months interacts with the reported history or the rank window.

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 (monthly median-rent history for a zip) and enumerates what comes back: home values, direction of movement, and national/state rank on 3-month rent growth. That is far more concrete than the title alone. It does not, however, distinguish itself from the overlapping sibling get_zip_market, so an agent must infer the boundary.

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 opening question frames the use case (you want to know which direction rent is moving), which implies when to call it. There is no explicit when-not guidance and get_zip_market / compare_zips are never mentioned, even though they plausibly overlap on zip-level rent data.

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 load and does well: it discloses the return payload (matching zips, key investor metrics, a doorbase.app link each) and flags an important behavioral caveat that cap rates are a modeled band. It omits auth/rate-limit/pagination behavior (the limit cap of 25 is only in schema), 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?

Three tight sentences with the core question and return shape front-loaded; little waste. The question-style opener is slightly less direct than a declarative verb, but it 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?

For a 10-parameter, no-annotation, no-output-schema tool, the description covers purpose, return contents, and the key cap-rate caveat. It could say more about sorting/limit behavior, but nothing essential is missing 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 coverage is 80%, so the baseline is 3; the description adds real meaning by explaining that cap rates are a modeled band and min_cap_rate matches the band's high end, which the schema states mechanically but does not explain as modeled. It also enumerates the filter dimensions available.

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

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

Opens with a specific framing ('Which US zip codes match these rental-market criteria?') and names the exact resource (30,000+ US zip codes) plus the filterable dimensions. This clearly sets it apart from siblings like get_zip_market (single zip), compare_zips, and top_markets.

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 implies a filter-based search but never states when to use this versus top_markets or compare_zips, nor any exclusions. The only usage hint ('Omit for nationwide') lives in the schema, not the description.

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 inclusion criteria and the important caveat that cap rates are a modeled band, not observed data. However, it never states that results are truncated to a top-N list (capped at 25), that no parameters are required, or anything about read-only/error 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?

Two tightly packed sentences with no filler; the eligibility criteria and modeling caveat are front-loaded. The opening rhetorical question ('Which US rental markets look strongest right now?') adds flavor but little information beyond the sentence that follows.

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 small, no-required-parameter read tool this covers the essentials — what is ranked, on what basis, and with what data-quality gate. It still leaves the agent guessing about sort direction, how many rows come back, and which fields each zip entry contains, none of which is supplied by an output schema.

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

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

Schema coverage is 50% — the state parameter is already documented as an optional 2-letter code, and the description only restates that scope ('national (or single-state)'). The limit parameter is never mentioned in the description, so the agent gets no guidance that this controls leaderboard depth.

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 leaderboard of US zips ranked by estimated cap-rate band) and states the eligibility filters (population 10,000+, complete rent/vacancy/home-value data, national or single-state scope). It is clearly distinguishable from get_zip_market or compare_zips by its ranking/screening nature, though it never names those siblings explicitly.

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 'national or single-state' framing implies when this tool fits, but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as search_markets for arbitrary filtering or compare_zips for side-by-side comparison. Usage must be inferred from the description of the output.

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