Title search, environmental reports, free US property data: loan limits, radon, flood, zoning, LLCs.
Scored across 53 tools
Most tools target distinct data products, but the set contains many geographic and presentation variants that an agent could confuse, such as radon_lookup vs. radon_by_county, fair_market_rent_by_county vs. fair_market_rent_by_zip, and three property tax rate tools. Workflow tools like check_address, check_coverage, order_title_search, get_order_status, and get_report are distinguishable by their descriptions, but the sheer number of similar lookup tools makes selection non-trivial.
Names are consistently snake_case and generally follow readable domain_action or noun_by_geography patterns. There is some variation between verb-first workflow names (check_address, order_title_search) and noun-based lookup names (flood_zone_lookup, county_loan_limits), but the conventions remain predictable.
Fifty-three tools is far more than an agent can reliably navigate for a property data server, with many regional variants and summary/search pairs that could be consolidated or exposed through parameters. The breadth reflects real product coverage, but the set is sprawling and heavy for a single MCP surface.
Coverage is unusually broad: title search ordering, status, reporting, environmental reports, coverage checks, property watch, tax appeals, tax sales, surplus funds, and many property risk lookups are all represented. Minor gaps remain around order cancellation/management and watch-list update/delete operations, but core workflows are well covered.
Building code violations and building permits on record with the city for one address, free, from the city's
own records (the same sources the title search report reads). city: chicago, philadelphia, cincinnati, mesa,
glendale-az (Glendale, Arizona), gilbert, buffalo or provo (list_coverage returns the current list). address:
street address starting with the house number, e.g. "233 S Wacker Dr"; the city is added when missing.
Returns counts over every record on file (total, open, severe, in court, balances due, active / expired permits)
and the most relevant violations and permits: the first 5 of each without an account (`gated: true`, `wall`
holds the true totals and `message` says how a person unlocks the rest on the page; the counts are complete).
Some cities publish only one of the two (Glendale: violations;
Gilbert, Provo: permits). status: 'ok'; 'not_found' (no parcel matches: ask the user to check the address);
'not_searched' (outside city limits: the message says why); 'unavailable' (the city's service did not answer:
not a 'no violations' answer; retry later).| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds substantial context beyond them: results are gated to the first 5 records without an account, 'gated: true' plus 'wall' holds true totals, and some cities publish only one of the two record types. The explicit warning that 'unavailable' is not a 'no violations' answer is exactly the kind of behavioral caveat an agent needs.
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?
Purpose and parameters are front-loaded and every status code earns its place, but the run is dense and slightly run-on, and the aside 'the same sources the title search report reads' adds little for tool selection. Still efficient for the amount of genuinely useful 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?
There is no output schema, yet the description fully documents the return shape (counts over all records, top 5 violations and permits, gating fields) and all four status values. Nothing an agent needs in order to call this correctly or interpret its result 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 0%, so the description must carry the load and it does: it enumerates accepted city values (with glendale-az disambiguated as Glendale, Arizona) and defers to list_coverage for the live list. It also specifies the address format (must start with the house number, example given) and the normalization rule that the city is appended when missing.
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 a specific verb+resource pairing: building code violations and building permits on record for one address, sourced from the city's own records. It is clearly distinct from siblings like property_history_lookup, zoning_lookup or check_address because it names the exact record types and the per-address 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?
Gives concrete usage context (free, per-address, city's own records) and routes to list_coverage for the current city list. Status codes tell the agent what to do next (ask user to check the address on 'not_found', retry on 'unavailable'), though it never explicitly contrasts against a near sibling such as property_history_lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Census tract of a US street address with the designations lenders and tax-credit programs use: the 11-digit tract GEOID (2020 boundaries), the FFIEC 2026 tract income level (low / moderate / middle / upper, from the tract median family income as a percent of the metro or statewide nonmetro median; low and moderate = LMI tract for CRA), HUD Qualified Census Tract status for 2026 and 2027, HUD Difficult Development Area status (by ZIP Code Tabulation Area in metro areas, by county outside them), and Opportunity Zone status. Read from the official lists; a point near a tract boundary can fall in the neighbouring tract, so confirm with the agency before relying on it.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does much of it: it cites the data source ('read from the official lists'), pins the vintages (2020 boundaries, FFIEC 2026, QCT 2026/2027), explains the income-level derivation, and warns that a point near a tract boundary can fall in the neighbouring tract. It omits auth needs, rate limits, and error behaviour, so it falls short of 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?
Purpose is front-loaded in the opening clause, and the long mid-sentence enumeration of return fields is dense but each item earns its place. The trailing boundary caveat is well-placed. It is a single swollen sentence, but there is no filler or repetition.
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 one-input lookup with no output schema and no annotations, the description is unusually complete: it defines every returned designation, their vintages, and the boundary caveat. Remaining gaps, address format handling and response shape, are modest given the tool's simplicity.
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 `address` parameter has 0% schema description coverage, so the description must compensate; it only indirectly constrains the parameter by saying it is a 'US street address'. It adds no format, parsing, or ambiguity guidance (e.g. how a rural route or a PO Box is handled), which is a real gap for the only 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 names a specific verb+resource (census tract of a US street address) and then enumerates exactly what the tool returns: 11-digit tract GEOID, FFIEC income level, HUD QCT/DOA status, and Opportunity Zone status. That output inventory tells an agent precisely which sibling lookups (e.g. opportunity_zone_lookup) this tool subsumes, so it is distinguishable without opening schemas.
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?
Usage is implied by the output list (use when you need tract-level CRA/FFIEC designations), but the description never states when to prefer it over siblings like opportunity_zone_lookup or check_address, nor any prerequisites. The closing caveat about boundary accuracy is a condition on trust, not a when-to-use rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an address BEFORE ordering (takes a few seconds). For a title search (report_type 'current_owner', the
default) give state and county: it matches the address to a real parcel in the county's records. For
report_type 'environmental' only the address is needed: it is matched with the US Census geocoder (any US address).
status 'matched' = safe to order; 'not_found' = ask the user to correct the address; 'not_covered' = the county is
not covered; 'unavailable' = the county / Census service is down right now (a title search can still be ordered
and retries; an environmental order needs the geocoder, so try again later).
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| county | No | ||
| address | Yes | ||
| report_type | No | current_owner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial behavior: expected latency ('takes a few seconds'), the meaning of all four status outcomes, and degraded-mode guidance that differs per report_type when the backend is down. This is context the annotations cannot express.
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?
Front-loaded with the key 'BEFORE ordering' instruction and latency note, and every clause carries information. It is dense as a single paragraph, but the status enumeration earns its space and nothing is 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?
There is no output schema, and the description compensates by fully enumerating the return statuses and their required follow-up actions. For a validation tool with 4 params and no structured output, an agent has everything needed to call it and interpret 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?
Schema description coverage is 0%, so the description carries the full burden, and it does: it documents all four parameters including their conditional requirements and the two recognized report_type values with 'current_owner' as default. It converts bare parameter names into actionable 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?
States a specific verb and resource ('Check an address') and frames it as a pre-order validation step, which cleanly separates it from siblings like order_title_search and check_coverage. The report_type branching makes the scope 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?
Explicitly says to run it 'BEFORE ordering' and gives the exact conditions that determine the call shape: state+county required for report_type 'current_owner', address alone for 'environmental'. It also routes the agent on what to do for each status, including correcting the address on 'not_found' and retrying later on 'unavailable'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a title search can be ordered for a county (or a borough / city such as Brooklyn, Tampa,
Houston). Returns the exact state and county values to pass to order_title_search. (The Environmental Records
Report and the flood / Superfund lookups work at any US address and need no coverage check.)
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| county | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds real behavioral context by stating the tool returns exact state/county values to feed order_title_search, but says nothing about failure modes (e.g. what an uncovered county returns) or rate limits.
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?
Three sentences, all useful, with the core action front-loaded and the exclusion note parenthetically contained. No filler or repetition of the tool name.
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?
There is no output schema, and the description correctly fills that gap by explaining what is returned and where it is used. For a two-parameter read-only check, an agent has everything needed to select and call 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 coverage is 0%, so the description must compensate. It does partly, clarifying that the county input also accepts borough/city names such as Brooklyn, Tampa and Houston, which the bare 'county: string' schema does not convey. It still doesn't explain what form state should take (abbreviation vs full name) or how the returned values pair with the inputs.
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?
States a specific verb (check) and resource (coverage for a title search order) and scopes it to a county/borough/city. It also names the downstream consumer, order_title_search, which separates it cleanly from siblings like list_coverage or check_address.
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?
Gives explicit when-to-use (before ordering a title search) and when-not (Environmental Records Report and flood/Superfund lookups work at any US address and need no coverage check), naming the alternatives that bypass it. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that a property can get a Property Tax Appeal Evidence Pack, before ordering. place: 'Cook' / 'Chicago',
'Philadelphia', or an NYC borough ('Manhattan', 'Brooklyn', 'Queens', 'Bronx', 'Staten Island'). parcel_id
optional: the 14-digit Cook PIN, NYC BBL or Philadelphia OPA account (needed for condo units). Status: matched /
ambiguous (several parcels: ask for the unit's parcel number) / not_found / unavailable (assessor down: retry).
| Name | Required | Description | Default |
|---|---|---|---|
| place | Yes | ||
| address | Yes | ||
| parcel_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and largely does so: it enumerates the four outcome states, explains that 'unavailable' means the assessor is down and should be retried, and notes parcel_id is needed for condo units. It stops short of explicitly stating the call is side-effect-free, though 'check ... before ordering' strongly implies a read.
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?
Front-loaded with the purpose, then the parameter details, then the outcome states — a logical order with almost no filler. The paragraph is dense and reads as one long run-on, but each clause adds information.
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?
No output schema and no annotations, so the status enumeration is essential and present, and the retry guidance covers the failure path. A note on idempotency/side effects would close the last gap, but an agent can call this correctly as written.
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 0%, so the description must compensate and it does: it enumerates accepted `place` values (Cook/Chicago, Philadelphia, NYC boroughs by name) and defines `parcel_id` formats per jurisdiction (14-digit Cook PIN, NYC BBL, Philadelphia OPA account) plus when it is required. This is meaning the schema alone does not convey.
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?
States a specific verb (check) plus resource (property eligibility for a Tax Appeal Evidence Pack) and its position in the workflow ('before ordering'), which cleanly separates it from order_tax_appeal_evidence and get_tax_appeal_evidence in the sibling 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?
'before ordering' gives clear sequencing context and the status descriptions tell the agent what to do next (ask for a parcel number on ambiguous, retry on unavailable). It never names the sibling order/get tools explicitly, so the routing is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FHFA conforming loan limit, FHA loan limit and VA county loan limit for one US county (any of the 3,144
counties in the 50 states and DC), for 1 to 4 unit homes, for the year in effect today, plus next year's once
FHFA (late November) or HUD (December) has published it.
state: two-letter code or name ("TX", "Texas"). county: name or FIPS ("Harris", "Harris County", "48201",
"St. Louis city", "Orleans Parish"). Returns the limits, whether the county is high-cost, HUD's area and median
price behind the FHA limit, the state range, the page URL and sources.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| county | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does disclose meaningful behavior: the year-in-effect semantics and the late-November FHFA / December HUD publication timing for next year's figures, plus the exact contents of the response. It stops short of stating read-only/safety characteristics or any failure behavior for unmatched counties.
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?
Front-loaded with the resource and scope, then parameter formats, then return contents; every sentence adds information. Slightly dense and the inline backticked parameter notes sit mid-paragraph, but 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?
With no output schema, the description correctly enumerates the return fields (limits, high-cost flag, HUD area and median price, state range, page URL, sources), and it covers both parameters and temporal behavior. It does not state whether the tool is read-only or how ambiguous county inputs are resolved, minor gaps for a lookup 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?
Schema coverage is 0%, so the description must compensate, and it does: it documents both required parameters with accepted formats and worked examples, including two-letter vs full state names and county name, suffixed name, or FIPS code, with edge cases like 'St. Louis city' and 'Orleans Parish'.
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?
Names the exact resource (FHFA conforming, FHA and VA loan limits) with a specific scope: one US county, 1-4 unit homes, current year plus next year once published. The county-level scope implicitly and clearly contrasts with the sibling national_loan_limits, so an agent can route without opening either schema.
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?
Usage is implied by the stated scope (single county, current effective year) and the coverage note (any of 3,144 counties), but there is no explicit when-to-use versus alternatives such as national_loan_limits, nor any stated prerequisites. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start watching a property in a covered county for email. address: street address with house number and
city (e.g. '1702 Ellsworth St, Philadelphia'); state: two-letter code; county: county or borough
('Philadelphia', 'Cook', 'Brooklyn'). Returns the watch and, for a new email, access_key + dashboard_url:
the ONLY key to that watch list (no password exists), shown once; give it to the user and tell them to keep it
private. The first check runs within minutes (status 'pending' until the parcel is resolved). An email that
already has a watch list gets an error: its owner adds properties from their own list. The first property is free; each additional
property is $7 a month (cancel any time).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| label | No | ||
| state | Yes | ||
| county | Yes | ||
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses that `access_key` + `dashboard_url` are returned only for a new email, that the key is shown once and is the only credential (no password), that the first check runs within minutes with status 'pending', and that pricing is $7/month after the first free property. These are precisely the behavioral facts an agent needs to relay to a user.
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?
Front-loaded with the action, then parameter formats, then return/credential semantics, then operational and pricing caveats — a logical order. It is dense and nearly every clause carries information, though the run-on sentence bundling parameters and returns into one block is slightly harder to scan than it could be.
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?
There is no output schema, and the description covers the return values (watch, access_key, dashboard_url) and the pending-status behavior, so an agent knows what to expect. The only gaps are the undeclared `label` parameter and a lack of detail about how to subsequently retrieve events, which a sibling handles.
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 0%, so the description compensates by defining address format ('street address with house number and city', with an example), state format (two-letter code), county format (county or borough with examples), and the role of email. The optional `label` parameter is never mentioned, leaving one of five parameters undocumented.
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?
States a specific verb and resource ('Start watching a property in a covered county for `email`') with the scoping condition ('covered county'). It is clearly distinguishable from siblings like list_property_watch_events (which reads events for an existing watch) and property_watch_coverage (which checks eligibility).
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 states the failure condition: an email that already has a watch list gets an error and its owner must add properties from their own list, which effectively tells the agent when not to call this. It doesn't name sibling alternatives (e.g., use property_watch_coverage first to confirm the county is covered), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HUD Fair Market Rents (studio to 4 bedrooms, monthly) for one US county, for the current HUD fiscal year and
the previous one, which year is in effect, the 90-110% voucher payment standard range, whether the area is a
HUD-designated Small Area FMR metro, and the state and national medians.
state: two-letter code or name. county: name or FIPS ("Harris", "Cook County", "17031"). New England counties
list each HUD area with its towns.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| county | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full behavioral burden and largely does so by enumerating the payload: current and prior fiscal year, which year is in effect, the 90-110% voucher payment standard range, Small Area FMR metro status, and state/national medians. It also flags the New England exception where HUD areas are listed with their towns. It does not state permissions, rate limits, or error behavior, which is a modest gap for a read-only reference lookup.
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?
Information-dense and front-loaded: what you get first, then argument formats. The single long sentence listing return fields is a bit run-on but every clause carries distinct semantic content; nothing is 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?
With no output schema, the description must describe returns and it does so thoroughly, including derived fields like the effective year and voucher range. It stops short of mentioning error/coverage behavior, notable given sibling coverage tools such as check_coverage and list_coverage, but nothing essential for a correct call 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 description coverage is 0% — both properties carry only bare titles — and the description fully compensates by specifying accepted formats for each: state as a two-letter code or name, county as name or FIPS, with literal examples ('Harris', 'Cook County', '17031'). This is the exact information an agent needs to build a valid call.
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 a precise verb+resource+scope: 'HUD Fair Market Rents (studio to 4 bedrooms, monthly) for one US county.' The county-level granularity, plus the explicit fiscal-year coverage, tells an agent exactly what this returns and implicitly separates it from the fair_market_rent_by_zip sibling.
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?
Use is implied by the stated geographic scope (a single county) and the enumeration of returned fields, so an agent can infer applicability. However, no sibling is named and there is no when-not-to-use guidance (e.g., 'use fair_market_rent_by_zip for ZIP-level FMRs'), so selection still requires inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HUD Small Area Fair Market Rents for a 5-digit ZIP code (studio to 4 bedrooms, current and previous HUD fiscal year), with the 90-110% payment standard range and whether the metro is one of HUD's 65 designated Small Area FMR areas (where housing agencies must use the ZIP figures). Non-metropolitan ZIP codes have none: use fair_market_rent_by_county for those.
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses important return context: studio-to-4-bedroom rents, current and previous fiscal year, the 90-110% payment standard range, and the metro designation status, plus the key limitation that non-metropolitan ZIPs return nothing. It does not cover auth/rate limits or exact error behavior, but for a read-only lookup it gives solid behavioral context.
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 with no wasted words. The first sentence front-loads what data is returned, and the second sentence handles the routing exception concisely.
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?
There is no output schema, so the description must convey return content; it does so by enumerating bedroom counts, fiscal years, payment standard range, and metro designation. However, it does not describe the exact response shape or field names, leaving a minor gap for an agent that needs to parse the output.
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 0%, so the schema only says 'Zip Code' as a string. The description adds meaningful semantics by specifying that the parameter is a 5-digit ZIP code. It does not clarify edge cases such as leading zeros or invalid ZIP handling, but it compensates for the main missing schema detail.
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?
States a specific resource (HUD Small Area Fair Market Rents) and key scoping details (5-digit ZIP, studio to 4 bedrooms, current/previous fiscal year). It clearly distinguishes itself from fair_market_rent_by_county by explaining that non-metropolitan ZIPs have no 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 routes the agent to fair_market_rent_by_county for non-metropolitan ZIP codes, which is the key when-not condition for this tool. The implied use case is also clear: obtain ZIP-level Small Area FMR data including payment standards and designation status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USGS-mapped earthquake faults near a US street address: every mapped fault section within 5 miles, nearest first (name, section, distance in miles and feet, direction, age of the most recent movement from 'historic' (< 150 years) to 'undifferentiated Quaternary' (< 1.6 million years), slip rate and sense, mapping scale, USGS report link), or the nearest mapped fault within 100 miles; plus the USGS 2014 seismic hazard map value (peak ground acceleration with a 2% chance of exceedance in 50 years, %g). Takes a few seconds. Returns the tool page URL. Mapped faults only: not a geotechnical or fault-rupture assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses runtime ('takes a few seconds'), a side-effect-ish return (the tool page URL), the radius thresholds and fallback logic, and the value ranges for fault age categories. It omits any auth/permission or rate-limit notes, which keeps it below a 5, but the operational profile is unusually well surfaced.
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?
Effectively one long but front-loaded paragraph that leads with the core result and follows with radius logic, field list, and scope caveats. Dense and information-rich with almost no filler, though the parenthetical field enumeration is heavy for a single breath.
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 with no output schema, the description fully documents what is returned (fields, distance units, age categories, hazard value), how far it searches, and the fundamental limitation of the data. Nothing an agent needs to invoke or interpret it 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?
One parameter with 0% schema description coverage, so the description must compensate. It qualifies the address as a 'US street address,' adding a geographic/format constraint the bare string schema lacks, though it doesn't spell out accepted formats (ZIP, suite, etc.).
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?
States a specific verb and resource ('USGS-mapped earthquake faults near a US street address') and immediately delineates scope (mapped fault sections within 5 miles, with a 100-mile fallback). An agent can distinguish it from near-address siblings like power_lines_near_address and superfund_sites_near_address without opening any schema.
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?
Gives clear context for when the tool applies (address-based USGS fault lookup) and an explicit exclusion ('Mapped faults only: not a geotechnical or fault-rupture assessment'). It stops short of naming alternative sibling tools, so an agent must infer routing, but the applicability boundary is well drawn.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FEMA flood zone at a US street address (any of the 50 states or DC), free. address = full street address
with house number, city and state, e.g. "1600 Pennsylvania Ave NW, Washington, DC 20500".
Returns the zone (A/AE/V/VE = Special Flood Hazard Area, shaded X = 0.2% annual chance, X, D), a plain-language
label and explanation, whether federal rules require flood insurance for a federally backed mortgage, base flood
elevation where FEMA publishes one, and a FEMA Flood Map Service Center link for the official map panel.
status: 'ok'; 'invalid' (the address could not be matched: the message says why; ask the user to correct it);
'unavailable' (the flood map or the address lookup did not answer: the zone was NOT determined, this is never a
'no flood zone' answer; retry later); 'rate_limited'. Always tell the user this is a screening from FEMA's
layer, not an official flood zone determination (lenders use FEMA's Standard Flood Hazard Determination Form).| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld annotations: it enumerates the returned zone codes and their meanings, insurance implications, base flood elevation, and map link, and it spells out all four status values with recovery actions. It also discloses the key limitation (screening only, not FEMA's official SFHDF) and the idempotent/retry-safe nature of 'unavailable'.
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?
Front-loaded with the purpose and address format, then output shape, then status handling and the disclaimer — a sensible order. It is longer than typical, but with no output schema each clause carries needed information; only the trailing disclaimer sentence is slightly padded.
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?
There is no output schema, yet the description fully documents return values, zone semantics, elevation/link fields, and every status code with the agent's recovery action. For a single-parameter lookup with rich annotations, nothing an agent needs to call and report 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?
Schema description coverage is 0%, so the description carries the burden, and it does: it defines `address` as a full street address requiring house number, city and state, and supplies a concrete formatted example. Minor gaps remain (whether ZIP or unit numbers are accepted/ignored, how to handle non-street addresses), keeping it just short of 5.
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?
States a specific verb and resource ('FEMA flood zone at a US street address') with explicit geographic scope (50 states or DC) and cost ('free'). It is immediately distinguishable from the other address-based lookups in the sibling list (radon, superfund, fault lines, zoning) because the resource is named precisely.
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 actionable guidance for each outcome: on 'invalid' ask the user to correct the address, on 'unavailable' retry later, and it explicitly warns that 'unavailable' is never a 'no flood zone' answer. It also instructs the agent to always frame results as a screening, not an official determination. No sibling tool competes for this job, so the absence of an explicit 'use X instead' clause is a minor gap only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Progress of an order (title search or environmental): status ('pending', 'processing', 'complete', 'failed'), per-source progress, and the error message if it failed. When complete, call get_report.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuine behavioral context: the closed set of status values, that progress is reported per source, that failures surface an error message, and that completion should be followed by get_report — implying a polling lifecycle. It omits polling cadence/rate limits.
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 tight sentences with zero filler; the resource and status enumeration are front-loaded and the follow-up action is placed last where it belongs.
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?
With no output schema, the description usefully carries the return-value burden by naming status, per-source progress, and the error field. Only the parameter provenance and polling guidance are missing for a single-parameter status 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?
Schema description coverage is 0% and the description never explains order_id — where it comes from (presumably returned by order_title_search), its format, or its lifetime. The parameter name is self-describing, which limits the damage, but the description does nothing to compensate for the schema gap.
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?
States a specific verb-equivalent ('Progress of an order') plus the resource and enumerates what is returned: status values, per-source progress, and error message. It implicitly separates itself from order_title_search (which creates orders) by describing a progress-check, but never names that sibling explicitly.
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?
'When complete, call get_report' gives a clear conditional next step, which is real routing guidance. It stops short of telling the agent when to call this tool (i.e., poll it after order_title_search) or how often, so it isn't full when/when-not/alternative coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The finished report as structured JSON. Title search: property and owner of record, risk score and summary, key findings, chain-of-title counts, environmental and tax data, sources searched with their status. Environmental report: every federal list searched with the records found and their distances, site facts and sources. Also returns the PDF link. Only works once get_order_status reports 'complete'.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds the readiness precondition and the PDF-link side output — behavior beyond the annotations. It stops short of noting pagination, size, or whether repeat calls re-fetch, so it earns credit but not full marks.
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 lead sentence 'The finished report as structured JSON' correctly front-loads the core fact, and the enumerations are informative rather than redundant. However, the single most operationally important constraint ('Only works once get_order_status reports complete') is buried at the very end, weakening the structure.
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?
With no output schema, the description carries the full burden of describing returns, and it does so thoroughly — splitting title-search vs environmental-report payloads and noting the PDF link. Combined with the completion precondition, an agent has everything needed to call it 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?
There is one required parameter (order_id) with 0% schema description coverage, so the description must carry the burden. It only indirectly implies that order_id identifies an order ('once get_order_status reports complete') without stating the format, source, or that this is the order identifier. Partial compensation, so a baseline 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 states a clear resource — the finished report — and enumerates exactly what it contains for each report type (title search fields, environmental report fields, PDF link). It implicitly distinguishes itself from get_order_status and get_sample_report via the content and the naming of the status dependency, though it never uses an explicit retrieval verb. An agent can tell what this returns without opening the schema.
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 closing sentence 'Only works once get_order_status reports complete' is a precise precondition that explicitly names the sibling tool to check first — strong when-to-use guidance. It does not, however, state what to do in the not-complete case or name any other alternative, leaving part of the routing implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A real finished report to look at before ordering. report_type 'current_owner' (default): the title search for 350 Fifth Avenue, New York (Empire State Building). 'environmental': the Environmental Records Report for 300 Bond Street, Brooklyn. Returns the page and the PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| report_type | No | current_owner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is lighter. It adds genuinely useful behavior: that the content is real finished output rather than mock data, and that the response includes both the page and the PDF.
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?
Purpose is front-loaded in the first sentence, then the two enum branches and the return shape follow in order. The street addresses are a touch verbose but they earn their place by making the two samples concretely distinguishable.
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?
There is no output schema, so the description correctly summarizes the return ('the page and the PDF'). With one optional enum parameter, rich annotations, and no nested objects, this is sufficient for correct invocation; only pagination or size expectations are unaddressed.
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 0%, so the description must carry the parameter meaning, and it does: it explains that the default 'current_owner' is a title search and 'environmental' is an Environmental Records Report, anchoring each enum value to a concrete sample. The default value is also restated, leaving nothing ambiguous.
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 resource (a real, finished sample report) and its purpose ('to look at before ordering'), which cleanly separates it from get_report and order_title_search by framing it as a preview artifact. It stops short of naming the sibling it is not, but the sample-vs-real distinction is 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?
'Before ordering' gives a clear use context and implies the tool is a pre-purchase preview rather than a data retrieval call. There are no explicit exclusions or named alternatives, so it lands at clear-context-but-no-routing rather than full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The finished Property Tax Appeal Evidence Pack as JSON (assessments, appeals, comparable sales, ratio check, deadlines, sources with pull dates, anything NOT RETRIEVED) and its PDF link. Works once the order is complete.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the payload composition (assessments, appeals, comparable sales, ratio check, deadlines, sources with pull dates, anything NOT RETRIEVED) and the completion precondition, which is useful. It says nothing about permissions, auth requirements, error behavior for an incomplete/unknown order_id, or rate limits.
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, front-loaded with the return payload and followed by the precondition. The long parenthetical inventory is dense but each item is informative; 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?
With no output schema, the description usefully enumerates the return contents and gives a precondition. However, it leaves order_id semantics undocumented and provides no guidance on failure modes (incomplete order, invalid id), so it is adequate but not complete for a tool keyed entirely on one opaque parameter.
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 order_id parameter has 0% schema description coverage and no enum, and the description never mentions it or its format/source. The agent must infer that order_id comes from the ordering tool; the description adds no 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?
States a specific resource (the finished Property Tax Appeal Evidence Pack) and enumerates its contents plus the PDF link, so an agent knows exactly what comes back. It does not explicitly name the ordering sibling order_tax_appeal_evidence, but the 'finished'/'once the order is complete' framing makes the retrieval-vs-order distinction inferable.
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?
'Works once the order is complete' gives a clear precondition that routes the agent: an order must exist before calling this. There is no explicit statement of what to do if the order is not yet complete (e.g., use order_tax_appeal_evidence or poll get_order_status), so it falls short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status and result of a tax sale due diligence batch: per parcel, the debts found with amounts and the effect of the sale, every check's status (found / none found / not searched / did not answer) and the cited rules; plus CSV and PDF links. 'Not searched' never means there is no debt.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add real value by enumerating the possible check statuses (found / none found / not searched / did not answer) and warning that 'not searched' never means there is no debt, which prevents a costly misreading. However, it omits the async dimension of a batch job (whether the batch may still be running, whether polling is required) and any auth or error behavior.
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?
Front-loaded with the core purpose, followed by a dense but useful enumeration of return contents and a single high-value caveat sentence. The middle clause is heavy but every element earns its place; 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?
With no output schema and no annotations, the description does a decent job of covering return values (per-parcel debts, sale effect, check statuses, cited rules, CSV/PDF links). But it leaves the job_id origin, the batch's async/polling behavior, and the relationship to start_tax_sale_due_diligence unexplained, so an agent lacks a complete workflow picture.
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 job_id is not described at all, and schema description coverage is 0%. The description implies job_id identifies a 'batch,' which gives a weak hint, but it never says where the id comes from (the start_tax_sale_due_diligence sibling) or its format, so it fails to compensate for the coverage gap.
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 the status and result of a tax sale due diligence batch, and details exactly what 'result' contains (per-parcel debts, sale effect, check statuses, CSV/PDF links). It is clear what the tool does, but it never names the sibling start_tax_sale_due_diligence or otherwise explicitly differentiates itself from the many other get_* tools.
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?
There is no when-to-use guidance, no statement of prerequisites (e.g. that job_id must come from start_tax_sale_due_diligence), and no alternatives or exclusions. The agent can infer it reads an existing batch's results, but nothing is stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Terms, privacy, refund policy and the legal boundary of every product (what a report or lookup is and is not).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as a read-only, idempotent, non-destructive, closed-world operation. The description adds useful content scope, especially the 'legal boundary of every product (what a report or lookup is and is not)', but does not disclose return format, auth requirements, or any behavioral limits beyond 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?
It is a single sentence with no filler and the content list is front-loaded. However, the phrasing is a fragment rather than a clear action statement, which slightly reduces structure quality.
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 zero-parameter read-only tool with rich annotations and no output schema, the description gives enough content scope to know what will be returned. It could be improved by explicitly stating the return format, but it is largely complete for this simple operation.
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 tool has zero parameters, and per the scoring baseline, no parameter semantics are needed. The description appropriately avoids inventing or implying parameter details.
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 the specific resource content: terms, privacy, refund policy, and the legal boundary of products. It is a noun phrase rather than a verb-led statement, so the action ('get') is only implied by the tool name. It distinguishes this tool from sibling data lookups by focusing on legal/policy boundaries, but does not explicitly contrast with any sibling.
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 when-to-use guidance is provided. The description hints at what the terms cover, but offers no conditions, prerequisites, or alternatives for deciding between this and other sibling tools such as get_report or list_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which homeowners' association (HOA / POA / condo association) may govern an address, from the official state
registries: Texas (HOA management certificates filed with the state, matched by ZIP code and the subdivision words in the appraisal
district's legal description) and Utah (Department of Commerce HOA Registry, matched through the Utah County
subdivision name). address: full street address with city and state. community (optional): the subdivision or
community name, which ranks the candidates. Returns candidates with how each matched, the management certificate PDF
(Texas) or registration number, status, expiry and management company (Utah). Candidates only: the recorded
declaration (CC&Rs) on the lot decides. Other states: status 'unsupported' with guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| community | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full load, and it does well: it discloses the matching methodology (ZIP code plus subdivision wording from the appraisal district legal description in TX; county subdivision name in UT), what the response contains per state, and the explicit epistemic limit that candidates are not authoritative. It omits cost/auth/rate-limit and ordering behavior, which keeps it short of 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?
The purpose and supported states are front-loaded, and the parenthetical matching mechanics earn their place by explaining why results may be fuzzy. The single dense paragraph mixes purpose, parameters, and return values, which is slightly harder to scan than separated sections but wastes little.
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 2-parameter read lookup with no annotations and no output schema, the description supplies the missing return-shape information (match explanation, certificate PDF or registration number, status, expiry, management company) and the cross-state coverage limit. Nothing an agent needs to call or interpret it 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 0%, so the description must compensate, and it does: `address` is specified as a full street address with city and state, and `community` is described as an optional subdivision/community name that ranks candidates — the ranking effect is genuinely new information beyond the schema. Format examples or the matching failure mode for a malformed address are absent.
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?
States a precise verb+resource: identifying which HOA/POA/condo association may govern an address, and names the two official sources (Texas HOA management certificates, Utah Department of Commerce registry). The resource is unmistakably distinct from siblings like zoning_lookup or check_address, so an agent can route here without ambiguity.
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?
Coverage boundaries function as usage guidance: only Texas and Utah are supported, and other states return 'unsupported' with guidance, which effectively tells the agent when not to expect results. The caveat that results are candidates only and that recorded CC&Rs decide is a clear interpretive constraint. It stops short of naming an alternative sibling for the states it does not cover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where each HeritageDeed product works. Title search: the states and counties (with main cities) where a report can be ordered, what it includes and does not, and the price. Also: the Environmental Records Report, flood zone and Superfund lookups (any US address), the cities with building records, the places with property history, the counties with surplus funds and tax sale lists, and the calculators' states. Call this before ordering if you are unsure of the county; the list is live (new counties appear automatically).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the list is live and 'new counties appear automatically,' which tells the agent results can change over time and it need not cache. It does not describe the return structure in detail, but the liveness note is real added value beyond 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?
The leading clause is well front-loaded ('Where each HeritageDeed product works'), but the remainder is a long, comma-chained enumeration of product categories and coverage dimensions that is dense and somewhat run-on. It earns most of its length through informational scope, but the structure could be tighter.
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?
There is no output schema, so the description carries the burden of explaining returns, and it does so reasonably: it tells the agent the response covers which states/counties/cities, what a title search includes and excludes, and pricing. Combined with full annotation coverage, this is complete enough to call the tool correctly, though the relationship to check_coverage remains unstated.
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 tool takes zero parameters, so there is nothing for the description to disambiguate and the rubric baseline of 4 applies. No parameter-related gaps exist.
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?
States a specific resource and scope: 'Where each HeritageDeed product works,' then enumerates the coverage categories (title search, environmental report, flood/Superfund, building records, property history, surplus funds, tax sales, calculators). The purpose is clear. However, it never distinguishes itself from the sibling check_coverage, whose name suggests a very similar coverage-check function, so an agent cannot fully disambiguate from the description alone.
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 an explicit usage trigger: 'Call this before ordering if you are unsure of the county.' That is actionable context. It stops short of naming when-not-to-use or pointing to check_coverage as the alternative for a specific-address coverage check, so it does not reach the routing precision of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every HeritageDeed product available through this server: the two reports (ordered with order_title_search) and each free lookup or calculator, with a one-line description and its tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so safety is covered structurally. The description adds genuinely useful return context that no schema provides (there is no output schema): each product comes with a one-line description and its associated tools. It does not discuss response format or size, but for a zero-argument catalog this is solid added value.
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?
A single front-loaded sentence that names the resource first and then qualifies the two product categories, with zero filler. Every clause carries information an agent can act on.
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?
With no parameters, no output schema and a simple catalog purpose, the description covers the essential behavior plus the shape of the result (one-line description and tools per product). It is nearly complete; only explicit invocation guidance and any ordering/nesting of the returned list are 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?
The tool takes no parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify, and it correctly implies the call is unconditional and argument-free.
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 action and resource: it enumerates every HeritageDeed product, splitting them into the two paid reports and the free lookups/calculators. It also names the sibling tool order_title_search that the paid reports route through, which helps an agent place it in the catalog. It is clear but does not fully differentiate itself from the many lookup siblings beyond being the index of them.
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?
Use is implied — an agent would call this to discover which products exist before choosing a lookup or ordering a report — and it explicitly points to order_title_search for report ordering. However, there is no explicit when-to-use/when-not statement, e.g. that this is the entry point before invoking any specific lookup, so the routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a watch list with its access_key ('wk_...', from create_property_watch or the dashboard link after
'#k='). Without watch_id: every watched property with its status, last check and unseen event count. With
watch_id: that property's events, newest first: kind (deed_recorded, mortgage_recorded, lien_recorded,
lis_pendens_recorded, owner_changed, violation_new, tax_sale_listed, surplus_listed, court_case, ...), severity
(high / medium / low / info), title, date, official source link. People's names are initials.
| Name | Required | Description | Default |
|---|---|---|---|
| watch_id | No | ||
| access_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden, and it does well: it discloses event ordering (newest first), the event kind vocabulary, severity levels, and the privacy behavior that names are initials. It omits auth failure behavior, pagination, and rate limits.
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?
Front-loaded with the access_key sourcing, then the two modes in sequence; the event-kind enumeration is dense but earns its place by telling the agent what to expect. The dashboard-link parenthetical is slightly verbose but practically useful.
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 dual-mode read tool with no annotations, no output schema, and 0% schema coverage, the description covers invocation and return shape (kind, severity, title, date, source link) well. Edge cases like invalid keys or result limits are not addressed.
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 0% schema coverage, the description fully compensates: it explains access_key's 'wk_...' prefix and where to obtain it (create_property_watch or the dashboard '#k=' link), and defines watch_id's dual role as an optional filter rather than restating the 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?
States a specific verb and resource ('Read a watch list') and explicitly describes the two operating modes keyed on watch_id. An agent can distinguish this read-back tool from create_property_watch without opening the schema.
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?
Clearly specifies when each mode applies: omit watch_id to list all watched properties with status, include watch_id to pull that property's events. No exclusion or alternative-sibling routing is given, but the branch conditions are explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who owns / is behind an LLC or corporation, from official sources. mode='name': query is the business name
(e.g. 'ESRT Empire State Building LLC'); mode='address': query is a street address and the owner of record there
is looked up first (NYC, rest of New York State, Philadelphia, Illinois, Texas, Utah County), then the entity.
state (two letters, optional) limits the registry search to one state; registries searched: NY, TX, PA, CO, CT, OR
(official open data). Returns: registry records (status, formation date, entity type, principal office, registered
agent, officers/principals where the state publishes them, link to the official record), and properties recorded to
that exact entity name in NYC ACRIS (deeds, mortgages), NYC HPD registrations, NY State assessment rolls, Philadelphia
OPA and Illinois PTAX-203 transfer declarations (with the declared signer's title). People appear only as initials.
New York does not publish LLC members; Florida (Sunbiz) is not searched automatically (its link is returned).
Refuses a person's name: business entities only.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | name | |
| query | Yes | ||
| state | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses data sources, what appears in results (records, properties, titles), and real limitations ('People appear only as initials', 'New York does not publish LLC members', Florida link-only). These constraints materially affect interpretation of results.
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?
Front-loads purpose, then mode, then state, then returns — a logical order. Dense but nearly every clause carries information; the registry list and parenthetical source names are slightly long, though they are genuinely useful detail.
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?
No output schema and no annotations exist, so the description must cover both behavior and returns — it does, enumerating records fields and the properties sources. Refusal conditions and coverage gaps (NY members, Florida) are stated, leaving little an agent needs to infer.
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 0%, so the description must compensate, and it does: it defines mode semantics for both values, explains query's meaning per mode with a concrete example, and specifies `state` as two letters that limits registry search. All three parameters are meaningfully documented where the schema is silent.
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?
Specific verb and resource ('Who owns / is behind an LLC or corporation, from official sources') plus an explicit scope boundary ('Refuses a person's name: business entities only') that separates it from people-oriented siblings like nyc_landlord_lookup. An agent can identify the tool's remit without opening the schema.
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 distinguishes mode='name' from mode='address' with examples and explains the effect of `state`. Includes a clear when-not ('Refuses a person's name: business entities only') and notes Florida is not searched automatically. It stops short of naming an alternative sibling for the person-name case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This year's national loan limit figures (FHFA conforming baseline and high-cost ceiling, HUD FHA floor and ceiling, for 1 to 4 units), next year's once announced, and each state's lowest and highest county limits. Use county_loan_limits for one county.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses data-freshness behavior ('next year's once announced'), which tells the agent the next-year figures may be absent. It does not state that the operation is read-only or describe caching/rate limits, but for a parameterless lookup those are low-risk gaps.
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?
Three tight sentences with no filler. The scope of returned figures is front-loaded and the routing hint to the sibling is placed last, which is the right position for a secondary consideration.
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?
There is no output schema, so the description must convey return content, and it does: it enumerates the FHFA and HUD figures, the unit range (1-4), the current and next-year vintages, and the state-level low/high county limits. An agent knows exactly what it will get back and when to prefer the county-level sibling.
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 tool takes zero parameters, so the schema has nothing to document and the baseline is 4. The description correctly implies no input is required and instead spends its words on what is returned.
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?
Names the specific resource (national loan limit figures) and enumerates the exact figures returned: FHFA conforming baseline and high-cost ceiling, HUD FHA floor and ceiling, for 1-4 units, plus next year's and per-state county extremes. It explicitly distinguishes itself from the sibling county_loan_limits, so an agent can choose between them without opening either schema.
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?
States the selection rule outright: 'Use county_loan_limits for one county.' That is an explicit alternative with the condition that selects it, leaving nothing to inference for a zero-parameter lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NYC 'who is my landlord': the building's HPD Multiple Dwelling Registration by address. borough is one of
manhattan, brooklyn, queens, bronx, staten-island; address is the street address with house number (e.g. '2400
Davidson Ave'). Returns registration status (current or expired, end date), the registered owner (company name, or
initials for a person), head officer and officers (initials), managing agent company, HPD violation counts (open by
class A/B/C), the grantee on the newest ACRIS deed for comparison, and the HPD Online link with the full registration.
status 'not_registered' means HPD has no registration on file (not 'no owner').
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| borough | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it lists the returned registration status, owner/officer/managing-agent details, violation counts, ACRIS grantee comparison, and HPD link. It also clarifies the important semantic edge case that 'not_registered' means no HPD registration on file, not 'no owner', though it does not mention permissions or rate limits.
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 purpose and then packs parameter rules and return details without filler. It is somewhat dense and long, but every clause adds useful specification.
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 a two-parameter lookup with no output schema and no annotations, the description is largely complete: it covers inputs, return contents, and a key status interpretation. Its main remaining gap is sibling differentiation rather than basic call correctness.
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 0%, so the description must compensate. It does so by defining the allowed borough values and describing the address format with a concrete example, which is meaningfully more than the bare schema 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?
States a specific verb and resource: looking up a building's HPD Multiple Dwelling Registration by address, framed as NYC 'who is my landlord'. It clearly describes the output domain, though it does not explicitly distinguish itself from siblings such as building_records_lookup or llc_owner_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?
The phrase 'who is my landlord' implies the use case, and the description explains required inputs well. However, it gives no explicit when-to-use guidance, prerequisites, or alternatives for the several adjacent lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is a US street address in a designated Qualified Opportunity Zone? Checks the address's 2010 census tract (the boundaries the designated zones keep) against the official list (IRS Notice 2018-48 and Notice 2019-42, 8,764 tracts; designations end December 31, 2028, Puerto Rico's December 31, 2027), and its 2020 tract against the Rev. Proc. 2026-14 list of tracts ELIGIBLE FOR NOMINATION as 2027 zones (eligible is not designated: governors nominate, Treasury designates, new zones run January 1, 2027 to December 31, 2036). designated null = the 2010 tract service did not answer (not a no). Not tax advice.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and largely meets it: it discloses the data sources, the sunset dates (2028/2027), the meaning of a null designated value, and a 'not tax advice' disclaimer. It omits practical traits like whether this is a read-only call or any rate/latency/auth notes, but the domain disclosure is unusually rich.
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 core question is front-loaded, which is good, but the body is a dense run-on of parenthetical citations (Notice 2018-48, Notice 2019-42, Rev. Proc. 2026-14, multiple dates) that is hard to scan. Much of it earns its place as domain context, but it is not well-structured for quick agent consumption.
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?
There is no output schema, so the description has to explain the return shape, and it does reasonably: it distinguishes the 2010-tract designation result from the 2020-tract eligibility result and clarifies that a null designated value means 'no answer,' not 'no.' That covers the main ambiguity an agent would hit when calling and interpreting a result.
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 0% and the single parameter is undocumented in the schema, so the description must compensate. It establishes that the input is a 'US street address' (implying geography and format constraints), but says nothing about parsing expectations, unit/format, or what happens with malformed or non-US input, so it adds only marginal 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 first sentence states a specific question-answering verb and resource ('Is a US street address in a designated Qualified Opportunity Zone?'), and the follow-up sentences pin down the exact matching logic (2010 tract vs. designated list, 2020 tract vs. eligibility list). This distinguishes it cleanly from neighbors like census_tract_lookup and check_address.
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?
It makes clear what each result dimension means and when it applies (2010 tract for current designations, 2020 tract for 2027 eligibility), which is strong interpretive context. However, it never explicitly names an alternative tool or states when NOT to use this one, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Order a Property Tax Appeal Evidence Pack (PDF + JSON): the parcel's assessment history, appeal outcomes on record, comparable sales, a neighborhood assessment-to-sale ratio check computed from the assessor's own data, and the filing deadline with the official route. $49 per pack. Then poll get_order_status(order_id) until 'complete' (about a minute) and call get_tax_appeal_evidence(order_id). Data only: no appeal is filed and no one is represented.
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| place | Yes | ||
| address | Yes | ||
| parcel_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses the $49 charge, the asynchronous ~1-minute completion, the required polling loop, and the 'data only – no appeal filed, no representation' legal scope. It omits failure/refund behavior and what happens if the parcel is not found, which are the remaining gaps for a paid mutation.
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 payload contents are front-loaded, followed by price and the follow-up workflow in the same compact block. It is dense but every sentence carries information; only the parenthetical content list 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?
For a paid, asynchronous ordering tool with no output schema and no annotations, the workflow and cost are covered well enough to call it. But the completely undocumented parameters and unspecified error/refund paths leave meaningful holes a caller must guess at.
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 0% across 4 parameters (address, place, parcel_id, email), so the description must compensate and it does not: no parameter is mentioned or explained. An agent cannot tell whether 'place' is a city, county, or state, whether parcel_id is preferred over address, or whether email is needed to receive the pack.
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?
States a specific verb ('Order') and resource ('Property Tax Appeal Evidence Pack') and enumerates the pack's contents: assessment history, appeal outcomes, comparable sales, ratio check, and deadline. It is clearly distinct from the sibling get_tax_appeal_evidence (retrieval) and check_tax_appeal_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?
Gives an explicit end-to-end sequence: order, then poll get_order_status until 'complete', then call get_tax_appeal_evidence(order_id), with an expected duration. It lacks exclusions, e.g. it never says to run check_coverage or check_tax_appeal_property first, so the agent is not routed to prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Order a report for a property. report_type 'current_owner' (default) = the title search report: address is
the street address (house number, street, city, ZIP), state the two-letter code, county the county (or
borough / city alias); only covered counties (check_coverage). report_type 'environmental' = the Environmental
Records Report for any US street address: give the full address with city and state; state and county are not
needed (they come from the Census geocoder). Returns an order_id; then poll get_order_status every ~20 seconds
until status is 'complete' (usually 1 to 3 minutes) and call get_report. Costs $49 for a title search and $29 for an
Environmental Records Report. email is optional (used only for the report link; nothing is sent while email delivery is off).
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| state | No | ||
| county | No | ||
| address | Yes | ||
| report_type | No | current_owner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag openWorldHint/idempotentHint=false; the description adds the far more actionable traits: exact costs ($49 vs $29), expected latency, polling cadence, the check_coverage prerequisite, and the important caveat that email delivery is currently off so 'nothing is sent'. That is real behavioral context, not restatement.
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?
Front-loaded with the core action and report-type branch, and every sentence carries operational value (prerequisites, cost, polling). It is a single dense paragraph, however, so the branching for the two report types takes effort to parse rather than being visually separated.
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?
There is no output schema, and the description compensates by stating what is returned (an order_id) and exactly what to do with it. For a paid, asynchronous, non-idempotent order tool, the cost, latency, prerequisite coverage check, and downstream calls are all present.
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 0%, so the description must carry all five parameters — and it does: address format (house number, street, city, ZIP), state as two-letter code, county accepting borough/city aliases, report_type enum semantics for both values, and email's limited purpose and optionality. It also notes state/county are ignored for the environmental 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?
States a specific verb and resource ('Order a report for a property') and then splits the resource into two explicitly named report types with distinct semantics. An agent can immediately distinguish this from siblings get_report and get_order_status, which are only downstream steps.
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?
Gives explicit routing conditions: title search only for covered counties (via check_coverage), environmental for any US street address. It also spells out the required follow-up workflow — poll get_order_status every ~20 seconds until 'complete' (1-3 min), then call get_report — leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
High-voltage electric transmission lines (100 kV and above) near a US street address, from federal infrastructure data: every mapped line within 1 mile, nearest first, with distance in feet and miles, direction, voltage, owner as recorded, the two substations it connects and its status, plus counts within 500 ft, 1/4, 1/2 and 1 mile. Local distribution lines on street poles are NOT in the data. Returns the tool page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does much of it: it discloses the data source (federal infrastructure data), the 1-mile search radius, the sort order ('nearest first'), the units (feet and miles), the aggregation buckets (500 ft, 1/4, 1/2, 1 mile), and the page URL return. It omits access constraints, coverage limitations for non-US addresses, and any failure behavior.
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?
Information is front-loaded with the resource and scope first, then the returned fields, then the exclusion. It is a single dense block of clauses that drifts into a long comma list, but nearly every clause carries distinct information.
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?
With no output schema and no annotations, the description supplies the return shape, search radius, sorting, and units, which is what an agent needs to interpret results. What remains missing is handling for uncovered or invalid addresses — relevant given the existence of check_coverage and check_address siblings.
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 exists and the schema provides no description (0% coverage), so the description must compensate. It adds the meaningful constraint that the address must be a 'US street address', but says nothing about format expectations (free-form single line vs. components) that would help an agent construct a valid value.
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 resource with hard boundaries: 'High-voltage electric transmission lines (100 kV and above) near a US street address, from federal infrastructure data.' It also carves out what the tool does NOT cover ('Local distribution lines on street poles are NOT in the data'), which separates it from general utility-line inquiries and from the sibling fault_lines_near_address tool by naming the data domain.
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?
Usage is implied rather than stated: an agent can infer this is for transmission-line proximity screening at an address, and the distribution-line exclusion prevents one misuse. But there is no explicit when-to-use guidance and no mention of alternatives such as fault_lines_near_address or check_coverage for addresses outside the data set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What has been recorded against a property, from the official parcel-keyed land records index, free.
place: manhattan, brooklyn, queens, bronx, staten-island, philadelphia, cook (Cook County IL, Chicago),
hamilton (Hamilton County OH, Cincinnati) or utah (Utah County UT, Provo/Orem); county or city names work too.
address: street address starting with the house number; in Hamilton and Utah counties add the city after a
comma (e.g. "851 W 300 S, Orem"), since street addresses repeat between towns.
Returns counts of recorded documents by kind (transfers, mortgages, releases, other) and by year, document
types, the first and latest recorded event, the transfers with date, type and recorded consideration (the
first 5 without an account: `gated: true`, `wall.total` is the true count, `message` says how to unlock the rest), the
parcel id and index searched, and building record counts where available. People's names are masked to
initials; businesses and public bodies are shown as recorded. It does NOT say which mortgage is open or
released (that matching is the title search report). status: 'ok', 'not_found' (no parcel matched),
'ambiguous' (several parcels: the message lists them), 'unavailable' (the county did not answer: not 'nothing
recorded'; retry later), 'invalid'.| Name | Required | Description | Default |
|---|---|---|---|
| place | Yes | ||
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only/idempotent safety; the description adds substantial context beyond them: result gating and how to unlock it, name masking to initials for people but not businesses, and the crucial distinction that 'unavailable' does not mean nothing was recorded.
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?
Front-loaded with the purpose, then parameter rules, then return shape and status codes — a sensible order with little waste. It is dense and runs long for two parameters, with somewhat ragged inline formatting, but nearly every clause carries operational 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?
With no output schema and only two bare-typed params, the description fully describes the return payload (counts by kind and year, document types, first/latest event, transfers with consideration, parcel id) and enumerates all five status values. Nothing needed to call or interpret a result 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 0%, so the description must carry the load, and it does: it enumerates the accepted `place` values (including county/city variants) and specifies the address format requirement (start with the house number; append city after a comma for Hamilton and Utah because street names repeat). Without this, both required params would be guesswork.
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 a specific verb+resource+source framing: "What has been recorded against a property, from the official parcel-keyed land records index." It immediately distinguishes itself from nearby report tools by naming what it is not (an open/released mortgage matching = the title search report), so an agent can separate it from order_title_search or recent_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?
Explicitly states the alternative for the adjacent need ("that matching is the title search report"), which routes the agent to order_title_search. It also explains the free tier boundary (first 5 transfers without an account, gated:true) and what each status means for retry decisions, so when-to-call and how-to-interpret are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Effective property tax rate for one US county (median real estate taxes paid / median home value, Census ACS
5-year), with the state and US rates, the county's rank in its state and nationally, and its neighbours.
state: two-letter code or name. county: name or FIPS ("Harris", "Essex County", "34013").
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| county | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the data source (Census ACS 5-year), the computation (median real estate taxes paid / median home value), and exactly what companions are returned (state and US rates, in-state and national rank, neighbours). It omits units (percent vs. decimal) and any caching/rate-limit or failure behavior, but for a read-only lookup this is solid disclosure.
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?
Front-loaded with the metric and its meaning, then a compact parameter-format clause. No filler sentences; each clause either defines the output or enables correct invocation.
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?
There is no output schema and no annotations, yet the description still specifies the return payload (rate, state/US comparison, ranks, neighbours) and both parameter formats, which is nearly everything an agent needs. The remaining gap is the rate's unit/scale (percentage vs. ratio) and any edge-case behavior for unmatched counties.
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 0% — the schema only says 'State' and 'County' as bare strings — so the description must compensate, and it does: state accepts a two-letter code or name, county accepts a name or FIPS, with concrete examples ('Harris', 'Essex County', '34013'). Both parameters become unambiguously callable.
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?
Names a specific metric (effective property tax rate for one US county), states its formula and source, and enumerates the derived outputs (state/US rates, state and national ranks, neighbours). The 'one US county' scoping cleanly separates it from property_tax_rate_by_zip and property_tax_rates_by_state in the sibling 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 single-county scope implies when to use this over the zip- or state-level siblings, but the description never names those alternatives or states an explicit selection rule. Usage is inferable from the resource granularity rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Effective property tax rate for a 5-digit ZIP code (Census ZIP Code Tabulation Area, ACS 5-year medians), with
the US rate. Pass home_value for a rough estimate of the yearly tax at that rate (an illustration, not a bill).
small_sample flags ZIP codes with under 200 owner-occupied homes (wide margin of error).
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | Yes | ||
| home_value | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses the data source and vintage, warns that the home_value output is an illustration rather than a bill, and notes the small-sample reliability caveat. It stops short of stating the rate's unit convention (percent vs. decimal) or what happens for uncovered ZIPs.
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?
Three dense sentences with no padding, front-loaded with the core result and geography, then the optional parameter and the reliability flag. Every clause carries information.
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?
No annotations and no output schema, so the description must explain the return; it covers the US benchmark rate, the yearly-tax illustration, and the small_sample flag. Only the rate's unit convention and coverage/error handling are left implicit.
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 0%, so the description must compensate; it clarifies zip_code as 5-digit and explains what home_value produces (a rough yearly tax illustration). But it gives no units/format for home_value and confusingly describes small_sample as something to 'pass' when it is not a parameter at all.
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?
States precisely what is returned - an effective property tax rate - for a well-defined geographic unit (5-digit ZIP / Census ZCTA), naming the data source and vintage (ACS 5-year medians). The ZIP granularity cleanly separates it from the sibling tools property_tax_rate_by_county and property_tax_rates_by_state.
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?
Usage is implied by the name and geography (look up a ZIP's rate), and it explains the optional home_value use case. However, it never says when to prefer this over property_tax_rate_by_county or the state-level variant, nor any prerequisites or invalid-ZIP behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Effective property tax rates of the 50 states and DC, ranked highest first (1 = highest), with median taxes and home values, the US rate, and the counties with the highest and lowest rates. Census ACS 5-year data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it does disclose meaningful behavior: the ranking order (highest first, 1 = highest), the comparison set (US rate), the extremes (highest/lowest counties), and the source (Census ACS 5-year). It doesn't mention data freshness beyond the dataset name or any auth/rate-limit notes, but for a static read-only reference tool that is minor.
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 tightly packed sentences with the core resource statement front-loaded, followed by the contents list and data source. Every clause adds usable information and nothing is 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?
With no output schema, the description must describe return values, and it does so thoroughly: ranking, medians, home values, US rate, and county extremes. Combined with zero parameters and a named source, there is no obvious gap an agent would need filled to call this 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?
The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly implies a parameterless national dataset.
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 resource (effective property tax rates of the 50 states and DC) with clear scope and granularity, telling the agent this is the state/national-level view rather than the county or ZIP tools. It does not name those sibling tools explicitly, so it stops short of a 5.
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 explicit when-to-use or when-not-to-use guidance and no named alternatives. The state-level scope implies it competes with property_tax_rate_by_county and property_tax_rate_by_zip, but the agent must infer that routing on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where HeritageDeed Property Watch works and what it checks there. With no arguments: every covered county
(state code, county, whether recorded documents are watched by parcel). With state (two-letter code) and
county (e.g. 'Cook', 'Kings' or 'Brooklyn'): that county's checks (records, owner of record, building
violations, tax sale / surplus lists, federal courts), each with its official source and cadence, plus the
county recording office's own fraud alert service when it has one (free is true only where the office says
so; recommend it too: it is official).
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| county | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the returned fields (state code, county, parcel-level watch status), the per-check detail (records, owner of record, violations, tax sale/surplus, federal courts) with source and cadence, and explains that `free` is true only when the recording office says so. It omits pagination, auth requirements, and rate limits, keeping it short of 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?
One tight paragraph, front-loaded with the no-argument behavior and then the argumented behavior, with parentheticals used only for genuinely useful examples and semantics. Every clause carries information.
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?
With no annotations and no output schema, the description must explain return shape, and it does so per mode. It is nearly complete for a simple two-optional-parameter read tool, missing only edge-case behavior (one argument supplied) and any mention of result size or limits.
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 0%, so the description must compensate, and it does for both parameters: `state` is a 'two-letter code' and `county` accepts names like 'Cook', 'Kings' or 'Brooklyn'. It does not state whether the two must be supplied together or what a partial argument set returns.
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 subject and scope: 'Where HeritageDeed Property Watch works and what it checks there', with each mode's return contents enumerated. It is clear what the tool does, but it never contrasts itself with the similar-sounding siblings check_coverage and list_coverage, so an agent must infer the difference.
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 two invocation modes are explicitly routed: 'With no arguments: every covered county' versus 'With `state` ... and `county`: that county's checks'. That gives clear when-to-use context for each form, but there is no guidance on when to prefer this over the sibling coverage tools or what happens if only one of the two arguments is supplied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Radon facts for one US county without an address: EPA radon zone (with the note for counties renamed or created
since 1993, and for Connecticut's planning regions the zones of the former counties their towns were in), and the
radon test results on file (laboratory and state-program data; NY, PA and TN state data, with PA results by ZIP
code and NY results by town). state is the two-letter code, county the county name ('Adams', 'Baltimore city',
'Capitol Planning Region'). Returns the county page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| county | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses data provenance (laboratory plus state-program data), state-specific granularity (PA by ZIP, NY by town), and legacy edge cases (counties renamed since 1993, Connecticut planning regions mapped to former counties). It omits failure behavior (unknown county, states with no coverage) and any latency or cost characteristics.
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 lead clause is front-loaded and the content is dense with genuinely useful domain detail, but the body is a single 80+ word sentence with nested parentheticals that is hard to parse on first read. The information earns its place; the packaging does not.
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?
With no annotations and no output schema, the description does describe the payload components (EPA zone plus on-file test results) and notes it returns the county page URL. It stops short of describing the shape of the test-result data, which is the main remaining gap 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?
Schema description coverage is 0%, so the description must compensate, and it does: 'state' is documented as a two-letter code and 'county' as a county name, with concrete examples ('Adams', 'Baltimore city', 'Capitol Planning Region') that convey the formatting quirks (independent cities, planning regions). It does not state whether names are case- or punctuation-sensitive.
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?
States a specific resource and scope: 'Radon facts for one US county without an address', which implicitly separates it from radon_lookup (address-based) and radon_state_summary (state-level). It never names those siblings outright, so an agent must infer the routing, but the resource and granularity are 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 phrase 'without an address' gives a clear selection condition versus an address-based radon lookup, and the description enumerates what data the call yields. It stops short of explicitly naming the alternative tool or saying what to do if the county is unknown or the state lacks state-program data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Radon for a US street address or a 5-digit ZIP code: the county's EPA radon zone (Zone 1 = predicted average
indoor screening level above 4 pCi/L, Zone 2 = 2-4, Zone 3 = below 2; EPA's 1993 county map) and the radon test
results on file for the county (laboratory test data 2008-2017: tests, median pCi/L, percent at or above
4 pCi/L; CDC state-program data for the latest year reported; New York DOH, Pennsylvania DEP and Tennessee DOH
state data). A ZIP code returns every county its Census ZIP Code Tabulation Area overlaps, by land share, and in
Pennsylvania the DEP results for the ZIP itself. Give address (house number, street, city, state) OR zip_code.
Returns the county page URL. Not a radon measurement of any building.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | ||
| zip_code | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: data vintage (EPA 1993 map, lab data 2008-2017, CDC latest year), the ZIP-to-multiple-counties-by-land-share expansion, the Pennsylvania ZIP-level DEP exception, and the return value (county page URL). What it omits is failure behavior — required parameters are 0 in the schema, so an agent is not told what happens if neither address nor ZIP is supplied, or if an address cannot be resolved to a county.
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?
Front-loaded with the two deliverable values (zone and test results) before the source citations, which is the right order. The parenthetical inventory of state data sources (New York DOH, Pennsylvania DEP, Tennessee DOH) is the least essential part and inflates the block without changing how the tool is called.
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?
No output schema exists, so the description must convey returns; it names the county page URL but does not enumerate the response fields beyond the statistics mentioned inline. Combined with the data-vintage and geographic-expansion disclosure, this is enough to call correctly, though the shape of the returned statistics is only lightly sketched.
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 0%, so the description must compensate, and it does: address is spelled out as house number, street, city, state, and zip_code as a 5-digit ZIP. It also explains the semantic consequence of each choice (ZIP fans out to every overlapping county by land share, plus ZIP-level PA DEP results). It stops short of saying whether both may be supplied together or which wins.
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?
States a specific verb and resource: returns the EPA radon zone plus county test statistics for a US street address or 5-digit ZIP. The input modality (address/ZIP rather than county/state) is what separates it from siblings like radon_by_county and radon_state_summary, and that distinction is stated up front.
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?
'Give `address` (house number, street, city, state) OR `zip_code`' gives explicit input guidance, and 'Not a radon measurement of any building' sets a clear expectation boundary. It never names radon_by_county or radon_state_summary as the alternative when the user already knows the county, so routing between the three radon tools is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many counties of a state are in EPA radon Zone 1, 2 and 3, and the counties with the highest median radon
test result in CDC's laboratory data (2008-2017, counties with 20 or more tests). state is the two-letter code.
Returns the state page URL and the national counts.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose valuable provenance: EPA zone definitions, CDC lab data window, the 20-or-more-tests threshold, and that it returns the state page URL and national counts. It never explicitly states read-only behavior, keeping it just under a top score.
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?
Three compact sentences covering purpose, input format, and return content, with the core purpose front-loaded. The 'How many...' interrogative phrasing is slightly less direct than a declarative statement but still 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?
For a one-parameter read tool with no output schema, the description covers the input format, the datasets used, filtering thresholds, and what is returned – enough for an agent to call it correctly. Minor gaps (no explicit read-only statement, no mention of empty-state behavior) keep it from a 5.
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 0% for the single `state` parameter, so the description must compensate. It does by specifying the expected format ('the two-letter code'), which is exactly the missing semantic. It does not note case sensitivity or validation, so a 4 rather than 5.
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 scope: a state-level rollup of EPA radon Zones 1/2/3 county counts plus top-median-test counties from CDC lab data. This is clearly a state summary distinct from the county-level and address-level radon tools. It does not, however, explicitly name a sibling to contrast against, so it stops short of a 5.
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?
Usage is only implied by the 'state summary' framing; there is no explicit when-to-use or when-not-to-use guidance relative to radon_by_county or radon_lookup. The data-source caveats (2008-2017, 20+ tests) give useful context but are not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recently sold properties (address, sale date and price only; no buyer or seller names) from official open
data, the last 90 days each source has published: area = 'Manhattan', 'Brooklyn', 'Queens', 'Bronx', 'Staten
Island', 'Cook' / 'Chicago' or 'Philadelphia'; optional 5-digit zip_code. Includes the median price, counts by
ZIP and the date the data runs through (NYC and Cook publish with a lag).
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | ||
| page | No | ||
| zip_code | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the data source (official open data), the 90-day lag behavior for NYC and Cook, and the deliberate omission of buyer/seller names. It omits any pagination behavior despite a page parameter, which is the only material gap.
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?
Front-loaded with the core purpose and squeezed into a dense but readable paragraph. Every clause carries real information, though the parenthetical and inline formatting make it slightly heavy.
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?
There is no output schema, so the description usefully explains what comes back (median price, counts by ZIP, data-through date). Combined with the area values and zip format, this is nearly complete for a 3-param tool, missing only pagination guidance.
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 0%, so the description must compensate. It fully covers `area` by listing its valid values and defines `zip_code` as 5-digit, but leaves the `page` parameter entirely unexplained in both schema and description.
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?
States a specific resource and scope: recently sold properties from official open data, with the returned fields (address, sale date, price) and the recency window (last 90 days each source published). This clearly distinguishes it from siblings like property_history_lookup or tax_sale_search.
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 usage through the geography enumeration and data-freshness caveat, giving good context for when the tool is appropriate. However, it never explicitly says when to choose it over alternatives such as property_history_lookup, and no exclusion conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How to use HeritageDeed's key-authenticated REST API (v1) instead of, or next to, this MCP server: base URL, how to get a free API key, authentication, endpoints, the live list of report types you can order, limits, signed webhooks, idempotency, batches (JSON or CSV) and the white-label PDF option. Use it when a developer wants to integrate title searches (O&E reports), lien and encumbrance checks or environmental records reports into their own software, or asks for an API key. This MCP server itself needs no key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it does disclose the key facts: the REST API is key-authenticated, keys are free and obtainable, that there are rate limits, signed webhooks, idempotency semantics, and batch formats. It effectively previews the content the tool returns. It stops short of stating explicitly that calling this tool has no side effects and produces no state change, which holds it below 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?
The purpose is front-loaded and the enumerated topics are each load-bearing for a developer deciding whether to integrate. The first sentence is very long and comma-heavy, which slightly impairs scannability, but nothing is redundant padding and the closing clarification sentence 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?
With no output schema and no annotations, the description must convey what the caller receives; it enumerates the response contents well enough to set expectations. Minor gap: it doesn't state the response format (prose documentation vs. structured data) or how the live report-type list is kept current, which matters for a documentation 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 tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies — parameter semantics are moot here, and the description instead describes the informational payload, which is the relevant content for a no-arg 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 names a specific resource (HeritageDeed's key-authenticated REST API v1) and enumerates exactly what it covers: base URL, API key acquisition, auth, endpoints, report types, limits, webhooks, idempotency, batches, and white-label PDF. This is clearly distinguishable from every sibling tool, which are all data-lookup or ordering tools rather than API-integration documentation.
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?
It gives an explicit usage trigger: 'Use it when a developer wants to integrate title searches (O&E reports), lien and encumbrance checks or environmental records reports into their own software, or asks for an API key.' It also clarifies the inverse case — 'This MCP server itself needs no key' — removing ambiguity about when auth is required versus when it isn't.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Seller net proceeds and the buyer's closing costs for a sale, free: Florida, Texas, New York City, New York
State outside NYC, Philadelphia. place: fl, tx, nyc, ny or philadelphia. price; payoff (the seller's
mortgage payoffs); commission_pct (total commission, e.g. 5.5); loan_amount (the buyer's new loan, for the
lender's policy and Florida mortgage taxes); owner_policy_payer seller or buyer (default: local custom,
seller in FL and TX, buyer in NY and Philadelphia); seller_share_of_split_tax 0 to 1 for taxes the contract
splits (Philadelphia, default 0.5); ny_county for the TIRSA zone outside NYC; recording_pages (FL and TX,
statutory fee) or recording_amount (NY, Philadelphia: entered); other_seller_costs (prorated taxes, HOA,
repairs); fl_prior_policy (Florida reissue rate).
Returns the seller's lines and total, the net to the seller, the buyer's lines and total, flags, and the sources
of every rate. An estimate, not a closing disclosure.| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | residential | |
| place | Yes | ||
| price | Yes | ||
| payoff | No | ||
| ny_county | No | ||
| loan_amount | No | ||
| commission_pct | No | ||
| fl_prior_policy | No | ||
| recording_pages | No | ||
| recording_amount | No | ||
| other_seller_costs | No | ||
| owner_policy_payer | No | ||
| seller_share_of_split_tax | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/idempotent/destructive annotations already covering the safety profile, the description adds genuinely useful context: it is a read-only calculator whose result is 'an estimate, not a closing disclosure,' and it discloses what the return contains (lines, totals, flags, rate sources). That is meaningful disclosure beyond the 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?
Purpose is front-loaded in the first clause, and the dense semicolon-delimited parameter block efficiently packs 12 field explanations into a few lines. It is terse but no sentence is wasted; the staccato style is slightly harder to scan than prose would be.
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 13-parameter, multi-jurisdiction read-only calculator with no output schema, the description covers inputs, output shape, and the estimate caveat. The main omission is the undocumented 'kind' parameter, which is minor given the residential default.
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 0%, so the description carries the full documentation burden and largely succeeds: it defines place codes, payoff, commission_pct, loan_amount, the owner_policy_payer default logic, the seller_share_of_split_tax 0-1 range and 0.5 default, recording_pages vs recording_amount by state, and fl_prior_policy. Only 'kind' is left undocumented.
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 and output: 'Seller net proceeds and the buyer's closing costs for a sale,' with an enumerated jurisdiction scope. It is clearly distinct from data-lookup siblings, though it never explicitly differentiates itself from adjacent calculators like title_insurance_premium or transfer_tax.
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 'free: Florida, Texas, New York City...' list tells the agent this only applies in five jurisdictions, which is useful applicability context. However, there is no explicit when-not guidance and no pointer to an alternative tool for sales outside those places.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a tax sale due diligence batch: a per-parcel flag sheet of debts that can outlive the sale, where public
parcel-keyed data shows them (NYC: unreleased federal tax liens, unpaid ECB penalties, past-due DOF charges;
elsewhere each debt type is marked 'not searched' with the statute's survival rule). Pass record_ids from the tax
sale lists (up to 50), or state + county slug (e.g. 'NY', 'kings-county') for that list's first 50 parcels.
Returns a job_id for get_tax_sale_due_diligence. Free, capped per client.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| county | No | ||
| record_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full load, and it does well: it discloses that the call is asynchronous (returns a job_id), that it is free but capped per client, and — importantly — that outside NYC each debt type is marked 'not searched' with the statute's survival rule rather than silently omitted. It stops short of stating auth requirements or the cap's concrete limit.
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?
Front-loaded with the purpose, then the two input modes, then the return value and cost. The parenthetical NYC debt taxonomy is dense but earns its place by explaining output contents; a slightly crisper structure would split the three concerns more visibly.
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?
With no annotations, no output schema, and a 0%-covered schema, the description supplies what the structured fields do not: the two invocation paths, the cap, the asynchronous job_id return, and the coverage caveat for non-NYC parcels. Only auth/rate-limit specifics and mode-precedence are 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 0%, so the description must compensate and largely does: `record_ids` is tied to tax sale lists with a 50-item cap, and `state`/`county` are given as slugs with concrete examples ('NY', 'kings-county'). It does not specify precedence or behavior if both modes are supplied simultaneously.
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?
States a specific verb and resource ('Start a tax sale due diligence batch') and immediately defines the artifact produced: a per-parcel flag sheet of debts that survive the sale. It is clearly distinguishable from get_tax_sale_due_diligence (which it feeds) and from tax_sale_search.
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?
Gives explicit invocation guidance for both modes: pass `record_ids` from the tax sale lists (up to 50), or `state` + `county` slug for that list's first 50 parcels. It also routes the agent forward by naming get_tax_sale_due_diligence as the retrieval tool, though it does not state exclusions such as when to prefer tax_sale_search instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every EPA Superfund National Priorities List (NPL) site in one state (50 states and DC), free: counts (final,
proposed, deleted, construction complete), a per-county breakdown, the state's rank, plus other EPA record counts
for the state (other Superfund/SEMS sites, leaking and registered underground storage tanks, brownfields, radon
zones). Data is EPA's, refreshed nightly; measured gives each source's date.
`state`: two-letter code or name. Optional filters: `county` (e.g. "Middlesex"), `status` ('final', 'proposed'
or 'deleted'). `limit` caps the site rows returned (1 to 500; counts always cover every site).| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | Yes | ||
| county | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, open-world behavior. The description adds useful context beyond that: nightly refresh, `measured` source dates, free access, and the important detail that `limit` affects site rows while counts always cover every site.
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 core resource and scope, then documents parameters and return behavior efficiently. Despite dense parenthetical detail, every sentence adds useful information for calling or interpreting the tool.
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?
With no output schema, the description still explains the main return components: NPL counts, per-county breakdown, rank, other EPA record counts, and source dates. For a read-only state-level data retrieval tool, this is complete enough for an agent to call and interpret.
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 0%, so the description must carry parameter meaning, and it does: `state` accepts a two-letter code or name, `county` has an example, `status` enumerates final/proposed/deleted, and `limit` is bounded 1–500 with an explanation of its effect.
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 resource and scope: every EPA Superfund NPL site in one state, with counts, county breakdown, rank, and related EPA records. It is clearly distinguishable from address-level lookup, but it does not explicitly name or contrast with the similar sibling `superfund_states_summary`.
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?
Usage is implied by the state-level scope and optional filters, but there is no explicit guidance on when to choose this over `superfund_sites_near_address` or `superfund_states_summary`. The filter behavior is explained, but alternatives are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EPA Superfund sites near a US street address (50 states and DC), free. address = full street address with
house number, city and state.
Returns the National Priorities List (NPL) sites within 3 miles (name, EPA id, status: final / proposed /
deleted, listing and deletion dates, distance in miles and direction, EPA site page), how many active NPL sites
are within 1 and 3 miles, the number of other Superfund (SEMS) sites within 1 mile and of EPA-regulated
facilities within 0.5 mile, all measured from the address's geocoded point.
status 'invalid' = the address could not be matched (the message says why); 'unavailable' = EPA or the Census
address lookup did not answer (NOT a 'no sites' answer, retry later). Tell the user it is a records lookup, not a
Phase I Environmental Site Assessment. The full search (RCRA, tanks, brownfields, flood, wetlands, radon, map)
is the Environmental Records Report: order_title_search(address, report_type='environmental').| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description goes well beyond by disclosing the 3-mile radius, the 1-mile/0.5-mile sub-thresholds, the exact result fields, and the important caveat that 'unavailable' is not 'no sites'. It omits only latency/rate-limit behavior.
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?
Front-loaded with purpose and the parameter constraint before the return-value detail; every segment is informative. It runs slightly long, with the middle enumeration of return fields and sub-radius counts taking more space than strictly needed, but no sentence is wasted.
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?
There is no output schema, yet the description enumerates the returned fields (site name, EPA id, status, dates, distance/direction, link) and the aggregate counts. Combined with status semantics and the non-ESA disclaimer, an agent has everything needed to invoke and interpret this 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?
Schema coverage is 0%, so the description carries the full burden and does: it defines `address` as a full street address requiring house number, city and state, and notes results are measured from the address's geocoded point. That is sufficient to call the tool correctly without inspecting 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?
States a specific verb and resource ('EPA Superfund sites near a US street address'), plus geographic scope (50 states and DC) and cost ('free'). This clearly separates it from the sibling superfund_sites_by_state and superfund_sites_summary lookups, which operate at state level.
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?
Gives the exact condition for use (an address-level proximity query) and names the alternative for the broader use case: order_title_search(address, report_type='environmental'). It also distinguishes 'invalid' from 'unavailable' outcomes and explicitly instructs a retry for the latter, which is real decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Superfund National Priorities List counts for every state and DC (final, proposed, deleted, construction complete, rank by final sites) and the national totals, from EPA data refreshed nightly. No site rows: use superfund_sites_by_state for one state's sites.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real context beyond them: the upstream source (EPA) and the nightly refresh cadence, which affects staleness expectations. It stops short of describing return shape (e.g. one row per state), which matters given there is no output 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?
Two compact sentences, front-loaded with what is returned, then the routing constraint. The parenthetical metric list is dense but each item maps to an actual breakdown field rather than 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?
With no output schema and no parameters, the description carries the full burden and mostly discharges it: it enumerates the metrics returned (final, proposed, deleted, construction complete, rank by final sites, national totals), the geographic scope, and data freshness. Only a row-level return format detail is left implicit.
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 tool takes zero parameters, so the baseline is 4. There is no argument whose semantics need explaining, and the description correctly does not invent any.
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?
States a precise verb+resource: NPL site counts for every state and DC, plus national totals, broken out by final/proposed/deleted/construction-complete and ranked by final sites. It explicitly distinguishes itself from the sibling superfund_sites_by_state, so an agent can choose without opening either schema.
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 names the alternative and the selection condition: "No site rows: use superfund_sites_by_state for one state's sites." That tells the agent both what this tool will and will not return.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the surplus funds (excess proceeds) still on an official list: money left after a tax deed or
foreclosure sale that the former owner or lienholders can claim. state: two-letter code or name;
county: optional county name (e.g. "Duval"); min_amount: optional floor in dollars; sort: amount_desc,
amount_asc, deadline_asc, deadline_desc or sale_date_desc; page_number from 1, per_page 1 to 100.
Each row: case or certificate number, parcel id, property address, former owner (people as initials, businesses
as recorded), sale type and date, amount as published, claim deadline and its basis, and the official list URL.
Amounts are as the office published them; claims, deadlines and eligibility are decided by that office (the
county page and surplus_funds_summary give the statute and how to claim). list_coverage lists covered counties.
Free preview: this tool returns the first 10 rows of each county's list (page_number above 1 is empty) with the
county's true `total_rows`; the full list and the CSV need HeritageDeed Pro ($39 a month) on the county
page (the `message` field says so). Summaries are complete.| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | amount_desc | |
| state | Yes | ||
| county | No | ||
| per_page | No | ||
| min_amount | No | ||
| page_number | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses important behavioral constraints: the free preview returns only the first 10 rows per county, page_number above 1 is empty in preview, total_rows remains accurate, and full lists/CSV require HeritageDeed Pro. It also explains the message field and that summaries are complete.
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 purpose, then moves through parameters, row contents, and preview limitations in a logical order. Despite its length, every section carries useful information for an agent.
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?
It is complete for a six-parameter, no-output-schema search tool: it explains return fields, pagination/preview limitations, relevant sibling tools, and the official-source caveat about claims and eligibility.
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 0% schema description coverage, the description compensates thoroughly: state accepts a two-letter code or name, county is optional, min_amount is a dollar floor, sort lists all accepted values, and page/per_page constraints are given.
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: searching surplus funds/excess proceeds on an official list, including what the money represents. It also distinguishes adjacent tools by pointing to surplus_funds_summary for statute/claim guidance and list_coverage for covered counties.
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?
It clearly establishes the search context and points agents to list_coverage and surplus_funds_summary for related needs. However, it does not explicitly state when not to use this tool or directly compare it with tax_sale_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per county: how many surplus rows are on the official list, their total and the largest, the list's own
date and the last refresh, the office and list URL, the statute, the claim rule and how to claim, the deadline
note. Optional state (code or name) narrows it. Use before surplus_funds_search to see what is covered.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds valuable context about what data is returned per county, which is behavioral beyond annotations. It doesn't cover auth or rate limits, but that's less critical here.
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?
Front-loaded with the core meaning ('Per county: ...'), followed by a compact usage note and parameter detail. The field list is dense but earns its place given no output schema; minor verbosity but efficient overall.
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 summary tool with no output schema, the description is complete. It explains what is returned, how to filter, and when to use it relative to the search sibling. Annotations cover the safety profile.
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 0%, so the description must compensate. It does: 'Optional `state` (code or name) narrows it.' This clarifies the parameter is optional, accepts code or name, and filters results. A small gap remains in not specifying code format (e.g., two-letter), but it's substantially better than the bare 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 states a specific resource (surplus funds) and scope (per county), and enumerates the exact fields returned (counts, total, largest, dates, office, URL, statute, claim rule, deadline). It also names the sibling surplus_funds_search, making it easy to distinguish from the search 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?
Explicitly says 'Use before surplus_funds_search to see what is covered,' naming the alternative and the condition that selects this tool over it. No inference needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Property tax appeal filing deadlines and the free / official filing route. place: 'cook' (Cook County,
Illinois: the Assessor's live township calendar with each township's last file date and Board of Review window),
'nyc' (Tax Commission: March 1 for tax classes 2-4, March 15 for class 1) or 'philadelphia' (Board of Revision of
Taxes: first Monday of October). Optional township narrows Cook to one township (e.g. 'Berwyn', 'Lake View').
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | ||
| township | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does disclose substantive behavioral content: the return shape differs per `place` (a live township calendar for Cook, fixed statutory dates for NYC and Philadelphia). It does not explicitly state read-only/safety profile, but the static informational nature is evident from the topic.
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?
Front-loaded with purpose, then the enumerated options, each sentence carrying real information (specific jurisdictions and dates). Slightly dense/parenthetical but no filler. 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?
For a two-parameter informational lookup with no output schema, the description covers both params and defines the enumerated values with their content. Minor gap: `place` defaults to an empty string and the description never says what an empty/default value yields.
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 0%, yet the description fully compensates: it defines the three `place` values with the concrete data each returns, and explains that `township` optionally narrows Cook, with examples ('Berwyn', 'Lake View'). This is exactly the value the schema lacks.
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?
States a specific resource with a clear scope: 'Property tax appeal filing deadlines and the free / official filing route.' The agent immediately knows this returns deadline/date information rather than appeal evidence or property checks. It does not name sibling tools it overlaps with (e.g. get_tax_appeal_evidence, check_tax_appeal_property) to differentiate explicitly.
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?
Usage is implied by the enumerated `place` values and what each jurisdiction returns, so an agent can infer which value matches its query. However, it never states when to prefer this over the sibling appeal tools or any prerequisites/exclusions. Adequate but with clear gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search properties still on an official tax sale / sheriff sale list. state: two-letter code or name;
county: optional county name (e.g. "Horry"; New York City boroughs by county: "Kings" for Brooklyn);
sort: sale_date_asc, sale_date_desc, amount_desc or amount_asc; page_number from 1, per_page 1 to 100.
Each row: case or certificate number, parcel id, property address, owner (people as initials, businesses as
recorded), sale type and date, the amount as the office labels it (opening bid, judgment, taxes due; some lists
publish none), appraised value where given, status and the official list URL. Rows leave the list when the
office removes them (paid, redeemed, sold, cancelled). Before bidding, a title search on the parcel shows the
other liens and mortgages of record: order_title_search where the county is covered.
Free preview: this tool returns the first 10 rows of each county's list (page_number above 1 is empty) with the
county's true `total_rows`; the full list and the CSV need HeritageDeed Pro ($39 a month) on the county
page (the `message` field says so). Summaries are complete.| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | sale_date_asc | |
| state | Yes | ||
| county | No | ||
| per_page | No | ||
| page_number | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the annotations: free preview returns the first 10 rows per county with true total_rows, page_number above 1 is empty in preview, full lists and CSV require a paid subscription, and a message field explains the limitation. It also discloses row lifecycle behavior, noting that rows disappear when the office removes them due to payment, redemption, sale, or cancellation.
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 purpose, then covers parameters, row contents, lifecycle, due-diligence next steps, and preview limitations. Every sentence contributes useful selection or invocation context, with no obvious 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?
There is no output schema, so the description carries the burden of explaining returns, and it does: each row includes case or certificate number, parcel id, address, owner, sale type/date, amount, appraised value, status, and official URL. It also explains the free-preview limitation and paid access model, making the tool definition complete enough for correct 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?
Schema description coverage is 0%, but the description compensates by explaining every parameter: state accepts a two-letter code or name; county is optional with examples and NYC borough guidance; sort lists the four allowed values; page_number starts at 1; per_page ranges from 1 to 100. This adds meaning well beyond the bare 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 states a specific verb and resource: search properties still on an official tax sale / sheriff sale list. It is clear enough to distinguish this from general property lookups, though it does not explicitly contrast itself with siblings such as tax_sale_summary or surplus_funds_search.
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 first sentence establishes the clear use case: searching active official tax sale or sheriff sale lists. It also points to order_title_search as a due-diligence next step, but it does not explicitly state when to use this tool instead of sibling search or summary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per county: rows on the official tax sale list, the next and last sale dates, the total of the published
amounts, the list's own date and the last refresh, the office and list URL, the statute, the cited bidding and
redemption rules and how to bid, and whether HeritageDeed's title search covers the county. Optional state
(code or name) narrows it.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered without the description. The text adds genuinely useful content context (what each row contains, that a statutory reference and bidding rules are included, and that HeritageDeed title-search coverage per county is reported), but says nothing about authentication, rate limits, data recency semantics, or result scope defaults.
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?
A single sentence, front-loaded with the scoping phrase 'Per county:' so the agent immediately grasps the row grain before the field list. The field enumeration is long but each item is informative and none is redundant, so it reads as dense rather than padded.
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?
With no output schema, the enumerated per-county fields essentially stand in for one, which is the right move for a one-optional-parameter read-only tool. Missing pieces are minor: default scope when `state` is omitted, whether all counties or a capped set are returned, and any pagination behavior.
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 0%, so the description must carry the parameter alone, and it does reasonably well: it states that `state` is optional, that it accepts a code or a name, and that it narrows the results. It stops short of giving concrete examples (e.g. 'CA' vs 'California') or clarifying the result set when the parameter is omitted.
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 makes clear this returns county-level tax sale list data by enumerating the per-county fields (sale list rows, sale dates, published amounts, list URL, statute, bidding/redemption rules). It is an output inventory rather than an explicit verb+resource statement, and it never contrasts itself with the sibling tax_sale_search, so it lands at clear-but-undifferentiated.
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?
There is no when-to-use guidance, no exclusions, and no mention of the obvious alternative tax_sale_search (summary vs. search). The only conditional language, 'Optional `state` ... narrows it,' describes a parameter's effect, not when this tool should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real estate transfer taxes on a sale, from the statutes and tax offices, free. place: nyc (all five
boroughs), ny (New York State outside NYC), fl (Florida outside Miami-Dade), philadelphia, chicago, cook (Cook
County outside Chicago), nc, sc, ar, tx or az (state or city names work too). price: the consideration in
dollars. kind: residential or other (NYC rates differ). mortgage: Florida only, the new mortgage amount
(adds note stamps and the intangible tax).
Returns each tax with its amount and who customarily pays (seller, buyer, negotiable), the total, flags for
what is not included (NYC supplemental tax, local municipal taxes), and the sources. An estimate, not tax advice.| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | residential | |
| place | Yes | ||
| price | Yes | ||
| mortgage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only, idempotent, closed-world profile, so the description only needs to add context — and it does: it discloses the return contents (per-tax amount plus who customarily pays seller/buyer/negotiable), the total, exclusion flags (NYC supplemental tax, local municipal taxes), and a liability caveat ('An estimate, not tax advice'). Only pricing/rate-limit or freshness behavior is absent, which is minor here.
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 tight paragraphs with the purpose front-loaded, then parameters, then returns. The long place enumeration is dense but each token is load-bearing given 0% schema coverage; little waste.
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?
With no output schema and 0% param coverage, the description compensates by enumerating inputs and describing the return shape, exclusion flags, and source attribution. An agent has everything needed to call it and interpret the result.
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 0%, so the description carries the full burden and does so completely: it defines place with a concrete value list and aliases, price as consideration in dollars, kind as residential/other with its NYC impact, and mortgage as Florida-only with the specific taxes it triggers (note stamps, intangible tax). No optional/required distinction is stated, but otherwise nothing is left ambiguous.
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?
States a specific verb+resource ('Real estate transfer taxes on a sale') and names the source basis ('from the statutes and tax offices'), which cleanly separates it from the recurring-rate siblings like property_tax_rate_by_county. An agent can identify this as a one-time transaction tax calculator without opening the schema.
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 `place` enumeration scopes usage precisely (nyc vs ny vs fl vs philadelphia/chicago/cook, plus state/city names), and conditional rules are given per parameter ('kind: NYC rates differ', 'mortgage: Florida only'). It never names an alternative to route to, so it stops short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UCC financing statements (and NYC federal tax lien notices) where a BUSINESS is the debtor. name: the debtor
business name as registered (e.g. 'Publix Super Markets, Inc.'). where: 'all' (default), 'FL' (Florida Secured
Transaction Registry, statewide), 'NYC' (ACRIS personal property records: fixture and co-op filings and federal tax
liens, four boroughs), 'CO' or 'CT' (state open data). Returns each filing's number, type, filing date, lapse date,
status, secured parties and, in NYC, the property. New York State (DOS), Texas, Illinois, Ohio, Arizona and
Pennsylvania are not searched automatically; not_automated gives each official search link and why. Refuses a
person's name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| where | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses return fields (number, type, filing date, lapse date, status, secured parties, NYC property), coverage limits, and the not_automated fallback. It omits auth/pricing/rate-limit behavior, keeping it short of 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?
Front-loads purpose and scope, then parameters, then coverage caveats. Dense but each clause adds real information; the NYC parenthetical is slightly long but earns its place by distinguishing borough/property behavior.
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 2-parameter read tool with no annotations and no output schema, the description covers purpose, both parameters' value space, return contents, coverage gaps, and a refusal condition. An agent has everything needed to call it 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 0%, so the description must compensate, and it does: `name` is defined as the registered business name with an example, and `where` enumerates each accepted value ('all' default, 'FL', 'NYC', 'CO', 'CT') with a substantive explanation of what each registry covers.
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?
States a specific verb and resource (UCC financing statements / federal tax lien notices) and narrows the scope to filings where a BUSINESS is the debtor, with an inline example. This clearly separates it from person-oriented siblings and the various lookup tools.
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 clear when-to-use context (business debtor filings) and an explicit when-not ('Refuses a person's name'), plus the coverage caveat about states not searched automatically. It does not name a sibling alternative for person-name searches, so routing is implied rather than complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is a US street address in a USDA Rural Development eligible area (the property-location test for USDA Single Family Housing Direct and Guaranteed loans, Section 502, and Multifamily Housing)? Give a full street address with city and state. Locates the address, then checks the point against USDA's official ineligible-area map layer (the one USDA's own Property Eligibility map uses). Returns eligible true/false, the matched address and county. NOT an official USDA determination (Rural Development decides on a complete application) and location only: household income limits (USDA income tool linked in the answer), credit and loan approval are separate. status 'not_determined' means USDA's map service did not answer: never read it as yes or no.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it explains that the address is located and checked against USDA's official ineligible-area map layer, lists return fields (eligible, matched address, county), and defines the important 'not_determined' status. It also warns that the result is not an official USDA determination and that income/credit/loan approval are separate.
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 core question, then moves to input, lookup behavior, return values, and caveats. It is dense and slightly long, especially the loan-program parenthetical and repeated caveats, but most sentences earn their 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?
There is no output schema and no annotations, but the description supplies the return fields, the important status semantics, and the limitations an agent needs to interpret the result correctly. For a one-parameter lookup, this is complete enough to use safely.
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 0% for the single address parameter, so the description must compensate, and it does by requiring a full US street address with city and state. It could go further with an example or ZIP-code expectations, but the essential input semantics are clear.
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 precise query: whether a US street address falls in a USDA Rural Development eligible area, naming the specific Section 502 and Multifamily Housing context. It clearly separates this property-location test from income, credit, and loan approval, so an agent can distinguish it from adjacent tools and concepts.
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?
It gives clear when-to-use context: the property-location test for USDA loan eligibility, with explicit exclusions for income limits, credit, loan approval, and official determinations. It does not name sibling alternatives such as check_address or check_coverage, which keeps it just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Zoning district of a property in New York City, Chicago or Philadelphia, from the city's own zoning data: the
district (e.g. R6B, DC-16, RM-1), commercial overlays / overlay districts, special or planned development
districts, and links to the city's zoning text. place: an NYC borough ('Manhattan', 'Brooklyn', 'Queens',
'Bronx', 'Staten Island'; 'nyc' works when the address names its borough or ZIP), 'chicago' or 'philadelphia'.
Not an official zoning determination.
| Name | Required | Description | Default |
|---|---|---|---|
| place | Yes | ||
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does meaningful work: it enumerates what is returned (district code, overlays, special districts, links to zoning text) and adds a material legal caveat, 'Not an official zoning determination.' It omits auth requirements, error behavior for unsupported locations, and rate limits.
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?
Front-loaded with the resource and return contents, then the place constraint, then the disclaimer. Dense but every clause carries information; 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?
No output schema exists, so the description's enumeration of returned fields is necessary and present, along with the coverage limits and disclaimer. Remaining gap is address input format and behavior for unsupported jurisdictions.
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 0%, so the description must compensate. It documents `place` thoroughly (borough names, the 'nyc' shorthand, and the rule that 'nyc' requires the address to name its borough or ZIP), but says nothing about the required `address` format or examples, leaving one of two required params undocumented.
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?
States a specific verb+resource ('Zoning district of a property') with explicit geographic scope (NYC, Chicago, Philadelphia) and enumerates the exact payload (district code, commercial overlays, special/planned development districts, links to zoning text). This clearly separates it from siblings like flood_zone_lookup and opportunity_zone_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?
The description constrains where it can be used by enumerating valid `place` values, but gives no explicit when-to-use/when-not guidance or routing to an alternative tool when the property is outside those three cities. Usage is implied by coverage rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_tax_appeal_propertycreate_property_watchget_tax_appeal_evidenceget_tax_sale_due_diligencelist_property_watch_eventsorder_tax_appeal_evidenceproperty_watch_coveragerecent_salesrest_api_infostart_tax_sale_due_diligencetax_appeal_deadlineszoning_lookupbuilding_records_lookupcensus_tract_lookupcheck_address4 fields changedInput schema / properties / county / defaultAdded value: +""Input schema / properties / report_typeAdded value: +{
+ "default": "current_owner",
+ "title": "Report Type",
+ "type": "string"
+}Input schema / properties / state / defaultAdded value: +""Input schema / requiredPrevious value: -[
- "address",
- "state",
- "county"
-]New value: +[
+ "address"
+]county_loan_limitsfair_market_rent_by_countyfair_market_rent_by_zipfault_lines_near_addressflood_zone_lookupget_sample_report1 field changedInput schema / properties / report_typeAdded value: +{
+ "default": "current_owner",
+ "enum": [
+ "current_owner",
+ "environmental"
+ ],
+ "title": "Report Type",
+ "type": "string"
+}hoa_lookuplist_productsllc_owner_lookupnational_loan_limitsnyc_landlord_lookupopportunity_zone_lookuporder_title_search4 fields changedInput schema / properties / county / defaultAdded value: +""Input schema / properties / report_typeAdded value: +{
+ "default": "current_owner",
+ "enum": [
+ "current_owner",
+ "environmental"
+ ],
+ "title": "Report Type",
+ "type": "string"
+}Input schema / properties / state / defaultAdded value: +""Input schema / requiredPrevious value: -[
- "address",
- "state",
- "county"
-]New value: +[
+ "address"
+]power_lines_near_addressproperty_history_lookupproperty_tax_rate_by_countyproperty_tax_rate_by_zipproperty_tax_rates_by_stateradon_by_countyradon_lookupradon_state_summaryseller_net_sheetsuperfund_sites_by_statesuperfund_sites_near_addresssuperfund_states_summarysurplus_funds_searchsurplus_funds_summarytax_sale_searchtax_sale_summarytitle_insurance_premiumtransfer_taxucc_lien_searchusda_eligibility_lookupcheck_addresscheck_coverageget_order_statusget_reportget_sample_reportget_termslist_coverageorder_title_searchProperty intelligence: 180M+ US parcels — lookup, search, owners, hazards, permits, deeds.
Flood, wildfire, soils, terrain, power grid, utilities and parcels for any US location, sourced.
U.S. real-estate data: property records, AVM value + rent estimates, sale/rental listings.
Official US-address public records: zoning, flood, parcel, permits, taxes. Free look, x402 paid.
Add one secure layer between your agents and this server.
