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

Beyond the annotations (non-read-only, open-world, non-idempotent), the description discloses real behavioral traits: immediate email vs connection-gated WhatsApp delivery, that messages originate from the business number, that the destination applies to every future lead, and the editor-role auth requirement. This is exactly the context annotations cannot carry.

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?

Three dense but front-loaded sentences that lead with the core action and then layer delivery/prerequisite details. Every clause carries information; slightly long for a 3-param tool but nothing is wasted.

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?

Covers purpose, delivery mechanics, prerequisites, persistence, and auth for a mutation tool with no output schema. Enough for an agent to call it correctly; only the return/confirmation behavior is left implicit, which is minor for a configuration tool.

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?

The description adds meaning beyond the 67%-covered schema: it explains that `to` can be a WhatsApp group as well as a number (the schema only mentions a number) and that it must be the owner's/team's address, and it contrasts the two `via` options behaviorally. It does not fully document every parameter, so a 4 rather than 5.

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?

States a specific verb and resource — make the bot notify the OWNER about a new lead — and clarifies exactly what is being configured: a persistent route where every future lead's contact is sent. It is clearly distinguishable from neighbors like dosai_add_lead_reminder (reminders) or dosai_set_notify_email (a raw setting) without opening either 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?

Gives clear usage context: this is for routing new-lead notifications, email fires immediately while WhatsApp requires the project's WhatsApp to be connected, and the editor role is required. It never names an alternative tool or states when not to use it, so it stops short of full routing guidance.

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