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

Annotations already cover read-only/safe behavior, yet the description still adds substantial context: it says the result is deterministic and grounded in FRED, Zillow ZHVI and state tax rates, that the grade comes from a Monte-Carlo of local price dynamics versus renting with p10/p50/p90 and a probability, and that it is a probabilistic model, not a guarantee, sales pitch, or financial advice. That tells the agent what kind of output to trust and how to present it.

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 what the verdict returns, then the data sources and model caveats, which matches how an agent would scan it. It is a dense run-on sentence with some redundant hedging ('never a guarantee, a sales pitch, or financial advice'), but every clause carries selection value; nothing is padding.

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?

Although an output schema exists, the description still gives the agent a complete mental model: inputs accepted, data grounding, model type and variability (p10/p50/p90, probability), and explicit limitations on how the grade should be used. Nothing needed to decide whether to call it or how to interpret the result 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% and the single parameter is fully documented as an enzos.ai URL (.../home/<id>) or 16-character id. The description's closing sentence ('Input is an Enzo's home URL or its id') merely restates the schema, so it adds no new format hints or edge-case behavior.

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 verb and resource ('Get Enzo's honest, independent read for one listing') and enumerates exactly what the verdict contains: price comparison, $/sqft, days on market, price cuts, monthly cost, income needed, and an A–F Monte-Carlo grade. That is enough to separate it from get_home or market_snapshot, but it never names a sibling or contrasts itself with them explicitly.

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 signals usage implicitly ('for one listing', 'Input is an Enzo's home URL or its id'), so an agent can infer this is the single-listing deep-dive tool. There is no explicit when-to-use/when-to-avoid guidance nor any pointer to below_market_deals or get_home as alternatives.

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