Cook County / Chicago Property Data

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

No annotations provided, so description bears full burden. It explains the tool returns comps with price ranges, but omits behavioral traits such as whether it is read-only, authentication needs, rate limits, or error handling. The description lacks disclosure of limitations 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?

The description is a single sentence that front-loads the key action and resource. It efficiently conveys scope and unique value without unnecessary words. However, it could be broken into two sentences for slightly better readability.

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 tool with one parameter and no output schema, the description covers the core functionality and output (comps with price range). However, it lacks details on edge cases (no comps found), error conditions, or performance, which are minimal but 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?

Only one parameter 'pin' with zero schema description coverage. The description mentions 'given PIN' but does not explain what a PIN is (Parcel Identification Number) or provide format/validation. It adds minimal semantic 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 the verb 'find' and resource 'comparable sales', specifies scope (recent arm's-length, same neighborhood and property class), and highlights the derived price range. It distinguishes from raw open-data query and sibling tools focus on parcels and dossiers, making purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for valuation by mentioning 'automated valuation', but does not explicitly state when to use this tool versus siblings like get_cook_county_parcel or get_cook_county_property_dossier. No when-not-to-use guidance or alternatives are 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 are provided, so the description bears full burden. It does not mention side effects, permissions, or error conditions (e.g., invalid PIN). However, it lists output fields, providing some transparency.

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

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

The description is a single sentence that is efficient and packs necessary information (input, output, constraints) without any 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 single-parameter tool with no output schema, the description adequately covers input and output. It could be improved by noting error handling (e.g., PIN not found) or if the PIN requires hyphens.

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 has no description for the pin parameter, but the tool description adds that the PIN must be 10 or 14 digits, which is essential guidance beyond the bare schema type.

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 retrieves a parcel record for a specific PIN in Cook County, IL, listing the returned fields (address, assessor class, etc.). It distinguishes from siblings by specifying 'parcel record' and the geographic scope.

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 you have a 10- or 14-digit PIN, but does not explicitly state when to use this tool versus alternatives like find_chicago_comparable_sales or get_cook_county_property_dossier.

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 full burden. It discloses that permits are derived via address+geo matching, making the record a finished product. It does not mention authentication or rate limits, but for a read-only data retrieval tool, the provided context is sufficient.

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. The first sentence lists contents and establishes purpose; the second adds critical context about permit linkage. No unnecessary 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?

The description covers the main data categories and the unique value of permit linkage. However, without an output schema, it would benefit from a brief note on the output structure (e.g., JSON object with fields). Still, it gives enough for basic understanding.

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 only mentions that the tool takes a PIN, with no details about format (e.g., 14-digit, dashes) or examples. Since schema coverage is 0%, the description fails to compensate, leaving the agent without guidance on valid input.

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 comprehensive property dossier including parcel basics, sales history, permits, tax assessment, and location context for a given PIN. It distinguishes itself as a 'one-call due-diligence record' which implies it is the most complete option among siblings.

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 this is the go-to tool for comprehensive property due diligence, mentioning that permits are linked and cannot be reproduced from raw data. However, it does not explicitly state when not to use it or compare directly 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?

With no annotations, the description clearly indicates it is a search/lookup operation returning data, implying no destructive side effects. Could mention any rate limits or authentication needs, but the behavior is well described.

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, no filler. First sentence defines core function and output, second provides usage order. Efficient and front-loaded.

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?

Covers input, output (ranked candidates with fields), domain (Cook County/Chicago), and integration with sibling tools. No output schema, but description sufficiently documents return values.

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 has 0% coverage on the single parameter. The description adds meaning by stating it accepts 'full or partial' street addresses, clarifying the input scope beyond the schema's bare type declaration.

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?

Explicitly states it resolves a street address to parcel PIN(s) with ranked candidates, including address, city, ZIP, and match score. Clearly differentiates from sibling tools by specifying it should be called first.

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 usage instruction: 'Call this FIRST when you have an address but not a PIN'. Also lists subsequent tools (get_cook_county_parcel, etc.), giving a clear workflow.

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