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

With no annotations provided, the description carries the burden of behavioral disclosure. It transparently explains that developerROI is a model output, not arithmetic, and disagrees with a build-to-zoning proforma, which is a significant limitation. It does not explicitly state whether the operation is read-only, but the 'Get' verb implies a safe read operation.

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 the main purpose, followed by output details and a critical caveat. The caveat about developerROI is essential and well-phrased, though slightly lengthy. Overall, every sentence adds value and there is 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 only one parameter and no output schema, the description provides a good overview of the return fields and the data-quality caveat. It also connects to the sibling list_market_signals tool. It could be more complete by mentioning any other return values or error conditions, but the essentials are covered.

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 already describes the 'id' parameter with 100% coverage. The description adds value by specifying that the id originates from list_market_signals, providing cross-tool context that is not in the schema. This helps agents understand what id to supply.

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: 'Get detailed AI intelligence for a specific property' and lists specific outputs (teardown probabilities, flippability scores, comparable sales, developerROI). It also distinguishes itself from sibling list tools by emphasizing it operates on a specific property and takes an id from list_market_signals.

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 clear usage context: it requires an id from list_market_signals, indicating a workflow. It also cautions against using developerROI for underwriting, which guides when not to rely on that value. However, it doesn't explicitly state alternatives or when to prefer this tool over siblings beyond the id source.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explicitly states the ordering behavior (ranked by ADU feasibility) and the returned data attributes, which gives a clear picture of the tool's output behavior. It does not mention potential side effects, but 'List' implies a read-only operation, and no contradictions with annotations exist.

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, front-loaded sentence with no wasted words. It states the action, subject, ranking criterion, and key output metrics efficiently, and the acronym expansion for ADU adds clarity without excessive length.

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 list tool with three well-documented parameters and no output schema, the description adequately conveys the core return values and ordering. It does not describe default limit behavior or exact result format, but the schema covers parameter defaults, making the description reasonably complete for its complexity.

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% parameter description coverage, so the schema already explains all three parameters (limit, minScore, excludeBlockers). The description adds no additional parameter-level semantics beyond the overall 'ranked by ADU feasibility' context, which does not meaningfully enhance the schema definitions.

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

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

The description clearly states the verb 'List' and the resource 'parcels ranked by ADU feasibility', and specifies the output fields (estimated max units, buildable square footage, lot geometry). It distinguishes itself from sibling tools like list_sb9_inventory and list_redevelopment_leads by focusing specifically on ADU feasibility.

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 ADU feasibility ranking is needed, but it does not explicitly state when to use this tool versus alternatives like list_sb9_inventory or search_permits. No exclusions or alternative tool references are provided, so guidance is only implied.

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 of behavioral disclosure. It adds useful context about high-signal opportunities and the intended workflow, but it does not disclose result ordering, return format, pagination, or default filtering behavior. 'Search' implies read-only, but operational details remain unspecified.

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 states the core purpose, and the second provides usage guidance. Information is front-loaded and every phrase 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?

The tool is simple with 4 optional, well-documented parameters and no output schema. The description explains when to use it but does not describe the result format or ranking semantics. Given the low complexity, this is adequate but leaves room for more operational detail.

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 covers 100% of parameters with meaningful descriptions, so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema already provides, which is acceptable given full 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 uses a specific verb ('Search') and a clear resource ('high-signal real estate investment opportunities') with concrete examples (teardowns, flips). It also differentiates from sibling tools by framing this as the entry point before diving into specific property details.

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 phrase 'Use this to find properties before diving into specific details' clearly indicates when to use the tool in a workflow. It does not explicitly name alternatives like get_property_intelligence, but the context implies a sequencing, and no exclusions are stated.

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 discloses ranking by redevelopment score and inclusion of FAR headroom in output, but doesn't mention read-only behavior, pagination, or default filtering behavior. Lacks depth but gives some context beyond schema.

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

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

Single well-structured sentence conveys core purpose, criteria, ranking, and output. Every phrase adds value 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?

For a list tool with four parameters and no output schema, description sufficiently explains what the tool does and what it returns. Gaps like usage alternatives and behavioral nuances prevent a 5, but it's reasonably complete given schema covers parameters.

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. Description adds general context about the domain (FAR headroom) but doesn't elaborate on each parameter beyond what schema already states. Meets but does not exceed baseline.

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

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

Description uses specific verb 'List' with resource 'underbuilt parcels' and adds defining criteria (small/older homes, low FAR usage, sizable lots). Clearly distinguishes from sibling tools like list_adu_leads or list_sb9_inventory by focusing on redevelopment score and FAR headroom.

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 identifying redevelopment opportunities, but provides no explicit guidance on when to prefer this tool over siblings or any exclusion criteria. No mention of alternatives even though sibling tools exist.

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

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

With no annotations, the description carries the behavioral disclosure burden. It indicates a read-only operation via 'read', specifies a geographic scope ('California-only'), and discloses that output includes block reasons for non-eligible parcels. It does not mention pagination or rate limits, but for a list tool this is acceptable.

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, well-structured sentence that front-loads the main action and resource, then adds scope and differentiation. Every clause earns its place with no filler.

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

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

Given 4 loosely-typed optional parameters, no output schema, and no annotations, the description provides enough context for correct use: scope, eligibility, and output characteristic (block reasons). It could benefit from explicit statement of default behavior, but the schema covers the defaults, so this is not a critical gap.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description does not add semantic meaning to the parameters (e.g., no mention of how 'limit' or 'status' behave), so it earns the baseline score of 3.

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 ('List') and clearly identifies the resource: active listings eligible for SB 9 lot split or duplex conversion, with per-parcel block reasons. It also distinguishes itself from sibling lead-list tools by stating it is a 'parcel-level buildability read, not a generic lead list.'

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 scopes usage to California and clearly states this is not a generic lead list, giving a strong 'when not to use' signal. However, it does not name a specific alternative tool or list explicit exclusion scenarios beyond 'generic lead list', so it falls just short of full 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?

With no annotations, the description relies on the verb 'search' and the phrase 'actually been permitted' to imply a read-only, authoritative query. However, it does not disclose output format, pagination behavior, data recency, or access requirements. No contradiction with annotations exists.

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 the action and scope, and ends with a clear use case. Every sentence contributes meaning with no filler.

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

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

For a search tool with fully documented parameters, the description gives sufficient context on purpose, filters, and usage. It lacks an output schema and does not specify return fields, but the core decision-making context is adequately covered.

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 the parameter semantics are fully documented in the schema. The description restates the filter options but adds no additional meaning beyond what the schema already 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 uses a specific verb and resource ('Search issued building permits') and adds geographic scope (SF Peninsula and adjacent Silicon Valley cities). This clearly distinguishes it from sibling tools focused on leads, inventory, and property 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 explicitly states when to use the tool: 'Use this to find what construction has actually been permitted at an address or in a city.' It does not mention exclusions or alternatives, but the intended context is clear.

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