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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context by disclosing the computation rules — day 180 yields to the tax return due date when that comes first, varying by filer type and extension — plus weekend/federal-holiday flags and a 'days left' calculation. With no output schema, this disclosure of return content is valuable.

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 dense sentence that front-loads the anchor input ('From the date the relinquished property closed') before listing outputs, with no filler. It is close to a run-on and could be split into an input statement and an output statement for faster scanning, but 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?

For a pure read-only calculator with three simple parameters, no output schema, and full schema coverage, an agent needs to know the input anchor, the branch conditions, and what comes back — all of which the description supplies, including the tax-return-due-date exception and the practical 'last closing date with full 180 days' output. Nothing required to call it correctly is missing.

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

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

Schema coverage is 100%, so a 3 is the baseline; the description earns above that by explaining why the non-required parameters matter, noting the exchange period depends on 'filer type and extension.' It also anchors sale_date as the relinquished-property closing date, reinforcing the schema's own note about using the first closing.

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 (1031 exchange deadlines) and enumerates exactly what is computed: the 45-day identification deadline, the end of the exchange period, weekend/holiday flags, days remaining, and the last qualifying closing date. That is far more specific than the title alone. It does not explicitly contrast itself with siblings (estimate_exchange_tax, list_dst_offerings), but their purposes are distant enough that confusion is unlikely.

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?

"From the date the relinquished property closed" establishes the triggering context and the schema clarifies that for multiple sales in one exchange the first closing is used, so usage is implied clearly. However, there is no explicit when-to-use/when-not statement or routing to alternatives such as estimate_exchange_tax for tax liability instead of deadlines.

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