Cook County / Chicago Property Data (free tier, no wallet needed)

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the bar for added value is met by the description's extra details: daily free allowance, wallet-free first 25 calls, $0.10 cost afterward, UTC reset, automatic widening for thin markets, and the explicit caveat that comps are NOT normalized for building size or age. This is rich behavioral context agents need to interpret results and usage costs correctly.

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 but every sentence conveys something decision-relevant: cost/allowance, output contents, market-thinning behavior, and a material limitation. The first sentence leads with the free allowance rather than the core purpose, but the title already carries that framing, so the redundancy is minor. It earns its length despite being longer than 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?

Despite having no output schema, the description tells the agent what the response contains: comparable sales, distance in metres, low/median/high price range, and the matching rung used. It also flags normalization limitations that affect interpretation. For a single-parameter read-only tool, nothing essential about invocation or returned meaning 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?

Schema coverage is 100% and the single pin parameter is already well documented with format, pattern, and an example. The description adds the useful routing note to call search_chicago_property_by_address first for addresses, but that is more usage guidance than parameter semantics. With full schema coverage, the baseline 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 recent arm's-length comparable sales in the same Cook County assessor neighborhood and property class as a given PIN, with distances and an implied price range/AVM. This distinguishes it from raw open-data queries and nearby sibling tools like search_chicago_property_by_address. The verb 'call it' is informal, but the resource and outcome are unmistakable.

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 gives concrete usage context: it is a comps/AVM lookup by PIN, and the schema directs users to search_chicago_property_by_address first when only an address is known. It does not explicitly enumerate when to choose this tool over get_cook_county_parcel or get_cook_county_property_dossier, but the comps/AVM focus makes the intended use clear. The free-quota note helps agents decide when calling is cost-effective.

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 establish read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond annotations: free daily allowance, reset time, post-allowance payment method, and the exact shape of returned 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 somewhat long but every section earns its place: pricing, return fields, and sibling differentiation. The most attention-grabbing detail (free tier) is 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?

For a single-parameter, read-only lookup with no output schema, the description is complete: it covers input format, return fields, cost behavior, and when to choose an alternative tool. No critical operational detail 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?

Schema coverage is 100% and the schema already explains the PIN pattern, dashes, example, and address fallback. The description mostly restates the 10/14-digit PIN requirement without adding new parameter meaning 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 names a specific resource ('Cook County, IL parcel record') and a precise input ('10- or 14-digit PIN'), then lists exact return fields. It also distinguishes itself from the dossier sibling by calling itself 'the cheap single-property lookup.'

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 says to use get_cook_county_property_dossier when sales, permits, or assessments are needed, and to call search_chicago_property_by_address first when only a street address is available. This gives clear routing guidance versus siblings.

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 annotations already declare read-only, open-world, and idempotent behavior. On top of that, the description discloses non-obvious operational details: the 25-free-calls daily limit, $0.03 cost after the allowance, UTC reset, permit-to-PIN linkage derived by address/geo match, and the important caveat that assessment values are assessed, not market values.

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 front-loaded with the most operationally relevant fact (free tier and cost), then gives the resource scope, contents, data-provenance caveat, and value interpretation caveat. Every sentence earns its place and there is 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?

Despite having no output schema, the description lists the major return sections and flags the two caveats most likely to mislead an agent: permit linkage and assessed-vs-market values. With a single well-defined parameter and strong annotations, this is complete enough for correct invocation and interpretation.

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?

There is only one parameter, pin, and the schema already covers it 100% with a pattern and a '14-digit PIN' description. The description repeats that the dossier is keyed by PIN but does not need to add much 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 states a specific verb and resource: it returns a full Cook County / Chicago property dossier for a PIN, and enumerates the major contents (parcel basics, sales/deed history, permits, tax assessment, neighborhood context). The phrase 'one-call due-diligence record' differentiates it from raw open-data lookups and sibling tools like get_cook_county_parcel.

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 clearly positions this as the comprehensive due-diligence call and explains why it is not reproducible via raw open-data queries. It does not explicitly name sibling alternatives or state when to prefer a simpler parcel or address search, but the usage context is clear enough for an agent to select it appropriately.

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 cover safety (readOnly, openWorld, idempotent, non-destructive). The description adds valuable behavioral context beyond annotations: it's 'FREE ($0, unlimited, no payment, no wallet)' and returns representative examples of every response shape. This is more than the annotations provide, though it doesn't detail response structure or size limits, which is acceptable given the sample nature.

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 dense paragraph that front-loads the free aspect and the purpose, then gives usage instruction and alternative. Every sentence carries information, though it could be slightly tightened. The structure is logical and not overly verbose for the information conveyed.

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 no parameters and no output schema, the description compensates fully by explaining exactly what is returned (the list of response shapes), the use case (validation), and the alternative for real data. Nothing an agent needs to call it correctly 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?

There are zero parameters, so the schema fully covers them (100%). Baseline for zero params is 4. The description doesn't need to add parameter semantics, and it doesn't attempt to. The lack of params is itself a clear signal.

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 fixed, representative example of every response shape this server returns for Cook County / Chicago property data' and enumerates the data types (address search, parcel, dossier, comparable sales). It distinguishes itself from siblings by explicitly noting it's a sample for validation, not real 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?

Explicitly instructs to 'Call this FIRST to validate the data structure before anything else.' It also provides an alternative for real data: 'For REAL verified data at $0, call get_cook_county_property_dossier with one of the always-free example PINs...' This gives both when-to-use and when-not-to-use 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?

Annotations already cover readOnly and idempotent, but the description adds important behavioral details: it ranks candidates, provides a match score and match_quality flag with specific meanings ('exact' certain, 'likely' shares house number, 'weak' no house number match). It also discloses that the service is free and unlimited, which is not in annotations. This gives agents a complete picture of what to expect.

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 front-loaded with the key selling point (free, no signup) and then methodically explains the input, output, and usage. Every sentence carries useful information—coverage, match quality, and the follow-up tools. It is a bit long but not redundant.

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 search tool with no output schema, the description is remarkably complete. It explains the output fields (address, city, ZIP, match score, match_quality), the semantics of match_quality, and the expected follow-up actions. An agent would know exactly how to call it and interpret the results.

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 fully describes the 'address' parameter with a min length and example. The description adds a concrete example with trailing city/state/ZIP and clarifies that full or partial addresses are acceptable. While this is helpful, it's a minor addition given the schema already covers the meaning.

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 'Resolve' and the resource 'Cook County / Chicago street address to its parcel PIN(s)'. It also distinguishes this from siblings by explicitly saying to call it FIRST when you have an address but not a PIN, and then pass the pin to sibling tools like get_cook_county_parcel. This leaves no ambiguity about the tool's role.

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 this tool: 'Call this FIRST when you have an address but not a PIN'. It also explains the match_quality flag and warns not to rely on weak hits, providing clear usage boundaries. It doesn't state when not to use it, but the positive guidance is strong enough.

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