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

Honestly discloses the real side effects (notifies owner, delivers email) and both scopes of rate-limiting (per business and per directory), all consistent with annotations (readOnlyHint=false, idempotentHint=false). Adds meaningful context beyond the annotations, though it stops short of describing duplicate-send handling or failure semantics.

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?

Two sentences, zero filler. The core purpose is front-loaded and the second sentence packs side-effect and usage guidance with real informational value. Every clause earns its place.

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 mutation tool with real-world effects, the description covers the crucial operational traits: side effects, rate limits, and single-target intent. The output schema covers return-value expectations, and annotations cover mutability, so the description fills the remaining critical gaps without redundancy.

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?

With schema coverage at 33%, the description only partially compensates. It reinforces the message and business intent ('one business'), but subject, sender_name, sender_email, and sender_phone are undocumented in both schema and description. The description does not extend meaning for the majority of parameters, though the schema's business field carries strong semantics on its own.

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?

Opens with a specific verb+resource ('Send a message to one business') and immediately differentiates from the read-only siblings (check/compare/get/search) as the sole write tool. The 'one business' scoping plus the side-effect disclosure leaves no ambiguity about what action this performs.

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 description gives actionable behavioral guidance ('send one considered inquiry rather than a broadcast') informed by rate limits, but it does not explicitly articulate when to use this tool vs. alternatives or state prerequisites. The schema's business parameter references search_businesses, which helps, but that lives in the schema, not the description.

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