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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds that the output is a break-even year and lists the factors included in the model, but says nothing about assumptions, rounding, or what the full response contains. With annotations carrying the behavioral load, this is adequate rather than rich.

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?

Two sentences: the first front-loads the core function and its output, the second is a single web-page reference. The factor enumeration is slightly long but each term maps to a real part of the model, so little is wasted.

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 15 optional parameters, no required fields, and no output schema, the description does the minimum: it states the purpose and the headline result (break-even year). It does not describe the returned structure (e.g., side-by-side cost totals, per-year breakdown) or model limitations, which an agent would need to set expectations for a 15-input calculator.

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% across all 15 parameters, including units and clarifying notes (e.g., what the down payment could earn if invested). The description adds no per-parameter meaning beyond restating high-level cost categories, so the baseline of 3 applies.

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 specific computation (rent vs. buy break-even analysis) and enumerates the cost factors it weighs (interest, tax, upkeep, lost returns, equity), which clearly separates it from generic siblings like mortgage_calculator or break_even_calculator. It stops short of explicitly naming an overlapping alternative, so it is clear but not fully differentiated in a 180-tool catalog.

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 statement, no mention of prerequisites, and no routing to or away from adjacent tools such as break_even_calculator, home_affordability_calculator, or rent_affordability_calculator. An agent must infer from the name alone that this is the right tool for comparing ownership versus renting.

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