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

Annotations already declare readOnlyHint/openWorldHint/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: a 1-credit cost and an honest false-negative caveat (a rough property priced at market rate returns false). It doesn't clarify behavior on an invalid or unfound address, so the additions are valuable but partial.

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 Markdown sectioning is clean, but the document leads with 'What it returns' rather than stating the purpose, and the 'What does TLC stand for?' FAQ consumes space a trained agent doesn't need. The false-negative FAQ does earn its place; the acronym one does not.

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 one-parameter read-only check with an output schema, the definition covers purpose, use cases, cost, and a meaningful failure mode. The remaining gap is input expectations for property_address, which is the one thing an agent must get right to call it successfully.

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 0% and the single parameter is documented only by an example string. The description says nothing about the property_address parameter — no format expectations, no statement about whether a full address with city/state/zip is required or whether partial addresses are geocoded.

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 output: a boolean/confidence flag for whether a property is a fixer-upper, with the signals behind it (AI condition, photo wear, listing NLP, price vs. comps). It is clear about what it does but never names close siblings like get_property_condition, location_red_flags, or get_renovation_cost, so the agent gets no explicit differentiation between them.

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 'When to use it' section gives two concrete scenarios (filtering MLS results for flip investors, pre-flagging for wholesale outreach), which is more than most listings get. It stops short of exclusions or 'use X instead when', so the alternative tools remain undifferentiated.

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