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

With no annotations provided, the description fully carries the burden. It discloses all outputs, data sources (California Apartment Association ordinance chart, AB-1482), and how key parameters are used (e.g., year_built for Costa-Hawkins filters). It does not explicitly mention side effects or error handling, but the behavior is well-covered for an underwriting tool.

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 lengthy but front-loaded with a clear purpose. Every sentence adds value by detailing outputs or usage. While it could be more structured (e.g., bullet points), it is not excessive given the complexity of the tool (30 parameters, no output schema).

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

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

Despite having 30 parameters and no output schema, the description is remarkably complete. It explains all return values (financials, regulatory resolution with specific fields, projection, drag summary, verdict with reasoning), lists data sources and assumptions, and covers key parameter interactions. This fully compensates for the lack of an output schema.

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

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

Schema description coverage is 83% (high), so baseline is 3. The description adds significant meaning beyond the schema by explaining how parameters like year_built and property_type drive regulatory filters and exemptions. It also contextualizes defaults and relationships between inputs and outputs.

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 it performs investment-grade deal underwriting with a regulatory layer, lists specific outputs (financials, regulatory resolution, projection, drag summary, verdict), and distinguishes from sibling tools like analyze_zoning or get_entitlement_roadmap by focusing on multifamily acquisitions and rent control analysis.

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 explicitly states when to use the tool: "when an agent needs to underwrite a multifamily acquisition, run a 'what-if' on a regulatory scenario, or surface NOI risk that conventional underwriting models miss." This provides clear guidance on use cases and implicitly excludes non-underwriting 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?

No annotations provided, so description must carry behavioral burden. It only states what is returned, but does not disclose if the operation is read-only, authentication needs, rate limits, or side effects.

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

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

Single sentence that is concise and front-loaded with key return items. No extraneous 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 complexity of zoning analysis, the description lacks explanation of what HCD compliance means, conditions for state-law overrides, or how to interpret results. No output schema, making it insufficient for an informed 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 each parameter described. Description adds overall context but no extra parameter-level detail beyond schema. 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?

Description clearly states the tool returns zoning classification, HCD compliance status, and specific state-law overrides for any US address. This distinguishes from sibling tools like analyze_deal or find_opportunities.

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 for zoning analysis, but no explicit guidance on when to use vs alternatives like lookup_property or get_entitlement_roadmap. No exclusions or prerequisites mentioned.

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 the description carries full burden. It only says 'Scan' and 'Returns ranked candidate list,' but does not disclose whether it's read-only, destructive, or any other behavioral traits like rate limits or performance implications.

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?

One sentence with front-loaded action and specific details. No unnecessary words, every part serves a purpose.

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

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

No output schema is provided, and the description does not explain the structure of the ranked candidate list. With 12 sibling tools, more context about when to use this over alternatives would improve 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?

Schema description coverage is only 25%. The description adds value for the 'incentive' parameter by listing examples, but fails to explain 'state' (needed to disambiguate cities) and 'max_results' (controls count). It does not compensate for the low coverage.

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 scans a city for parcels qualifying under specific state-law incentives and returns a ranked list. The verb 'scan' and resource 'city for parcels' are specific, and the listed incentives distinguish it from siblings like 'scan_portfolio' and 'source_deals'.

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 this tool versus alternatives. It implies usage for finding qualifying parcels under incentives, but does not mention when not to use it or provide context relative to sibling tools like 'analyze_deal' or 'watch_parcel'.

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. Description lists output components but does not disclose behavioral traits like data source, update frequency, or error handling.

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?

Single sentence covering multiple output aspects. Front-loaded with key value, 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 4 parameters and no output schema, the description omits important details like how to interpret risk flags or CEQA pathway, and lacks usage examples.

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

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

Schema description coverage is only 25%. Only project_type has an example. The description does not clarify optional parameters (city, unit_count) or their impact on results.

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 a step-by-step approval pathway including permits, timelines, fees, CEQA pathway, and risk flags. It uses specific nouns and distinguishes this tool from siblings like analyze_zoning or track_permit.

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 guidance on when to use this tool vs alternatives. Does not mention when not to use it or prerequisites.

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

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

No annotations provided, so description carries full burden. It implies read-only behavior ('Live') and lists data types, but does not explicitly state idempotency, refresh rates, or authorization needs. Adequate but 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?

Single sentence with no extraneous words. Efficiently conveys the tool's output.

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

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

For a simple, parameterless tool returning current rates, the description is mostly complete. Could mention data source or update frequency, but not essential given the tool's scope.

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 zero parameters with 100% coverage. Description logically adds no parameter detail. Baseline 4 for zero-param case.

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 live SOFR, 10Y Treasury, and CRE cap-rate spreads for underwriting. It uses specific verbs and resources, differentiating it from sibling tools like analyze_deal or find_opportunities.

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 guidance on when to use this tool versus alternatives. Given many sibling tools, explicit context or exclusions would help but are absent.

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 the description fully carries the burden. It explicitly states 'Read-only,' describes the return content including the 'not found' envelope, and mentions the nightly cron for new listings, setting expectations for data freshness and coverage 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 well-structured with a clear first sentence summarizing the output, followed by use cases, read-only behavior, and cron note. Slightly verbose but every sentence adds value; minor surplus detail like the cron info could be condensed.

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 one parameter and no output schema, the description thoroughly explains the return structure, error case, and related functionality. It equips the agent with all necessary context to decide when and how to invoke this 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?

The single parameter 'address' is fully described in the schema with an example. The description does not add new semantic meaning beyond confirming it expects a full street address; hence no significant extra value. Baseline 3 due to 100% schema coverage.

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 a pre-rendered Dilix demo bundle for an address, listing specific components (3D hero, HUD images, broker headline, Dilix correction metrics, shareable URL). It distinguishes from sibling tools like request_demo_render and lookup_property by focusing on the pre-rendered demo use case.

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: 'when an agent or chat user wants to surface the Dilix counterfactual on a property — pitches, deck slides, prospect emails, social posts.' Also provides a fallback hint to live-render at /feasibility-3d if no demo exists, guiding when to use an alternative.

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, description carries full burden. It lists return types (records, valuation, history, etc.) but does not disclose behavioral traits like error handling for invalid addresses, rate limits, or auth requirements.

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?

Single sentence, front-loaded with key data categories (records, valuation, history, owner, attributes). No wasted words; efficient communication.

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 tool simplicity (2 params, no output schema, no annotations), description adequately covers purpose and scope. Could mention behavior when property not found, but overall sufficient.

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 covers both parameters with clear descriptions (street address, city/state/ZIP). Description adds 'any US property' context, but does not significantly extend beyond schema, which already provides 100% coverage.

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

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

Description clearly states the tool returns property records, valuation, sale history, owner info, and physical attributes for any US property. It uses specific resource categories and distinguishes from siblings like lookup_demo (which likely focuses on demo data) and analyze_deal (which is about deal analysis).

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 when-to-use or when-not-to-use guidance. The description implies use for US property lookups based on address, but does not contrast with alternatives like find_opportunities or track_permit.

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 discloses that it fires GitHub Actions, returns immediately, and that the bundle is typically available in 60-90 seconds. It also explains the follow-up action of calling `lookup_demo`. This is good transparency for an async trigger tool, though it could mention if re-triggering is allowed.

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 main action. Every sentence adds value: the first states the core function, the second explains the async behavior, the third gives usage guidance and an ideal use case. 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 context (2 params, no output schema, no nested objects), the description is complete. It covers what the tool does, how it works asynchronously, what to expect, and how to retrieve the result. The intended use case is clear.

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 adds value by explaining the optional `source_url` parameter: 'if provided, the render scrapes broker NOI for full $ delta computation.' This provides meaningful context beyond the schema's description.

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

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

The description clearly states the tool's function: 'Live-renders a Dilix demo bundle for an address that doesn't have one yet.' It specifies the verb ('renders'), resource ('Dilix demo bundle'), and conditions. It distinguishes itself from sibling tools like `lookup_demo` which is for fetching existing demos.

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 when to use: 'Use this when `lookup_demo` returned `found: false`.' It also provides ideal context ('live cofounder/investor pitches'). While it doesn't explicitly say when not to use, the condition is clear from the context.

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 mentions the input limit (50 properties) and output type (report), but does not disclose if the tool is read-only, has side effects, or requires authentication.

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 concise sentences, front-loaded with the key action, and contains no extraneous information.

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

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

Given no output schema, the description adequately explains return value. With 11 siblings, more differentiation could be helpful, but the description is sufficient for a simple single-parameter 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?

The schema coverage is 100% with a description of the 'addresses' parameter. The tool description reinforces the purpose but adds no new semantic details 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 performs a 'Bulk compliance and opportunity scan across up to 50 properties' and returns a per-property report. This distinguishes it from siblings like analyze_deal (single property) and find_opportunities (search).

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 batch scanning multiple properties, providing context. However, it does not explicitly state when not to use it or mention alternatives like analyze_zoning for zoning-specific scans.

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, description should disclose auth needs, side effects, or output behavior. It only states the basic function, omitting details like whether it's a search or retrieval, or any 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?

Single sentence, no wasted words. Efficiently conveys the core function.

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 provided, so description should explain return value. It does not state what information is returned about sourced properties. Nested object parameter could also use more context.

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 descriptions for both parameters. Description adds an example for 'criteria' but doesn't fully elaborate all possible subfields. 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?

Description clearly states the tool sources candidate properties matching criteria across markets. Verb 'Source' and resource 'candidate properties' are specific, but lacks differentiation from siblings like 'find_opportunities'.

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 guidance on when to use this tool vs alternatives. Sibling tools like 'find_opportunities' and 'scan_portfolio' overlap, but no when-not-to or context is 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?

With no annotations, the description must disclose behavior. It says 'notifies on status changes' but does not explain the notification mechanism (e.g., email via notify_email), whether it is a one-time or ongoing subscription, or if authentication is required. Major behavioral aspects are left ambiguous.

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 two sentences and no wasted words. It could be improved by structuring information about parameters separately, but it is not 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?

Given three parameters and no output schema/annotations, the description is too short. It omits details about output format, notification frequency, prerequisites, and how it differs from sibling tools like watch_parcel. The notification feature needs more explanation for an agent to use 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?

The description states tracking 'by ID or address', adding context that address and permit_id are alternative identifiers. However, with 0% schema coverage, it fails to explain the notify_email parameter (its purpose, optionality, or format). The description adds some value but does not fully compensate for the missing schema descriptions.

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 tracks a permit application by ID or address and returns status with notifications. The verb 'Track' and resource 'permit application' are specific. However, it does not explicitly differentiate from siblings like watch_parcel, which may have overlapping functionality.

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 this tool versus alternatives. The description implies usage for tracking a specific permit, but does not mention when not to use it or provide context for choosing between track_permit and sibling tools like watch_parcel or lookup_property.

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 must disclose all behavioral traits. It mentions hourly monitoring and email alerts but omits details on setup, costs, limits, or how to stop monitoring.

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 single sentence is efficient but lacks necessary details. It is not overly verbose but sacrifices completeness.

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 two simple parameters and no output schema, the description is somewhat adequate but fails to explain monitoring scope, return behavior, or how to manage alerts.

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 clarify parameters. It only restates parameter names without adding format, constraints, or examples.

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 sets up hourly autonomous monitoring on a parcel and sends email alerts on changes. The verb 'set up' and resource 'parcel' are specific, and it distinguishes from sibling 'track_permit' by covering broader regulatory changes.

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 this tool versus siblings like 'track_permit'. The description implies general monitoring use but lacks exclusions or alternatives.

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