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

Beyond the annotations (readOnly=false, destructive=true, openWorld=true), it discloses real downstream behavior: the contractor contacts the homeowner directly, GroundQuote never emails/texts or charges the homeowner, and repeat calls for the same pair within a day return the same request. That last point is useful de-duplication context, though it sits in mild tension with idempotentHint=false and could be read as describing return-value identity rather than absence of side effects. Failure modes (bad contractor_id, catalog mismatch, consent false) are not covered.

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 front-loaded with the core action, then layers consent gate, mode semantics, and downstream behavior in short declarative sentences; nothing is padded. The field enumeration in the first sentence partially duplicates the schema, which is the only mild waste.

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 destructive, open-world, 8-parameter tool with nested objects and no output schema, the description covers the consent gate, the two usage modes, the contractor's direct contact, the no-charge guarantee, and de-duplication. What remains thin is error/edge behavior and the non-core optional parameters, but the essentials for a correct call are present.

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 only 38% across 8 parameters, so the description carries real weight here, and it does define the otherwise undocumented wants_site_visit boolean (true = arrange a measurement visit, false = price inquiry). It also restates the homeowner and fence payload at a high level, but says nothing about contractor_id, notes, preferred_days, or preferred_time, leaving several parameters under-explained.

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 uses a concrete verb ("Sends") plus an enumerated payload (name, email, phone, address, fence details) and a precise target scope ("ONE GroundQuote contractor"). The 'ONE' qualifier cleanly separates it from any notion of a broadcast or listing tool like find_fence_contractors, so an agent knows exactly what this does without opening the schema.

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 an explicit, hard precondition: "Only call after the homeowner has explicitly agreed to share these details with that contractor," and ties wants_site_visit to the two usage modes (measurement visit vs. price inquiry). It stops short of naming an alternative or stating what to do if consent has not been given, so it is clear but not exhaustive.

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