Opportunity Zones (opportunityzones.help)

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful domain behavior beyond that: it accounts for multiple start-date types and reports whether the 180-day window reaches OZ 2.0 on Jan 1, 2027. It does not describe output shape or optional-parameter handling, but the annotation bar is lower.

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

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

The description is a single front-loaded sentence with little waste, starting with the core purpose. The parenthetical list is dense but 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 five-parameter calculation tool with no output schema and only 20% schema coverage, the description is too thin on parameter usage and return behavior. It explains the high-level calculation but not how the optional date and entity fields affect 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 only 20%, so the description must compensate. It partially maps to the kind enum by naming direct, passthrough, 1231, RIC/REIT dividend, and installment scenarios, but omits 1256 and collectible and says nothing about dividend_date, entity_year_end, or entity_return_due.

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 calculation: the last day to invest a gain in a QOF. It adds scope by naming the start-date scenarios covered and the OZ 2.0 threshold check, which clearly distinguishes this deadline tool from sibling calculation 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?

The description implies when the tool applies by listing taxpayer start-date scenarios, but it does not explicitly say when to use this versus siblings like calc_oz2_benefit or calc_2026_inclusion. There are no exclusions or alternative-selection guidance.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior. The description adds useful context: the 10%/15% basis step-up applies only when the holding period was met, and tax is estimated at the user's rate. It still omits return format and calculation assumptions.

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 one dense sentence with no filler, front-loading the result and date. It could be split for readability, but every clause adds scope or calculation logic.

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 four-parameter calculator with no output schema and 0% schema descriptions, the description explains the core computation but leaves key inputs and the return shape underspecified. It is adequate to understand the purpose but not fully sufficient to invoke correctly without inspecting the 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 carry parameter meaning. It references deferred gain, the user's rate, and the holding period/date indirectly, but never explains fmv_12_31_2026, date format, or whether rate_pct is a percentage or decimal.

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 calculation: deferred gain inclusion on Dec 31, 2026 for a pre-2027 QOF investment, including the basis step-up and estimated tax. The 'pre-2027 QOF' scope clearly distinguishes it from OZ 2.0-related sibling calculators.

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 specifies the applicable scenario (pre-2027 QOF investment) but gives no explicit when-to-use/when-not guidance or named alternatives among the many calc_* siblings. Usage is implied by the scope rather than stated.

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 readOnly, idempotent, non-destructive, closed-world, so the safety profile needs no restating. The description adds real behavioral context beyond them: it discloses the fallback path, that the fallback result is explicitly flagged as an approximation, and that the underpayment rate is caller-supplied rather than derived. It does not say what the response contains (penalty amount, pass/fail), which keeps it off 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?

It is a single sentence with two levels of nested parentheticals, which makes the conditional logic hard to parse on first read. The purpose is front-loaded, and every clause does carry information, so nothing should be cut — but the structure should have been broken into separate sentences or bullets.

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 an 8-parameter tool with no output schema and only 50% schema coverage, the description explains the computation flow and the exact-vs-approximate branch, which is the critical part. It never states what the tool returns (a pass/fail determination plus a penalty figure is only inferable) and leaves several parameters to bare schema names, so an agent still has gaps to close.

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 only 50% schema description coverage across 8 parameters, the description has to carry weight, and it does: it explains that d1_*/d2_* are the two semiannual testing dates that get averaged, what monthly entries contain and override, and that underpayment_rate_pct is an input the caller must supply. Undocumented in either place are the semantics of months and the distinction between the qozp and total figures, so it is not complete.

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 computation: averaging two semiannual testing dates and, on failure, computing the Form 8996 Part IV penalty month by month. The resource (QOF 90% asset test / Form 8996 Part IV) is unambiguous and no sibling calc_* tool overlaps it. It falls short of a 5 only because the verb-and-resource statement is buried inside one very long sentence rather than stated cleanly 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?

There is genuine guidance on which input path to take — supply monthly figures for an exact result, otherwise testing-date figures are applied per half-year and the output is flagged as an approximation — but that is parameter-level usage, not tool-selection guidance. Nothing tells the agent when this tool applies versus the other calc_* siblings, and prerequisites (e.g., that the caller must look up the IRS underpayment rate) are only implied.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful model mechanics (5-year deferral, 10%/30% step-up, 10-year exclusion capped at year 30), but it does not state modeling assumptions, unit conventions, or what the comparison result looks like.

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 a single front-loaded sentence with no wasted words. However, its brevity comes at the cost of missing information, so it is efficient but under-specified rather than fully optimized.

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?

This is an 8-parameter calculator with no schema descriptions and no output schema, and the description does not compensate for those gaps. An agent would not know how to set invest_date, discount_pct, or rate_later_pct, nor what the tool returns.

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 8 parameters, so the description must carry the meaning of names like gain, rural, growth_pct, hold_years, invest_date, discount_pct, rate_now_pct, and rate_later_pct. It only indirectly hints at rural step-up and hold-period concepts and leaves several parameters entirely unmapped.

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 uses a specific verb ('Models') and a specific resource ('OZ 2.0 investment ... against paying tax now'), which is clear enough for an agent. It does not explicitly distinguish this calculator from siblings such as calc_2026_inclusion or calc_180_day_deadline, so it falls 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?

There is no explicit guidance on when to use this tool, when not to use it, or which sibling calculator is the alternative. The comparison framing ('against paying tax now') implies a use case, but the agent must infer the selection criteria from the title and description alone.

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

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

Annotations already establish that this is a read-only, idempotent, non-destructive calculation. The description adds the important 30-month window and the 100%/50% rural threshold, but it does not explain how the inputs interact or what the output represents beyond the implied required amount.

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 one front-loaded sentence with no filler. The parenthetical efficiently states the key threshold distinction.

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 five-parameter tax calculation with no output schema and no parameter documentation, this is too sparse. It gives the core rule but leaves the agent without enough information to confidently supply or interpret the inputs.

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 define the five parameters. It only alludes to a building's basis, the 30-month period, and the rural condition; it does not explain purchase_price, land_value, spent_so_far, or how start_date is used.

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 identifies the specific calculation: how much must be added to a building's basis within 30 months, including the 100% vs. 50% rural rule. That is clear enough to distinguish it from sibling calculators, though it uses a question rather than an explicit verb and does not name adjacent 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 explicit guidance on when to use this tool versus alternatives such as the 180-day deadline or 90-percent test calculators. It also omits prerequisites, assumptions, and when-not-to-use conditions.

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 read-only, idempotent, non-destructive, and closed-world behavior. The description adds domain-specific behavioral context by naming the test battery and excluded-business list, but it does not explain pass/fail output, how missing optional inputs are treated, or what the tool returns.

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

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

The description is a single front-loaded sentence that lists the key tests without filler. Every phrase contributes specific domain 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?

There is no output schema and the description does not explain return values or how the all-optional nine inputs affect which tests are evaluated. Although annotations cover safety, the definition leaves too much invocation detail unspecified for a multi-test calculation 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% across nine parameters, so the description must compensate. Its test percentages implicitly map to parameter pairs such as tangible_qozbp/tangible_total, gross_income_zone/gross_income_total, and nqfp/total_basis, but it never names the inputs, units, or required relationships, so the compensation is only partial.

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 uses a specific verb ('Checks') and enumerates the exact QOZB tests: 70% tangible property, 50% gross income, 40% intangibles, 5% nonqualified financial property, and the excluded-business list. This clearly identifies the tool's scope and distinguishes it from sibling tools like calc_90_percent_test, calc_180_day_deadline, and get_tract.

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 explicit when-to-use guidance, no prerequisites, and no comparison to alternative sibling tools such as calc_90_percent_test or calc_substantial_improvement. Usage can only be inferred from the stated purpose.

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 this is a safe, read-only, idempotent operation. The description adds useful context beyond annotations: the request is routed to Janover Capital LLC, the service is free and non-obligatory, and Janover arranges loans rather than selling fund interests.

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 wasted words. The core purpose is front-loaded, followed by routing and scope clarification, both of which 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?

For a zero-parameter link tool with no output schema, the description covers who it is for, what it provides, where it routes, and the commercial nature of the service. It does not explicitly say whether the link is returned as a URL or opened directly, which is a minor remaining gap.

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

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

The tool has zero parameters, so the baseline is 4. No parameter semantics are needed, and the description does not need to compensate for schema gaps.

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

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

The description identifies a specific resource—an Opportunity Zone debt-financing request link—and distinguishes it from the calculation and lookup siblings. It is clear enough to select the tool, though the phrasing 'Link where...' describes the destination more than stating the tool's action (e.g., 'Returns a link').

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 names the intended audience (developer, sponsor, business owner) and the project context (Opportunity Zone), and notes the service is free with no obligation. However, it does not explicitly say when to use this versus alternatives or when not to use it, leaving usage guidance implied.

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, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds a content inventory (which dates are returned), which is the useful extra given there is no output schema, but it says nothing about return format or ordering.

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 short sentence with no filler, and the core identity ('The program calendar') is front-loaded. It is telegraphic rather than well-formed prose, which slightly weakens readability but costs nothing in length.

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, non-destructive static reference tool with no output schema, the description covers what the agent needs: what category of data and which specific dates. Only the shape of the response (list vs. prose, date formatting) is left unstated, which is a minor gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly avoids inventing parameter semantics for a parameterless reference 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 the specific resource ('the program calendar') and enumerates the contents (OZ 1.0 inclusion date, OZ 2.0 start, designation periods, filing dates), so an agent knows exactly what this returns. It is a noun-phrase fragment with no verb, and it does not explicitly distinguish itself from date-adjacent siblings like calc_2026_inclusion or calc_180_day_deadline, but the static-vs-computed distinction is 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?

Usage is only implied: an agent infers it should call this when it needs fixed program dates. There is no explicit when-to-use statement, no exclusion, and no reference to the calculator siblings that also surface dates (calc_2026_inclusion, calc_180_day_deadline), which is the main ambiguity risk.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the data content and provenance ('with the official source'), but says nothing about response format or pagination, which keeps it at a moderate level.

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 dense sentence that front-loads the returned data types and ends with provenance. No filler, no redundancy with the title.

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 values; it does so at a high level (counts, eligibility, nomination/certification status, source). For a one-parameter read-only tool with rich annotations, this is nearly complete, though exact field shapes remain unspecified.

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 a single parameter at 100% schema coverage ('Two-letter code, FIPS code or name'), the schema already does the heavy lifting. The description adds only that a territory is also accepted ('one state or territory'), a marginal gain over the schema.

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

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

The description specifies the resource and data returned (counts of 2018 zones, rural zones, 2027-eligible tracts, nomination/certification status) and scopes it to one state or territory. It is clear what the tool does but never contrasts itself with siblings like get_tract or lookup_address, 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?

The phrase 'for one state or territory' implies the appropriate scope (state-level aggregation), but there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as get_tract for tract-level data. Usage is only inferable.

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 readOnly, idempotent, non-destructive, closed-world, so safety is covered; the description adds genuine domain behavior by disclosing the vintage-matching logic and the fact that many GEOIDs are valid in both vintages. It stops short of saying what happens on a miss (no record, invalid GEOID) or what the returned record 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?

Three tight sentences: what it returns, how vintages are matched, then the parameter-selection rule. No filler, and the geoid/geoid_2010/geoid_2020 decision is front-loaded where an agent will see it before opening the schema.

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 is the only source for return semantics, and it says only 'Status' without indicating what fields come back (designation year, eligibility, round) or how a not-found tract is signalled. For a zero-required-parameter read tool that gap is survivable but leaves the agent guessing about the response shape.

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, and the description earns above baseline by explaining the relationship between the three parameters rather than restating them: the single geoid vs. the 2010/2020 pair, and why the pair is preferable when a property has already been geocoded. It does not state whether the pair and the single geoid can be combined or which wins if both are supplied.

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 resource precisely (an 11-digit census tract GEOID) and scopes the return to a 'status' record, which separates it from siblings like calc_90_percent_test or lookup_address. The word 'status' is only disambiguated by the title ('Opportunity Zone record'), so the description alone leaves the domain slightly implicit, and no sibling is named as a contrast.

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 conditional routing: use the single geoid for a bare lookup, but 'if you already geocoded a property, pass geoid_2010 and geoid_2020 instead.' It also explains the vintage pairing rule (2010→2018, 2020→2027) that determines which input is meaningful. It does not point to alternatives such as check_qozb or lookup_coordinates for agents that have no GEOID yet.

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 readOnly, idempotent, openWorld, and non-destructive, so the safety bar is low; the description instead adds substantive behavior: three external services with a fallback chain (Census geocoder, then OpenStreetMap, then FCC Census Block API for tract assignment) and a version split between 2010-tract 2018 designations and 2020-tract 2027-round status with a source field. What is missing is failure/ambiguity behavior (failed geocode, multiple matches) and latency or rate constraints of the external services.

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 action and immediately followed by the return payload, with no filler. It is dense with parenthetical data-source detail, which is justified but makes it a slightly heavy read.

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 burden of explaining returns and does so concretely (both OZ vintages, source field, rural flags, ACS stats). It is nearly complete for a single-parameter lookup; only error and no-match behavior remain 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?

There is only one parameter and schema coverage is 100%, with the schema supplying the format and an example ('2 Woodward Ave, Detroit, MI 48226'). The description adds nothing about the address parameter itself (formats tolerated, whether ZIP is required, ambiguity handling), so the baseline 3 for schema-does-the-work 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 (geocodes) and resource (US street address) and enumerates exactly what is returned: 2018 OZ status on 2010 tract, 2027-round status on 2020 tract, rural flags, and ACS tract statistics. This is precise enough to separate it from siblings like get_tract, lookup_coordinates, and check_qozb, which operate on tracts or coordinates rather than a full address-to-OZ join.

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 input shape: hand it a one-line US address when you need OZ status. However, the description never states when to prefer this over lookup_coordinates (geocoding only) or get_tract (tract-level lookups), nor does it mention prerequisites or exclusions such as non-US or non-street addresses.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds no behavioral context of its own — nothing about what is returned (a status flag? a tract ID?), coverage of the underlying dataset, or how the point is resolved to a tract.

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?

Single short sentence with zero padding, which is good, but the brevity is under-specification rather than economy — the one clause delegates all substance to another 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?

No output schema exists, so the description should explain what a caller gets back, and it does not. For a geo lookup with two undescribed parameters and no return information, the definition leaves the agent guessing on the majority of what it needs.

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 supplies no meaning for lat/lon beyond the obvious names. It does not state coordinate format, expected range, precision requirements, or how boundary-crossing points are handled.

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 'Same as lookup_address for a latitude/longitude point' defines the tool purely by reference to a sibling; the actual function (Opportunity Zone status) appears only in the title, not the description. An agent that has not read lookup_address's definition learns nothing about what is returned or what resource is being looked up.

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 'for a latitude/longitude point' implicitly routes the agent here when it holds coordinates rather than an address, which is a usable selection signal against lookup_address. However, no explicit when/when-not statement or prerequisite is given.

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

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

Annotations already establish readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds useful domain behavior (the 31-month spend-by rule and the 62-month startup extension), but says nothing about what the `disaster` flag changes or what happens when infusions are missing/invalid.

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 dense sentence with no filler, and the primary output (spend-by dates per infusion) is front-loaded before the conditional 62-month case. Slightly terse for the amount of undefined behavior it leaves open, but structurally 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?

No output schema exists, so the description must convey return shape; it does say spend-by dates are produced per infusion, which is the core contract. However, with three parameters at 0% schema coverage and no annotations explaining computation rules, the description is not complete enough to call the tool confidently in the disaster or multi-infusion cases.

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 parameter meaning. It only implicitly explains `startup` (via the 62-month extension); `disaster` and the `infusions` array (date format, amount semantics, whether dates are infusion or deployment dates) are entirely undocumented 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?

The description names the specific output (spend-by dates per cash infusion) and the two statutory horizons (31-month safe harbor, 62-month startup outer limit), which is enough to distinguish it from sibling calculators like calc_180_day_deadline or calc_substantial_improvement. It is a noun phrase rather than a verb+resource statement, but the purpose is 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?

There is no when-to-use or when-not guidance and no routing to siblings, despite a crowded family of deadline calculators. The mention of 'start-up businesses' implicitly hints at the `startup` flag, but nothing tells an agent when to prefer this tool over the other calc_* tools.

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