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

Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds substantial calculation context: the stress test rate formula, GDS ratio, down payment, amortization, tax and heating assumptions, and an explicit disclaimer that it is not a loan offer. This is rich behavioral disclosure beyond structured data.

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 front-loaded with the usage trigger, followed by the computation method, methodology source, and disclaimer. Every sentence adds necessary context, and there is no filler despite the technical detail.

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?

Given no output schema, the description clearly states that the tool computes a gross household income figure and describes the assumptions behind it. It could go slightly further by specifying the exact return shape or units, but it is otherwise complete for the agent's 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 100%, so the baseline is 3. The description implies that ville selects a city reference home and prix optionally overrides it, but this largely restates the schema descriptions rather than adding new semantic detail.

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 computational resource: the gross household income required to buy a home in a Canadian city. It clearly distinguishes this from sibling tools by output type, but it never explicitly names an alternative or contrast, so it falls short of the explicit sibling differentiation expected for 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?

It gives a clear triggering condition: call when the user asks what income is needed to buy a home in a Canadian city. No when-not guidance or alternative tool recommendations are provided, but the usage context is unambiguous.

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