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

Annotations already establish this as a safe, offline read calculation, so the description focuses on domain behavior instead: the premium is added to the mortgage while provincial sales tax is paid in cash at closing, and only ON/QC/SK levy that tax. That is genuine behavioral nuance an agent could not get from annotations, though edge cases (insurable price cap, minimum down payment rules) are unstated.

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 front-loaded sentence that names the subject first, then scopes it, then lists outputs. It is dense with parentheticals but every clause carries information; only minor trimming of the nested aside would improve reading flow.

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 usefully enumerates the returned figures (premium rate, premium amount, sales tax, insured mortgage total) so an agent knows what to expect. Remaining gaps are edge-case handling, such as the insurable price ceiling and behavior when down payment is at or above 20%.

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 baseline is 3; the description earns a bump by clarifying that the province parameter only matters for sales tax and that only ON, QC and SK charge it, which is not apparent from the flat 10-province enum. It says nothing about the firstTimeBuyerNewBuild parameter's 30-year amortization effect beyond what the schema already documents.

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 (CMHC mortgage default insurance premium) plus precise scope (down payment under 20%, Canadian home) and enumerates the outputs: premium rate, premium amount added to mortgage, provincial sales tax, insured mortgage total. This clearly separates it from siblings like minimum_down_payment and insured_insurable_uninsured.

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 'under 20% down payment' condition implicitly defines when the tool applies, which is a real usage constraint. It gives no explicit when-not guidance or named alternatives (e.g., for 20%+ down payments the premium is zero and insured_insurable_uninsured applies), so it falls short of a 5.

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