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

With no annotations, the description carries the full burden and does reasonably well: it discloses the returned payload (phone number, diagnostic fee, specialist hours, current on/off-duty status), states the number is answered 24/7 by a named AI dispatcher, and explicitly clarifies no booking occurs, implying a side-effect-free read. Remaining gaps are permission/auth needs and behavior on the negative branch.

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 leading question front-loads the decision the agent needs, followed by a compact payload list and a closing constraint. Every clause carries information, though "specialist hours and on/off duty now" is slightly compressed to the point of ambiguity.

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?

There is no output schema and no annotations, so the description appropriately substitutes by listing the return fields. Combined with one required parameter, the definition is adequate, with only the negative-case behavior and ZIP format left unclear.

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%, so the description must compensate. It does add the meaningful constraint that the ZIP must be a California ZIP, which is not in the schema, but it gives no format guidance (5-digit vs ZIP+4) or behavior for invalid/out-of-area input, leaving the single required parameter only partly specified.

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 resource (appliance repair dispatch coverage) and a specific scope (a California ZIP), and it enumerates what the answer contains. An agent immediately knows this is a coverage-check lookup, not a booking or search tool, and the sibling tools are unrelated so no differentiation is required.

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 "No booking: the person calls the number" explicitly rules out the most likely wrong expectation (that this tool schedules a repair) and tells the agent the follow-up path is a phone call. It also implies applicability only to California ZIPs, though it does not state what to do for out-of-state or invalid ZIPs.

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