Stratalize Real Estate

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

Annotations already indicate safe read behavior. The description adds value by specifying the data source (CBRE and JLL quarterly surveys), implying data freshness and authority. It does not mention output format or limits, but annotations lower the bar for behavioral disclosure.

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 concise sentences with no wasted words. First sentence states the core functionality, second adds source credibility, third identifies target users. Front-loaded and efficient.

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?

The tool has no output schema, but the description does not explain return values. However, given the tool name and sibling context (all benchmarks), agents likely infer a single value or range. Input parameters are well covered with enums, making the description nearly complete for a simple retrieval tool.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by mapping parameters to the phrase 'by asset class, market tier, and geography,' covering all three parameters. While it does not provide additional syntax or examples, it adequately conveys the role of each parameter.

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 retrieves cap rate benchmarks by asset class, market tier, and geography. It distinguishes from sibling tools like get_construction_cost_benchmark by specifically focusing on cap rates, and the naming convention reinforces the purpose.

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 mentions the tool is 'used by CRE acquisition teams, asset managers, and real estate CFOs for property pricing and portfolio valuation,' providing context on when to use it. However, it does not explicitly differentiate from alternatives like get_cre_debt_benchmark or get_ncreif_return_benchmark, leaving some inference to the agent.

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?

The description adds significant behavioral context beyond annotations: it details the six perils, data sources (NOAA, FEMA, USGS), and an example output. This complements the readOnlyHint and destructiveHint annotations without contradiction.

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 concise, front-loaded with purpose, and efficiently includes use cases, peril details, data sources, and an illustrative example. Every sentence adds value without redundancy.

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 tool's complexity (composite risk across multiple perils), the description fully explains its output, data sources, and typical use. No output schema exists, but the description provides sufficient context 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?

The single parameter 'location' is described in the schema as 'US city and state', with 100% coverage. The description includes an example ('Miami-Dade FL'), which adds marginal clarity but does not substantially increase meaning beyond the schema.

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

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

The description explicitly states the tool's purpose: pricing physical climate risk for a location, with specific use cases (acquisition, underwriting, site selection, disclosure) and details about the composite risk score across six perils. This clearly distinguishes it from sibling tools, which cover diverse benchmarks and intelligence.

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 starts with 'Use when pricing physical climate risk for a location', providing clear usage context. While it doesn't explicitly state when not to use it or list alternatives, the use cases are specific and the tool's scope is well-defined.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to reiterate safety. It adds value by detailing what the tool returns (costs, ratios) and sources, but does not disclose additional behaviors like pagination or response format.

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 single, well-structured sentence conveys scope, outputs, sources, and audience without redundancy. Every element is relevant and front-loaded.

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 tool's complexity (multiple cost components) and lack of output schema, the description fairly outlines what is returned and sources. It could be more complete by hinting at output format (e.g., ranges or structured data), but is sufficient for an agent to understand the tool's purpose.

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 compensate. It mentions 'by building type and region', addressing the 'building_type' and 'region' parameters, but does not explain the 'construction_class' parameter (likely cost tier). This partial coverage provides some meaning but not complete for all three parameters.

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 explicitly states it provides construction cost benchmarks with specific outputs (hard cost per SF, soft cost ratios, contingency standards, material escalation) and names authoritative sources, clearly differentiating from sibling tools like get_cap_rate_benchmark or get_cre_debt_benchmark.

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?

Description implies usage for construction cost data but lacks explicit guidance on when to prefer this tool over alternatives or any exclusions. The sibling tools are distinct in topic, so context is clear, but no direct comparison is given.

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

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

Annotations already indicate read-only and non-destructive. Description adds data sources and output fields, providing useful behavioral context beyond 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?

Two sentences plus a source line: efficient, front-loaded with purpose and filtering, no wasted words.

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?

Covers purpose, filtering, data sources, and audience. Lacks detail on output format, but acceptable given no 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 has 0% parameter description coverage. The description only mentions the parameters in passing without explaining enum values or usage meaning, failing to compensate for the schema gap.

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

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

The description clearly states the tool provides CRE debt benchmarks (DSCR, LTV, spreads) filtered by property and lender type, with data sources and audience. It distinguishes itself from siblings like get_cap_rate_benchmark.

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?

Implies usage for CRE CFOs and capital markets teams. No exclusions or alternatives mentioned, but context from siblings makes it clear this is for debt benchmarks.

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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds minor context about data sources (NAHB, ULI, industry composite) but does not reveal additional behavioral traits 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?

The description is short (three sentences) and front-loaded with the tool's purpose. Every sentence adds value: the first lists outputs, the second gives usage context, the third cites sources. No wasted words.

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 tool's complexity, the presence of readOnlyHint, and no output schema, the description adequately conveys the metrics and usage. It misses the market_tier parameter but covers most essential context for a benchmark tool.

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

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

With 0% schema description coverage, the description must clarify parameters. It only mentions 'by product type,' which corresponds to the product_type parameter. The market_tier parameter is entirely ignored, leaving agents confused about its purpose and allowed values.

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 identifies the tool as providing development pro forma benchmarks including specific metrics like yield on cost, profit-on-cost, and construction-to-perm spread. It distinguishes itself from sibling tools (e.g., get_cap_rate_benchmark, get_construction_cost_benchmark) by focusing on development pro forma.

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 states the intended users and use cases: 'For developers underwriting new projects and lenders sizing construction loans.' This provides clear guidance on when to use the tool, though it does not mention when not to use it or alternative 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 declare readOnlyHint=true; description adds context about data being 'live' and its purpose as a leading indicator, no contradictions.

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 with no wasted words; key information (live data, source, use cases) is front-loaded.

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

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

No output schema, so description should hint at return format. It lists indicators (starts, permits, etc.) but does not explain what the tool returns (e.g., time series, table). For a simple tool with two enum params, it is adequate but could be more 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?

With 0% schema description coverage, the description should explain parameters like region and structure_type. It mentions 'by market tier' but does not clarify which parameter that maps to or provide detailed meaning beyond enum 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?

Description clearly states specific verb ('get'), resource ('housing supply indicators'), and data sources ('FRED and Census'), and distinguishes from siblings like cap rates or construction costs.

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?

Identifies target audiences (developers, lenders, investors, policy analysts) but does not explicitly state when not to use or compare to alternative sibling 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that the data is free and from HUD's annual dataset, but does not disclose details like update frequency, rate limits, or return format. With annotations providing the core safety info, a 3 is appropriate.

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

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

Two concise sentences, front-loaded with purpose and use cases. No wasted words; every sentence adds value.

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?

The tool is simple with two parameters and no output schema. The description covers source, cost, and use cases, but omits details about the return format (e.g., monthly rent values per bedroom). For a straightforward query, this is adequate but not thorough, hence a 3.

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% (metro_area has a description, bedroom_count does not). The description does not add meaning beyond the schema's parameter definitions. Given moderate coverage and no elaboration, a baseline score of 3 is justified.

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?

Clearly states it provides HUD Fair Market Rents by metro area and bedroom count. The description includes specific use cases (affordable housing underwriting, Section 8, LIHTC) which distinguishes it from siblings that cover climate, disaster, or weather data.

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

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

Explicitly lists usage scenarios like affordable housing underwriting and compliance. Does not provide negative guidance or mention alternatives, but the context is sufficiently specific for selection among dissimilar sibling 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 declare readOnly and non-destructive. Description adds useful context: data source (FRED weekly survey), update frequency (weekly), and specific benchmarks. No contradictions.

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 key information (what is provided), followed by audience and update frequency. No redundant or unnecessary text.

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?

Lacks explanation of how optional parameters change results. No output schema or description of return format. Missing details on error cases or data limitations. For a tool with optional inputs, more context is needed.

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 has 0% description coverage and the description does not explain the 'state' and 'loan_type' parameters. Agent has no guidance on how these optional parameters affect the output.

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?

Clearly states it provides live mortgage rate benchmarks including specific types (30Y, 15Y fixed, ARM spreads, etc.) and target audience. Distinguishes from sibling tools by focusing on mortgage market.

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?

Implied usage context (homebuyers, lenders, etc.) but no explicit when-to-use or when-not-to-use compared to sibling tools like get_cap_rate_benchmark. Lacks alternatives or exclusions.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that data comes from NCREIF quarterly public data, which is useful context about the source and currency, but does not disclose additional behavioral traits beyond what annotations 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 three concise sentences, front-loaded with the core purpose. Every sentence contributes essential information about the tool's output, audience, and data source, with no redundancy.

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 tool has three optional parameters and no output schema, the description adequately explains the tool's purpose and target audience. It mentions the return components but lacks details on how parameters filter results or the exact response format. Still, it is fairly complete for a benchmark query tool.

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

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

Schema description coverage is 0%, so the description does not explain parameters beyond their enum names in the schema. The parameter names (period, region, property_type) are self-explanatory, but the description could have clarified that it returns multiple return components (total, income, appreciation) without a parameter for that. Thus, it adds marginal 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 tool provides NCREIF Property Index institutional return benchmarks, specifying total returns, income returns, and appreciation by property type and region. It distinguishes from sibling benchmarks by emphasizing its role as the standard for institutional real estate portfolios.

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 advises that this tool is for pension funds, endowments, and institutional asset managers, indicating when to use it. However, it does not explicitly contrast with sibling tools or provide when-not-to-use guidance, though the context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that the tool returns annual data with historical context and trend acceleration. However, it omits details on rate limits, data freshness, or pagination, which are beyond annotations but would add value.

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 verbose with multiple sentences and includes credibility statements (e.g., 'Cited by the Federal Reserve'). It is front-loaded with usage context but could be more concise 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?

Given no output schema, the description explains the output includes event count, total losses, deaths, and historical trend, with a concrete example for 2023. For a tool with one optional parameter, this is mostly complete, though it could clarify the exact output structure.

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 partially compensates by mentioning year in the example (2023). It implies the parameter controls which year's data, but does not explicitly state the format or valid range. Baseline of 3 is appropriate given the single required parameter is optional with a default.

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 returns NOAA's annual billion-dollar disaster economics data, including event count, total losses, deaths, and historical trend acceleration. This specific verb-resource pairing distinguishes it from sibling tools like get_storm_event_history or get_climate_risk_score.

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

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

The description explicitly enumerates use cases: ESG reporting, reinsurance negotiations, infrastructure decisions, and SEC/TCFD disclosures. It implies when to use but does not explicitly name alternatives or state when not to use, leaving room for improvement.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds data sources and target users but does not disclose additional behavioral traits such as rate limits, data freshness, or side effects. Since annotations cover the key behavioral constraint, a score of 3 is appropriate.

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

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

The description is three sentences, front-loaded with the core output, then sources, then target users. Every sentence adds value, no redundancy or unnecessary words.

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?

The description covers what metrics are returned, data sources, and intended audience. Without an output schema, it could provide more detail on the return format (e.g., structure of results, units). However, for a read-only benchmark tool with two parameters, it is largely 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 has 0% description coverage for parameters. The description mentions 'by property type' for one parameter (property_type) but does not describe the market_tier parameter or any parameter details (e.g., allowed values explained, default behavior). The description fails to add meaning beyond the schema's enum values.

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 specifies the tool returns property operating benchmarks (OpEx per SF, NOI margins, occupancy rates) by property type, with named data sources. It distinguishes from sibling tools like get_cap_rate_benchmark and get_ncreif_return_benchmark by focusing on operational metrics.

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 indicates target users (asset managers, etc.) but does not explicitly state when to use this tool over alternatives like get_cap_rate_benchmark or get_rental_market_benchmark. Usage guidance is implied through the metrics and sources, but no direct 'when to use' or 'when not to use' instructions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds supplementary behavioral context by identifying the data source (Lincoln Institute) and the types of data provided, which aids trust and understanding without contradicting 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 with no redundancy. The first sentence front-loads the core purpose, the second adds source credibility, and the third provides context and audience. Every sentence 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?

With 2 parameters and no output schema, the description adequately covers what the tool returns (effective tax rates, assessment ratios, appeal success rates) and its source. Could optionally mention data year or limitations, but currently sufficient for a simple lookup tool.

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

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

Schema coverage is 50% (state has description, property_type only enum). The description mentions 'by state and property type', linking parameters to tool functionality, but does not elaborate on parameter details or defaults. This adds some meaning beyond schema but not full compensation for undocumented property_type.

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 provides property tax benchmarks including effective tax rates, assessment ratios, and appeal success rates, filtered by state and property type. It names the data source (Lincoln Institute) and target audience, distinguishing it from sibling tools that cover other real estate benchmarks.

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 specifies the intended users (property owners, asset managers, acquisition teams) and provides context that property tax is a large controllable expense, implying when to use it. However, it does not explicitly state when not to use or offer alternatives to sibling 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 declare readOnlyHint true. Description adds specific data sources (FRED, CMBS), components (maturity wall, cap rates), and update frequency (quarterly). No contradiction with 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, no redundant words. Front-loaded with the core value proposition. Every sentence 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?

Given no output schema, the description adequately explains what the tool returns (delinquency rates, maturity wall, cap rates) and update frequency. Sufficient for an agent to understand outcomes.

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 has 0% description coverage for parameters. Description mentions 'by property type' and 'stressed cap rate scenarios' which hint at the two parameters but does not explicitly map or explain valid values. Adds some meaning but incomplete.

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?

Clearly states it provides CRE debt stress benchmarks including live delinquency rate, CMBS delinquency by property type, maturity wall exposure, and stressed cap rate scenarios. Distinguishes from sibling get_cre_debt_benchmark by focusing on stress.

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?

Lists target audience (lenders, special servicers, distressed investors, regulators) which implies context. Does not explicitly state when to use this vs alternatives, but the 'stress' focus provides implicit guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds behavioral context by naming the data source ('NAREIT public monthly data') and listing the specific metrics returned. However, it does not disclose potential limitations like data recency, pagination, or rate limits.

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

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

The description is two sentences, front-loading the key benchmarks and then providing source and audience. Every part is relevant and non-redundant. It is concise without being under-specified.

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 there is no output schema, the description should indicate the return format (e.g., structure of results, units, time period). It does not. While the parameter is simple (a single enum), the lack of output specification leaves the agent uncertain about what to expect after invocation. The description is incomplete for a data retrieval tool.

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

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

Schema coverage is 0% (no description in the parameter schema), so the description must compensate. It mentions 'property sector' in the overview but does not elaborate on the enum values or how to choose a sector. The enum values (e.g., 'multifamily', 'office') are somewhat self-explanatory, but the description could add meaning by noting that 'all_equity' is a composite or that data availability may vary by sector.

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 it provides 'REIT valuation and performance benchmarks' including specific metrics like FFO multiples, AFFO multiples, dividend yields, NAV premium/discount, and total returns by property sector. This distinguishes it from sibling tools that focus on other real estate benchmarks (e.g., cap rates, construction costs, mortgage rates).

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 mentions the target audience ('For REIT analysts, portfolio managers, and IR teams') and states 'Free,' implying usage context. However, it does not explicitly state when to use this tool versus alternative sibling tools (e.g., get_cap_rate_benchmark, get_ncreif_return_benchmark) or give any 'when not to use' guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the list of data points and sources but does not disclose behavioral traits like data freshness, pagination, or rate limits. With annotations covering safety, a 3 is appropriate.

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

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

The description is concise (3 sentences) and front-loaded with the main purpose. It includes necessary context about sources and audience. Minor redundancy in the sentence listing data points could be streamlined.

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

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

No output schema is provided, and the description does not explain the return format or structure. For a benchmark tool, this is a significant gap. Additionally, parameter semantics are missing, making the description incomplete for an AI agent to fully utilize the tool.

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

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

Schema description coverage is 0%, so the description must compensate. However, it does not explain the two parameters ('unit_type' and 'market_tier') beyond what the enum values suggest. The description adds no additional meaning to the input schema.

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

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

The description clearly states the tool provides rental market benchmarks including asking rents, vacancy rates, rent growth, and rent-to-income ratios, with specific data sources. This distinguishes it from sibling tools like get_hud_fair_market_rent or get_residential_market_benchmark.

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 mentions target users (landlords, investors, property managers) but does not explicitly state when to use this tool versus alternatives or provide exclusions. The usage context is implied but not detailed.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by naming data sources (FHFA HPI, FRED, Census) and the target audience. No contradictions with 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 two sentences: the first lists the metrics provided, the second gives sources and audience. It is front-loaded with the purpose and contains no unnecessary words.

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 tool's complexity (multiple metrics, enums, no output schema, many siblings), the description covers the purpose and sources but misses parameter semantics and explicit usage guidelines. It is adequate but has 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?

With schema description coverage at 0%, the description should compensate by explaining the parameters 'market_tier' and 'property_type'. It mentions 'by market tier' but does not define the enum values or describe property_type. No parameter information is provided.

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 provides residential real estate market benchmarks with specific metrics (home price indices, price-to-rent ratios, etc.) and data sources. It distinguishes from siblings by focusing on residential market benchmarks, as opposed to cap rates, rental markets, or other real estate metrics.

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 usage for residential investors, agents, developers, and housing analysts but does not explicitly state when to use this tool vs alternatives like get_cap_rate_benchmark or get_rental_market_benchmark. No when-not or exclusion criteria are provided.

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 indicate readOnlyHint=true and destructiveHint=false. The description adds valuable context: the data source (NOAA), authoritative recognition (reinsurers, Federal Reserve, SEC), and the output structure (event frequency, losses, deaths, trend). No contradictions with 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 concise and front-loaded with use cases. Every sentence adds value: use cases, what it returns, an example, and the source. No redundancy or fluff.

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 only 2 simple parameters and no output schema, the description sufficiently explains the output metrics and provides an illustrative example. It covers the key information an agent needs to invoke the tool correctly.

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

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

Schema coverage is 50% (state described, years_back not). The description adds the example 'Texas 10-year history' and implies default behavior, but does not provide explicit format or constraints for years_back beyond the schema default. Baseline adjusted for low coverage, but description provides some context.

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 returns NOAA's tally of billion-dollar weather disasters with specific metrics (frequency, losses, deaths, trend). It specifies the resource and action precisely, and the context of use cases distinguishes it from general sibling tools like get_noaa_disaster_economics.

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 first sentence explicitly lists specific use cases (insurance underwriting, real estate due diligence, ESG disclosures, board briefings). While it doesn't explicitly say when not to use or name alternatives, the context is well-defined and implies appropriate scenarios.

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 indicate readOnlyHint=true and destructiveHint=false. The description adds value beyond annotations by detailing pricing tiers, authentication requirements, and the tool's role as a discovery gateway. No contradictions.

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 'START HERE' and conveys purpose, content, and pricing in a few sentences. It is slightly dense with parenthetical pricing details, but overall efficient and well-structured.

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 catalog tool with no parameters or output schema, the description fully covers what the tool does, how to use it, and its behavioral traits (read-only, auth modes). It is complete for the tool's purpose.

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 are zero parameters, and the schema coverage is 100% by default. The description does not need to explain parameters, and the baseline for 0 parameters is 4. No additional parameter info is necessary.

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 that this tool returns a 'complete Stratalize tool catalog' across multiple domains. It specifies the tool as a starting point ('START HERE') and distinguishes it from sibling tools that focus on specific data queries.

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 directs agents to 'Call this first to discover tools by role or vertical.' It also covers different access models (public, x402, OAuth). However, it does not explicitly state when not to use this tool, though the context makes it clear.

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 indicate readOnlyHint: true and destructiveHint: false. The description adds that it uses official NOAA data and specifies thresholds (precipitation probability, wind >25 mph, freeze <32°F). It also states the output includes risk tier and high-risk days. This adds context beyond annotations without contradicting them.

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 concise: three sentences plus an example and source citation. It is front-loaded with use cases and purpose, then explains analysis, provides a concrete example, and cites the data source. No wasted words.

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?

Despite lacking an output schema, the description fully covers the return value ('risk tier and specific high-risk days') and provides an illustrative example. It addresses the simple input format, data source, and typical use case, making the tool's behavior complete for an AI agent.

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% with a description for 'location' (US city/state or address). The description reinforces this with examples ('Chicago IL', '1600 Pennsylvania Ave') but does not add significant new meaning beyond the schema baseline. Hence a score of 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 explicitly states the tool analyzes NOAA 7-day forecast data against construction delay thresholds (precipitation, high wind, freeze) and returns a risk tier with high-risk days. It distinguishes itself from siblings by being specific to US outdoor construction weather risk, using clear verb 'Analyzes...returning' and resource 'NOAA 7-day forecast data'.

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

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

The description provides explicit use cases: 'when scheduling outdoor construction work, planning equipment deployment, or assessing weather risk for any US project site' and includes an example with actions like 'Reschedule concrete pours and crane operations.' It does not explicitly state when not to use or compare to alternatives, but the context makes usage clear.

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