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). The description adds real behavioral context beyond them: two parameters are required because the form has no default, and bonus_percent is sourced from tax-params.json when acquired_date and placed_year are supplied, otherwise falling back to the form's stored default. That conditional-data-source behavior is not visible in the schema or annotations, though it stops short of describing the returned worksheet.

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?

Four short sentences, front-loaded with the identity of the tool then the required-input constraint and the bonus-percent data path. No filler; the closing disclaimer is brief and arguably earns its place for a financial estimate. Sentence 2 is slightly dense but not wasteful.

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 11-parameter, 9%-documented tool with no output schema, the description covers only the required inputs and bonus logic. Six parameters (recovery years, short-life year-1 percent, apply_bonus_anyway override, placed_month, basis) are unexplained, and the structure of the worksheet output is left implicit. Adequate to get a minimally correct call, but not complete.

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 9% (one of eleven parameters documented), so the description carries a heavy burden. It explains the requiredness of land_percent/cost_seg_percent and the bonus_percent resolution logic tied to acquired_date/placed_year, which is genuinely additive. But basis, placed_month, short_life_years, apply_bonus_anyway, building_recovery_years, and short_life_year1_percent have no semantics anywhere, so compensation is 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?

States a specific verb+resource: a year-1 cost segregation worksheet. No sibling covers cost segregation, so it is distinguishable by topic (calculation vs. lookup_* or calculate_* tools are orthogonal domains). However it never says it 'computes an illustration/depreciation schedule,' leaving the output shape implicit.

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 routing to any sibling. 'Estimates for planning; not tax advice' is a liability disclaimer, not usage guidance. The agent must infer from the name alone that this is the right tool for year-1 cost segregation.

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