ReadyPermit Property Intelligence

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's behavioral contribution is additive. It discloses that the tool takes ~20 seconds and consolidates 20+ sources, which is useful latency context. 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 a dense paragraph but uses clear sections (first sentence, USE WHEN, RETURNS, timing). Each sentence contributes unique value. Could be slightly restructured for easier scanning, but overall 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?

Given no output schema, the description thoroughly explains return values (Buildability Score, zoning, flood zone, etc.) and even mentions the alternative cost. It covers why to use this tool and what to expect, making it complete for complex property analysis.

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 value by explaining that address 'accepts any format' and that persona 'changes tone and emphasis' with examples. This goes beyond the schema's minimal 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's purpose: 'Get complete property intelligence for any U.S. address' and lists specific data categories (zoning, flood risk, etc.). It distinguishes itself from sibling tools by implying a comprehensive scope, though it doesn't explicitly name alternatives. The USE WHEN examples further reinforce 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?

Provides explicit 'USE WHEN:' conditions with concrete example queries, plus a 'RETURNS:' section. This gives clear context for when to invoke this tool versus more specific siblings. No when-not-to-use, but the guidelines are strong enough for an AI agent to decide correctly.

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 cover safety (readOnlyHint, destructiveHint), so description adds value by disclosing return structure (max square feet, stories, envelope dimensions) and clarifying the tool's nature as a local calculation engine without external data dependencies. 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?

Excellent structure with clear functional headers (USE WHEN, RETURNS) and a concluding input summary. Every sentence serves a distinct purpose—defining scope, triggering conditions, output format, and input requirements. No redundant or filler content despite 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?

Given the lack of output schema, the description compensates by explicitly documenting return values (dimensions, coverage math). It adequately covers the 7-parameter input space and clarifies the tool's relationship to sibling query tools, providing sufficient context for agent selection and 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?

With 100% schema description coverage, the schema carries the parameter documentation burden. The description lists input categories ('lot area, setbacks, FAR, height limit, and coverage') which map to parameters but do not add semantic depth beyond the schema's technical definitions (e.g., does not explain interaction between setbacks and 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 opens with specific verb (Calculate) + resource (maximum buildable area/building envelope) + context (zoning constraints). It explicitly distinguishes from siblings by stating it is a 'pure calculation tool, does not query data'—contrasting with lookup_zoning or search_comparable_sales.

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?

Contains explicit 'USE WHEN' section listing specific user query patterns ('how much can I build', 'max square footage', etc.). Implicitly directs users to alternatives by clarifying it 'does not query data,' suggesting lookup_zoning for code lookups, and notes required inputs (lot dimensions, zoning rules) must be 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 already indicate read-only, idempotent, non-destructive behavior. Description adds value by listing exact outputs (wildfire zone, seismic zone, EPA proximity, etc.) and input methods. 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?

Well-structured with clear sections: main action, USE WHEN, RETURNS. Slightly lengthy due to enumeration of use cases, but each 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?

For a tool with no output schema, the description fully explains what it returns, including specific risk zones and combined score. Input options are clear. Covers all necessary context 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?

Schema coverage is 100% with clear descriptions for each parameter. Description adds that address is preferred and coordinates are alternative, which is helpful but not essential 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?

Description clearly states it runs full environmental risk screening using specific data sources and returns specific risk assessments. It distinguishes from sibling tools like check_flood_zone by being comprehensive and mentioning distinct data sources.

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 'USE WHEN' list with common user queries, giving clear guidance on when to invoke. However, it does not exclude cases where a more specific sibling like check_flood_zone would be better, so not a perfect 5.

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 cover read-only/idempotent/destructive hints. Description adds critical context: 'Uses the official FEMA API' (confirms external dependency), and explains return value semantics (X=low risk, A/AE=100-year, V/VE=coastal) which annotations don't provide. 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?

Perfectly structured with clear section headers (USE WHEN, RETURNS). Four sentences each earning their place: purpose, trigger conditions, return value documentation, and data source authority. No redundancy or verbosity.

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 single-parameter lookup tool with no output schema, the description comprehensively compensates by detailing exact return fields (zone codes, insurance requirements, base flood elevation, annual risk probability). Covers all necessary context for an agent to use this effectively.

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 100% schema description coverage for the single 'address' parameter, the schema carries the semantic burden. Description mentions 'U.S. property' aligning with the schema's 'Full U.S. property address' but adds no additional syntax guidance or format examples 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?

Opens with specific verb 'Check' + exact resource 'FEMA National Flood Hazard Layer' + scope 'any U.S. property'. Clearly distinguishes from sibling 'check_environmental_risks' by focusing specifically on FEMA flood data rather than general environmental 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?

Excellent 'USE WHEN:' section lists six specific query patterns (e.g., 'is this in a flood zone', 'do I need flood insurance') that trigger this tool. Lacks explicit mention of when NOT to use it or naming of sibling alternatives like 'check_environmental_risks' for broader environmental queries.

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 cover safety profile (readOnly, idempotent, non-destructive). The description adds crucial behavioral context: performance characteristic ('quick', 'faster than analyze_property'), and critically, details the return structure (score, letter grade, buildability band, top 3 factors) which compensates for the missing output schema. Does not mention rate limits or caching behavior, preventing a 5.

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

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

Excellent structure with clear section markers ('USE WHEN:', 'RETURNS:'). Every sentence delivers value: purpose, usage triggers, output specification, and performance comparison. No filler or redundancy despite containing multiple distinct information types.

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?

Comprehensive for a tool lacking an output schema. The description fully specifies the return values (numeric ranges, enum values for grades/bands, count of factors). Sibling differentiation is explicit. Combined with strong annotations covering safety and idempotency, no critical information is missing.

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 100% schema description coverage ('Full U.S. property address'), the baseline is 3. The description mentions 'this address' in the usage examples, providing minimal additional context, but does not need to compensate for schema gaps. No additional parameter semantics (format examples, validation rules) are provided 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 opens with a specific verb ('Get') and resource ('Buildability™ Score'), explicitly scopes it to 'quick' screening 'without running the full analysis', and differentiates from sibling 'analyze_property' by stating it's 'Faster than analyze_property'. Clearly distinguishes this as the lightweight pre-screening option.

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?

Contains an explicit 'USE WHEN:' section listing specific user intents ('pre-screen properties', 'is this worth analyzing', 'quick check', 'filter a list of addresses fast'). Explicitly names the alternative tool ('analyze_property') and states when to prefer this one ('deal screening and portfolio filtering').

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 cover the safety profile (readOnly, idempotent, non-destructive), but the description adds valuable behavioral context by detailing the specific data returned in the 'RETURNS:' section (zone codes, FAR, setbacks, parking requirements). This compensates for the missing output schema. Minor gap: doesn't mention coverage limitations or external data dependencies implied by openWorldHint.

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?

Well-structured with three distinct sections (purpose, usage triggers, return values) that front-load critical information. The enumerated examples in 'USE WHEN' and 'RETURNS' are slightly verbose but serve a functional purpose for pattern matching. No filler content present.

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 absence of an output schema, the description comprehensively documents return values including specific zoning fields (FAR, setbacks, lot coverage) that would otherwise be unknown. Combined with clear annotations and single well-documented parameter, this provides complete contextual information for 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?

With 100% schema description coverage ('Full U.S. property address'), the baseline is 3. The description reinforces this by specifying 'any U.S. property address' but doesn't add syntax details, format examples, or constraints 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 opens with a specific verb ('Look up') and clear resource ('zoning designation and development standards'), explicitly defining the tool's scope. It further distinguishes itself from siblings like check_flood_zone or search_comparable_sales by focusing on zoning codes, permitted uses, and development standards rather than environmental risks or sales 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?

Contains an explicit 'USE WHEN:' section that lists specific query patterns ('what zone is this', 'what can I build', 'can I build a duplex here'), providing clear signals for when to select this tool over alternatives like analyze_property or get_buildability_score. This is exemplary guidance that leaves little ambiguity for 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 details exactly what the tool returns: 'subject property AVM, list of recent sales with price, sqft, price/sqft, distance, beds/baths, and rental comps with rent amounts. Also includes local market stats.' This adds significant behavioral context beyond the readOnlyHint annotation.

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 structured with a clear opening purpose, a 'USE WHEN' block, a 'RETURNS' block, and a closing note. Every sentence adds value and there is 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?

For a read-only search tool with 4 parameters and no output schema, the description covers purpose, usage triggers, output details, and context. It misses potential details like pagination or error behavior, but overall is quite 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 coverage is 100% with all parameters described. The description does not add significant extra meaning 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 starts with a clear verb-resource pair: 'Find recent comparable property sales and rental comps near a property.' It distinguishes this tool from siblings like analyze_property or check_environmental_risks by explicitly mentioning 'comparable sales' and 'comps'.

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 'USE WHEN' section provides concrete user query examples (e.g., 'what are comps in this area', 'recent sales near here'). It also states the tool is useful for 'investor deal evaluation, CMA, and market analysis.' No explicit when-not or alternatives, but 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?

The description discloses key behavioral traits beyond annotations: confirmed corrections are applied within 48 hours, submissions affect the Staff Responsiveness city score, and it returns a correction ID and status. No annotation 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 clear sections (purpose, usage, behavior, return). It is front-loaded but slightly verbose with motivational phrasing. Every sentence adds value, though some could be tightened.

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 (5 parameters, 2 required, no output schema), the description covers purpose, usage, behavioral outcomes, and return format. It lacks detail on error or rejection handling, but overall it's sufficiently complete for an AI 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?

Schema coverage is 100%, so the baseline is 3. The description does not add deep parameter-level detail but provides overall context. It's adequate but doesn't enhance individual parameter understanding.

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: reporting an error on a Buildability page for verification and update. It uses specific verbs ('Report an error') and resource ('Buildability page'), and distinguishes it from sibling tools that focus on data retrieval or 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?

The description includes a 'USE WHEN' section with concrete examples of user statements that trigger this tool. It also provides motivational context about the civic feedback loop. While it doesn't explicitly state when not to use, the examples and clarity make the usage context strong.

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