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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description does add one piece of return-shape information - that the answer includes 'the page to start on' - which is useful since there is no output schema, but it says nothing about length, format, or what the explanation contains.

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?

It is a single sentence, which is appropriately sized for a one-parameter lookup tool, and the scope constraint is front-loaded. However, the long parenthetical of problem categories bloats the sentence and the core payload ('why it costs jobs and what FindingLeads does about it, with the page to start on') is buried at the end.

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 simple read-only, one-enum tool with no output schema, the description covers the trigger, the content of the answer, and the actionable next step (a starting page). The only gap is that the exact return format is unspecified, which is minor at this complexity.

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% and the single 'problem' parameter carries a full enum with a description, so the schema does the work. The prose list of problems (missed calls, slow follow-up, few reviews, Google/AI search, no website) largely restates the enum, adding no syntax or selection nuance.

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 what the tool returns for a given problem: an explanation of why it costs jobs, what FindingLeads does about it, and the page to start on. It is clear enough to separate from siblings like get_pricing or list_free_checks, but it never states a verb+resource cleanly (the sentence is an answer, not a 'Returns X for Y' statement), and the enumeration of problems duplicates the enum rather than sharpening the purpose.

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 phrase 'For one common reason a contractor loses jobs' implies the use case (the user has one of these five problems), but there is no explicit when-to-use, when-not-to-use, or routing to alternatives. Notably, estimate_missed_call_cost overlaps on the 'missed-calls' problem and the description gives no guidance on which to pick.

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