Grove Hopper Property Tax Check

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

Annotations already declare readOnlyHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: sourced answers drawn from Grove Hopper county/state guides and research posts, returned with links, plus a pointer to the free per-address check. The trailing "Read-only" merely restates the annotation and earns nothing.

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?

Scope and the negative routing rule are front-loaded, and the quoted example questions do useful semantic-matching work. It runs long as a single block, and the enumerated topic list plus the trailing "Read-only" are mildly redundant against the rest of the text.

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 return burden and does so: it states answers are sourced, come with links, and direct the user to the free address-specific check. Combined with full schema coverage and clear annotations, nothing material is missing for correct 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 coverage is 100%, so baseline is 3; the description goes further by explaining that state and county are optional and act as a preference signal ("prefer local guide answers"), which is more actionable than the schema's 'if the question is local'. The question parameter itself adds nothing beyond the schema, so it is not a 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?

Names a specific verb+resource (answer a property tax question) and immediately narrows the scope to general, non-address-specific questions, backed by concrete example queries about appeals, decks, basements, and remodels. An agent can distinguish this from address-checking siblings 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 states when to use it (general property tax questions, any US state) and when not to ("Do not use when the person gives an address and wants it checked (use check_property_tax_assessment)"). It does not disambiguate from find_property_tax_exemptions or get_property_tax_appeal_deadline, even though it lists 'exemptions' and 'what evidence wins an appeal' as covered topics, leaving a real routing ambiguity.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered and 'Read-only' merely restates it. Beyond that the description adds real substance: the assessed value can be looked up from a street address, a fallback typical local effective rate is substituted and explicitly labeled as an estimate, and 'the formula and rate source are shown' discloses the transparency of the output. It stops short of describing the response shape or caveats about estimate accuracy.

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 front-loaded with the trigger scenarios, then moves to input rules and finally to scenario parameter mappings, which matches how an agent reads it. Nearly every clause carries information, though the parenthetical quoted user phrasings and the partially redundant 'Works for any US address, county or state' add length without much new selection value.

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

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

For a zero-required-parameter, 12-parameter calculator with no output schema, the description does the heavy lifting: it explains scenario selection, the interchangeable rate-input paths, the address-based lookup fallback, and that the formula and rate source are surfaced. The remaining gap is that with no output schema present, the description never tells the agent what fields come back (bill amount, effective rate, savings per year), which would be needed to chain results reliably.

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

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

Schema description coverage is 100%, so the baseline is 3, and each of the 12 parameters is individually documented in the schema. The description does add orchestration meaning the schema cannot express — that any one of annual bill, percent rate, millage, or state/county may supply the rate — which pulls it toward 4, but it omits ordering or precedence when multiple rate inputs are supplied simultaneously, leaving the key ambiguity unresolved.

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 concrete verb and resource set — estimating a property tax bill, projecting the tax effect of a home improvement, and computing annual savings from a successful appeal — each with a natural-language example phrase an agent can pattern-match against. It does not, however, contrast itself with the overlapping sibling answer_property_tax_question, so an agent asking 'how much is my property tax' could plausibly route to either 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?

Usage is stated clearly via three 'use this when' triggers with quoted user phrasings, plus per-scenario parameter instructions ('improvement (add improvementCost or addedAssessedValue)', 'appeal (add newAssessedValue or reductionPercent)'). What is missing is any exclusion or named alternative — nothing tells the agent to prefer find_property_tax_exemptions or get_property_tax_appeal_deadline for adjacent questions, or that a pure factual question should go to answer_property_tax_question.

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

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

Annotations already cover safety (readOnlyHint, destructiveHint=false, openWorldHint), and the description adds value beyond them: data provenance varies (direct county record vs. live search of county/public pages, and it reports which), expected latency is up to ~25 seconds, and it confirms nothing is filed or submitted. That is exactly the extra context an agent needs before committing to a long-running call.

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 definition is front-loaded with trigger phrases and exclusions before the long return-value enumeration, so the important routing information comes first. The middle sentence is dense and run-on with nested parentheticals, but since there is no output schema, the return list earns its space.

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 explaining returns, and it does so thoroughly: assessed value with tax year and source link, estimated annual bill with rate, a 10% savings scenario, appeal deadline with days remaining, hearing body, filing instructions, and a result card. Latency, exclusions, and read-only status round out 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 100% and the single parameter already documents the format with an example, so the description only needs to reinforce meaning. It adds scope information the schema lacks ('works for any US address', it confirms property and county before returning), which helps an agent decide validity of the input, though it stops short of describing failure behavior for unmatched addresses.

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

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

Description opens with concrete user intents ('is my property tax too high', 'what is my home assessed at') and states the specific resource: assessed value, tax year, estimated bill, appeal deadline for a specific US address. It also distinguishes itself from answer_property_tax_question and from non-US scenarios, so an agent can route 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?

Explicit when-to-use triggers are given as quoted user phrasings, and when-not-to-use is stated with the named alternative ('Do not use for general questions with no address (use answer_property_tax_question)') plus a non-US exclusion. Nothing about 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.

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the trailing 'Read-only' is redundant. The description still adds real value beyond them: it discloses a latency ceiling of about 25 seconds when live search is triggered, the provenance of the data (Grove Hopper county research, 50-state roundups, live official pages), and what each returned program contains.

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 front-loaded paragraph that leads with the trigger conditions, then inputs, then outputs, then the exclusion and latency caveat. It is dense but every sentence is functional apart from the redundant 'Read-only' tag at the end.

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, and the description compensates by describing the return payload (what the program does, eligibility, how and by when to apply, source links). Coverage limits, latency, and the sibling hand-off are all present, so nothing an agent needs in order to call this 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 100%, so state, county and situation are already documented with examples and an enumerated value list. The description restates that county is optional and repeats the situation categories, adding no syntax or format detail the schema lacks. Baseline 3 applies.

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 (find property tax exemptions), enumerates the exact query phrasings it answers (senior, veteran, disabled-veteran, disability, homestead, senior freeze), and scopes coverage to any US state and county. It is clearly distinguishable from the sibling tools, and it explicitly names get_property_tax_appeal_deadline as the tool for a different need.

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 trigger phrasing ('property tax exemptions for seniors', 'senior property tax freeze') plus an explicit exclusion: do not use for appealing an assessment, use get_property_tax_appeal_deadline instead. Required vs optional inputs are spelled out (state required, county optional), leaving little to inference.

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

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

The annotations already establish read-only, non-destructive, open-world behavior, and the description adds substantial context beyond them. It discloses latency for live-search counties, explains output contents, and describes how township and notice-date rules affect the result.

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 use cases and is generally dense with useful information. It is somewhat long as a single paragraph and includes a redundant 'Read-only' statement already covered by annotations, 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?

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: exact deadline, days left, hearing board, filing method, forms, steps, and source links. It also covers jurisdiction-specific edge cases and latency expectations.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description still adds meaningful semantics: address is needed for township resolution, county and state are alternatives, and noticeDate is used to compute deadlines in notice-based jurisdictions.

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 purpose: retrieving property tax appeal deadlines and filing details. It names example user questions and explicitly distinguishes itself from find_property_tax_exemptions, so an agent can identify the right tool 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?

It gives explicit trigger phrases, accepted geographic scope, and input alternatives, along with a clear exclusion: do not use it for exemption applications. The exemption tool is named as the correct alternative for that case.

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