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

Annotations already establish that this is a safe, read-only, closed-world calculation, so the safety profile needs no restatement. The description adds useful scope detail (rebates applied, MLTT/NRST triggers, fees broken out separately), but says nothing about the returned breakdown, rounding, or how defaults are applied to untouched cost parameters.

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, but the remainder is a single run-on parenthetical list that packs a dozen items without grouping or prioritization. It contains no wasted words, yet the density costs scannability.

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 15-parameter calculator with no output schema, the definition covers inputs well via the schema but leaves the response shape unexplained (presumably a cost-by-cost breakdown plus total). An agent knows what goes in, not what comes back.

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%, with all 15 parameters individually documented and three enums constrained, so the schema carries parameter meaning fully. The description reinforces which jurisdictions trigger which taxes, but adds no syntax or semantics 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?

The description names a concrete outcome (cash needed to close a Canadian home purchase) and enumerates the cost components it aggregates, which distinguishes it from narrower siblings such as land_transfer_tax or cmhc_insurance. It never names those siblings explicitly, but the aggregation framing makes the 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?

Usage is only implied: this is the all-in closing estimate, whereas sibling tools cover individual components. There is no explicit 'use this instead of X when Y' statement, and no note on when a single-component tool would be preferable or on assumptions (defaults filled in for unlisted costs).

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