CRE Intelligence

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

No annotations exist, so the description carries full burden. It lists return content but does not disclose behavioral traits like read-only nature, authentication needs, or limitations (e.g., PDF format only).

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. The first sentence front-loads the purpose, and the second details return items. Highly 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?

With an output schema (indicated by context signals), the description need not explain return values, yet it lists them anyway for clarity. The tool has a single parameter and no nested objects, so the description adequately covers most context. Could mention handling of multi-page documents.

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% and already describes the 'text' parameter. The description adds the context 'raw text copied from a commercial lease PDF', which is mildly helpful but does not significantly enhance understanding 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 uses a specific verb ('Extract') and resource ('commercial lease document'), and lists the specific terms extracted, clearly distinguishing it from sibling tools like flag_lease_risks.

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 use for lease abstraction but provides no explicit guidance on when to use it versus alternatives like flag_lease_risks or generate_deal_memo, nor when not to use it.

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 burden. It describes the tool as extracting structured data (safe, read-only) but does not disclose error behavior, rate limits, or what happens if the input is not a rent roll. Adequate but not rich.

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 an appended list of return values. Purpose is front-loaded. Every sentence earns its place – no filler. Very concise and 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?

An output schema exists (not shown but stated), so description need not detail return format. It lists key outputs (tenant list, suite/SF, etc.) which is sufficient. Could mention input format expectations, but overall complete for a data extraction 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 100% – both 'text' and 'property_name' have schema descriptions. The tool description adds marginal value: it reiterates the paste instruction and context for property_name. Baseline 3 is appropriate as schema already documents the parameters adequately.

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 'Extract structured tenant and lease data from a rent roll document' – a specific verb and resource. It lists extracted data (tenant list, suite/SF, lease dates, etc.), and no sibling tool duplicates this function.

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 instructs to paste text from a rent roll PDF. This tells how to use it, but does not mention when not to use it or alternatives among siblings (e.g., abstract_lease). Still, the instruction is clear and actionable.

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 full burden. It discloses automatic fetching of SOFR if loan_rate is not provided, and lists return values. This is good but doesn't cover all behavioral aspects like potential reliance on external data.

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 focused sentences: one for purpose, one for outputs. No wasted words, front-loaded with key action. Very concise 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?

Given the complexity (8 parameters, output schema exists), the description adequately explains the core function and automatic behavior. It doesn't need to detail returns since output schema covers that.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context about automatic rate fetching, but this is already in the schema's loan_rate description. No new param semantics beyond 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 builds a levered DCF model using live Federal Reserve rates, with a specific verb and resource. It distinguishes itself from siblings like export_dcf_excel (export) and get_current_rates (just 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?

No explicit guidance on when to use versus alternatives. The description implies its purpose but doesn't mention when not to use it or suggest siblings like get_current_rates for rates-only tasks.

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 full burden. It discloses key behavioral traits: the Excel contains live formulas, the download link is valid for 60 minutes, and a demographics sheet is conditionally added. However, it does not mention potential errors, size limits, or rate limits, which would improve transparency.

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 a single dense sentence that efficiently conveys the tool's purpose and key features. It is front-loaded with the primary action ('Generate a downloadable Excel ...') and wastes no 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 (10 parameters, output schema exists), the description covers the main functionality and output characteristics. It could mention error conditions or limitations, but overall it provides sufficient context for an agent to understand what the tool produces.

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%, and the schema already describes each parameter adequately. The tool description adds overarching context (e.g., demographics sheet for address) but does not significantly enhance individual parameter semantics beyond what the schema provides.

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 generates a downloadable Excel underwriting model with live formulas, listing specific features like PMT/FV amortization, IRR, sensitivity grid, etc. It distinguishes from siblings like build_dcf_model by emphasizing the export and downloadable nature.

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 use when an Excel export is needed but does not explicitly state when to use this tool over alternatives (e.g., build_dcf_model), nor does it provide when-not-to-use guidance. Usage context is implied but not fully clarified.

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 discloses the tool analyzes risks and returns structured output, implying a read-only operation. However, it does not detail potential side effects, permissions, or whether the analysis is deterministic or involves external calls. This is adequate but not thorough.

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 long, front-loaded with purpose, followed by a usage instruction, then output summary. Every sentence adds value with 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 a single simple parameter, high schema coverage, and an output schema (assumed to exist), the description adequately covers input source and output contents. No additional context is needed for correct tool 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?

There is one parameter (rent_roll_json) with schema description coverage at 100%. The description in the tool repeats that it expects JSON from analyze_rent_roll, which matches the schema. No additional semantics beyond the schema are provided, so a baseline 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 clearly states it analyzes a parsed rent roll for investment risks, and explicitly names the expected input source (analyze_rent_roll output). It lists specific risk categories returned (rollover, concentration, credit, recommendations), distinguishing it from sibling tools like analyze_rent_roll which parses, and others like build_dcf_model or generate_deal_memo.

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 the agent to feed the output from analyze_rent_roll directly into this tool, providing clear guidance on when to use it. It does not mention when not to use or list alternatives, but the context is sufficient for correct invocation.

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 discloses that live data is pulled from FRED and Census Bureau, adding transparency. However, it does not mention side effects like data saving or auth requirements, though for a memo generator these are likely minimal.

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-loaded with purpose and followed by a key behavioral trait. Every word earns its place; no 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 the complexity of 6 parameters and an output schema, the description covers the main purpose and data sources. It does not explain prerequisites like needing rent roll data, but the schema hints at optional inputs from sibling tools.

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 baseline is 3. The description does not add meaning beyond what the schema provides, except indirectly noting that property address and type relate to data pulls from external sources.

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 generates a formatted CRE acquisition/Investment Committee memo, which is a specific and distinct resource. It differentiates from sibling tools like analyze_rent_roll or build_dcf_model by being the final memo output.

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 memo generation but does not explicitly state when to use versus siblings. Context from sibling list helps, but no exclusions or alternative tool references are 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?

No annotations are provided, so the description carries full burden. It discloses the kind of data returned but does not mention read-only nature, latency, authentication, or rate limits. For a read-only data tool, this is acceptable but not exhaustive.

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 with three sentences, no wasted words, and front-loaded with the main action: 'Get Commercial Real Estate price index and broader market data.'

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 fully covers the tool's purpose, output data types, and usage context. Given the tool has no parameters and an output schema exists, it provides sufficient completeness.

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 no parameters, so the description does not need to elaborate. Schema coverage is trivially 100%, and the baseline for zero parameters is 4.

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 retrieves Commercial Real Estate market data from the Federal Reserve, listing specific data types like price trends, vacancy proxies, and credit spreads. This distinguishes it from siblings like get_current_rates and get_inflation_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 mentions providing macro context for deal underwriting and cap rate analysis, implying usage scenarios. However, it does not explicitly state when to use this tool over alternatives or when not to use it.

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 description must carry full burden. It doesn't explicitly state this is a read-only operation or discuss side effects, authentication needs, or data freshness. The description adds value by explaining what returns, but lacks explicit safety or behavioral disclosures.

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 purpose, then outputs, then usage advice. No fluff, 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 parameters and presence of output schema, the description adequately explains the return values and usage context. It could detail update frequency, but for a simple getter it's sufficiently 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 parameters and 100% schema coverage, the description adds no parameter info but doesn't need to. Baseline for 0 params is 4. The description focuses on output, which 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 clearly states the tool gets live interest rates from the Federal Reserve (FRED), listing specific rates and mentioning cap rate calculation. This distinguishes it from siblings like 'get_cre_market_data' or 'get_inflation_data' which cover different domains.

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 says to use it 'BEFORE any DCF model or loan underwriting', providing clear context. It also notes these are real-time numbers Claude cannot access, but doesn't mention when not to use it or give 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 provided, so description carries the burden. It implies a read-only operation by describing returned data, but does not disclose potential latency, data source limitations, or any side effects. Adequate but not exhaustive.

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, zero wasted words. Front-loaded with purpose, then specifics, then use case. 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 parameters and presence of an output schema, the description fully covers what the tool does and why to use it. No missing information for this simple 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?

No parameters exist, and schema coverage is 100%. The description adds no parameter information, which is appropriate. Baseline of 4 for zero 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?

Clear verb 'Get', specific resource 'CPI and rent inflation data from the Federal Reserve', and explicit outputs (overall inflation, shelter inflation, rent-specific CPI with YoY changes). Distinguishes from siblings like get_cre_market_data by focusing on inflation.

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?

Explicit recommendation to use for calibrating rent growth assumptions in DCF models, with a strong directive 'don't guess'. While it doesn't list alternatives or exclusions, the context is clear and actionable.

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 provided, so description carries burden. It notes the data is 'address-specific from actual Census tract — not estimates', indicating precision and reliability. Also mentions that Claude cannot access without MCP, setting expectations. No negative behavioral traits omitted.

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

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

Five sentences, each valuable: action, return fields, non-estimate claim, access limitation, alternative tool. 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 simple one-param tool with output schema, description covers action, return fields, data source, and provides alternative. Adequate for agent to invoke 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 100% with description for 'address'. The tool description adds no extra info about the parameter beyond what schema provides ('Full US property address'). Baseline 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?

Description clearly states 'Get Census Bureau demographics for any US property address' and lists returned fields. It explicitly distinguishes from sibling get_radius_demographics by advising to use that for trade-area rings.

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?

Provides explicit alternative tool (get_radius_demographics) for different use cases, and states the tool's limitation ('Claude cannot access this without MCP'). Lacks explicit 'when to use' statement, but purpose implies it.

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 provided, so description carries full burden. It explains the aggregation method (census tracts whose centroid falls within each radius) and lists the demographic metrics. Could mention US-only limitation or data availability, but overall transparent.

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 focused sentences: purpose, details, and usage alternative. No wasted words, well-organized.

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?

Input parameters are clearly covered. The output schema exists (not shown), so detailed return documentation is not needed, but description still lists the metrics. Usage context and alternatives are provided. Complete for decision-making.

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 clear descriptions of address and radii_miles. The description does not add new parameter semantics beyond what the schema already provides, though it gives helpful context about the aggregation logic. Baseline 3 is appropriate.

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

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

Clearly states the tool gets aggregated Census demographics for radius rings around a US property address. Specifically mentions the standard 1/3/5-mile trade-area format and lists the metrics returned, distinguishing it from the sibling get_market_demographics.

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 tells when to use this tool (trade-area/site analysis) and when not to, with a direct alternative: 'Use get_market_demographics for the single census tract immediately around the address.'

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 fully carries the burden. It discloses the tool uses only free Census data, grades on specific signals, and lacks actual sale prices. It clearly states the limitations and that results must be verified before buying. 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 well-structured with two paragraphs: purpose first, then caveats. It is front-loaded with the core action. Could be slightly more concise but is not overly verbose.

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?

Has output schema and 100% parameter coverage. The description explains the grading signals and warns about data limitations, providing sufficient context for an agent to understand the tool's capabilities and limitations. Minor gap: does not explicitly list output fields, but output schema exists.

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?

Input schema has 100% coverage with clear descriptions for 'state' and 'county'. The description does not add extra parameter-level meaning beyond what the schema provides, which is acceptable given the high schema coverage. Baseline 3 is appropriate.

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

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

The description clearly states the tool screens a US county as a land-investing market, specifies the style (raw-land flip / Podolsky), and lists the signals used (population growth, demographics, etc.). It distinguishes from sibling tools like 'screen_parcel_dd' and 'get_cre_market_data' by focusing on county-level land market screening.

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 when to use (to rank/shortlist markets) and what it does NOT include (actual land sale prices, comps). It warns that per-parcel verification is needed and that data is from free Census sources only. This provides clear guidance on appropriate use and limitations.

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 transparently discloses the data sources (FEMA NFHL and USFWS NWI), the limited scope (flood + wetlands only), and the implications of the check. There are no contradictions or missing behavioral cues.

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 well-structured with a clear purpose statement, usage instructions, and important caveats. It is front-loaded and each sentence adds value. Slightly verbose with emphasis (all-caps) but not detrimental.

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 that an output schema exists (stated), the description covers all necessary context: inputs, data sources, scope, limitations, and usage guidance. It is sufficiently complete for an agent to understand the tool's role in the workflow.

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 input schema has 100% description coverage (lat, lng with 'decimal degrees'). The description adds context that these are parcel coordinates but does not provide additional constraints or format details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Pre-screen a land parcel's location for the AUTOMATABLE due-diligence red flags: FEMA flood zone and federal wetlands.' It uses a specific verb ('pre-screen') and identifies the exact resource (land parcel) and checks. It also differentiates from sibling tool 'screen_land_market' by focusing on flood/wetlands due diligence.

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?

Explicit usage guidance is provided: 'Use this to kill obviously-bad parcels at scale BEFORE spending time on manual due diligence.' It also clearly states what the tool does NOT cover (legal access, title/liens, zoning) and emphasizes that a clean screen is necessary but not sufficient.

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