parcel-edge

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

With no annotations, the description discloses that the tool is a watchlist that re-checks as financing appears, and that loan absence is unverified. It names the scope (Cook County) and limitations, but does not specify side effects or read-only nature explicitly.

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 core purpose. It packs information without unnecessary words, though it could be slightly more 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 no output schema, the description adequately explains what the tool returns (permit amount, age, window status, applicant, work description) and its purpose. It provides limitations and scope, making it sufficiently complete for a query tool of moderate 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?

Schema coverage is only 33% (only county has a description, which is minimal). The description does not explain 'limit' or 'minTier' beyond their schemas; it lists output fields (permit amount, age, etc.) but not parameter details. This fails to compensate for the low 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 provides fresh assessable construction permits in the permit-to-financing window. It specifies the target audience (hard-money/construction lenders) and the niche (prospects racing the permit-to-loan gap), distinguishing it from generic permit 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 explicitly states when to use (for lenders seeking prospects) and provides honest caveats about unverified loan absence. However, it does not mention when not to use or compare to sibling tools, lacking explicit exclusions.

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

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

With no annotations provided, the description bears full responsibility for disclosing behavior. It mentions the content (counties, streams, etc.) and notes it is free, but does not disclose data freshness, rate limits, authentication needs, or any side effects. This is insufficient for a tool that presumably retrieves 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?

The description is a single sentence, which is concise. However, it could be better structured (e.g., bullet points) to improve readability, especially given the list of items. It is not verbose, so the score is slightly above average.

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

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

The description covers the main content (counties, streams, buyers, methodology, notes), but lacks details about output format (e.g., JSON array, table) and does not explain what 'honest signal-density notes' means. It is moderately complete for a tool with no output schema.

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

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

The input schema has no parameters, and schema description coverage is 100% (empty). The description does not need to add parameter meaning. It appropriately lists the types of information returned, which is relevant context for a parameterless tool.

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

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

The description clearly states that the tool provides information on covered counties, streams, buyers, data sources, methodology, and signal-density notes. It distinguishes itself from sibling tools that focus on specific reports like construction_window_leads or exemption_flags. However, it could be more specific about the format or type of coverage 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?

No guidance is given on when to use this tool versus its siblings, nor are any prerequisites or context provided. The word 'Free' might hint at usage restrictions, but it does not constitute clear usage guidelines.

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?

Without annotations, the description discloses that results are 'flags' and 'candidate improper exemptions,' not conclusive fraud. It mentions 'Full owner/exemption EVIDENCE CHAIN' but does not detail behavioral aspects like idempotency, rate limits, or data freshness. This is 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?

The description is dense and includes many examples and details, which is helpful but could be more concise. It is structured with a clear start, followed by examples and caveats, but the length (multiple sentences with parentheticals) slightly reduces clarity.

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 and the complexity of multi-county exemption flags, the description covers the tool's purpose, use case, supported counties, and a disclaimer. It lacks explanation of the minTier parameter but is otherwise comprehensive for an agent to understand when and how to invoke it.

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 33% (only county has a description). The description adds meaning by explaining the default county (allegheny-pa as densest) and the condition for county support. However, parameters limit and minTier are not elaborated beyond the schema, leaving gaps.

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

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

The description explicitly states the tool identifies 'exemption-contradiction FLAGS' where a homestead exemption coexists with a non-owner-occupant owner, with specific county examples. It clearly distinguishes this from sibling tools like overassessment_leads or construction_window_leads by focusing on exemption fraud indicators.

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 explains the tool is for 'candidate improper exemptions for exemption-audit/recovery contractors' and specifies which counties are supported. It includes the caveat 'NEVER a fraud verdict,' but does not explicitly state when not to use or provide direct comparisons to sibling tools.

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

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

With no annotations provided, the description carries the full burden. It discloses the paid nature, that it returns only unsatisfied liens, explains interpretation of tax-year span (judicial vs upset sale), and states the redemption posture under PA law. It also notes the cross-join value and limitations. This is thorough for a read-only 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 somewhat lengthy but front-loads the key information (cost, purpose) and uses clear structuring (naming the tool, listing returns, providing interpretation). Every sentence serves a purpose, though it could be tightened slightly for brevity.

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 tax-deed title research and no output schema, the description fully explains what the tool returns (lien stack, totals, tax-year span, redemption posture), how to interpret results, and cautions about its use as a candidate input only. It is comprehensive for a single-input 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 'pin' has schema coverage 100% with a description. The tool description adds meaning by specifying it is an Allegheny County PIN and providing an example format (0138S00120000000). It also explains that the report is generated for that PIN, adding context 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 specifically states it is a 'per-parcel tax-deed title-research report for a single Allegheny County PA PIN' and lists the returned data (unsatisfied liens, tax-year span, redemption posture). The verb 'bundle report' and resource 'liens on a PIN' are clear, and it distinguishes from sibling tools like 'county_coverage' or 'exemption_flags' which serve different purposes.

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 cost ($0.50 USDC/call, free preview) and provides a caveat that it is a 'CANDIDATE title input, NOT a title opinion' and advises confirming with county/counsel before bidding. This gives clear context for appropriate use, though it does not explicitly contrast with sibling tools.

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

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

No annotations are provided, so the description carries full burden. It discloses that leads are candidates from public data, the firm confirms valuation, and includes a disclaimer 'Not legal/valuation advice.' It does not mention rate limits or auth, but for a read tool this is sufficient. However, it could be more specific about whether data is real-time or cached.

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 paragraph. It front-loads the core purpose, then provides necessary details (counties, alternatives, disclaimer). Every sentence adds value with 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?

The tool has no output schema, so the description should explain the output structure. It mentions 'Scored, dated, deadline-stamped' but does not specify fields like tier, ratio, parcel ID, or sale price. It also lacks information about pagination, ordering, or rate limits. Given 4 parameters and moderate complexity, this is a notable 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 coverage for parameters is 100%, so each parameter has its own description. The tool description adds context about the meaning of 'over-assessment' and the ratio, but does not add significant information beyond what the schema already provides for individual parameters. 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 the tool returns 'Scored, dated, deadline-stamped COMMERCIAL property-tax over-assessment leads.' It defines what constitutes a lead and specifies it's for contingency tax-appeal firms. This distinguishes it from siblings like 'exemption_flags' by noting that for non-disclosure counties (Texas/Georgia), 'exemption_flags' should be used instead.

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: for commercial property tax over-assessment leads in counties that publish sale prices. It also explicitly says when not to use (Texas/Georgia non-disclosure counties) and names the alternative sibling 'exemption_flags'. This provides clear decision criteria.

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 does not disclose behavioral traits beyond the data returned (e.g., read-only, no side effects, authentication needs, or rate limits). The word 'Free' adds some context but is insufficient.

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 that efficiently conveys purpose, scope, and key outputs. Every word serves a purpose; 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's simplicity (one param, no output schema) and lack of annotations, the description covers the core functionality but omits return format and error handling. It is adequate but not fully comprehensive.

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 the pin parameter described as '14-digit Cook County PIN'. The description repeats this format in context. Baseline 3 applies as the description adds minimal value 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 clearly states it checks a single Cook County PIN for over-assessment, listing specific data points (AV, sale, ratio, appeal window). It distinguishes from siblings like overassessment_leads by emphasizing 'SINGLE' PIN, indicating a focused tool.

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 does not explicitly guide when to use this tool versus siblings. It mentions 'SINGLE' PIN, which implies it's for individual queries, but lacks when-not-to-use or alternative tool references.

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 transparently explains the tool's inferential nature, data source (Cook Assessor Permits), and limitations (paperwork lag, phased builds). Does not mention read-only status, but that is implied for data retrieval.

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

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

The description is verbose with all-caps and business jargon. It is not front-loaded; the first sentence is convoluted. While it includes useful detail, it could be more 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?

Given no output schema, the description mentions output fields (permit amount, age, etc.). It explains data source and limitations. However, it omits details on parameter 'limit' and 'minTier', and does not clarify pagination or ordering, leaving some gaps.

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

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

Schema description coverage is 33% (only county has a description). The description does not explain 'limit' or 'minTier' parameters, leaving their meaning unclear. It adds no value beyond the schema for parameter semantics.

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 returns stalled-project candidates for surety/draw-control firms and construction lenders, specifying criteria (large assessable permits past build window). However, it does not explicitly distinguish from sibling tools like construction_window_leads, missing full differentiation.

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 context on when to use (stalled permits) and limitations (inference, not verified, county dependency). Lacks explicit when-not-to-use or alternative tool mentions, but the context is sufficient for basic guidance.

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