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

Annotations already declare a non-readonly, non-idempotent, open-world write; the description adds real context beyond that: owner-only authorization, the 10-per-project quota, and the external dependency on a configured notify email or connected Telegram bot. It stops short of saying what happens on failure or what is returned on success.

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?

Front-loaded with the core action and kept to one dense sentence, so it is efficient. The parenthetical asides and clipped fragments ('money for the period') make it a bit cryptic rather than fully polished.

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 an 8-parameter mutation with no output schema, the description covers permissions, quota and channel prerequisites well but says nothing about the conditional parameters (weekly vs monthly) or what the created report returns, which the agent needs in order to follow up with dosai_update_report or dosai_delete_report.

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 63% schema description coverage, the schema does most of the work for send_times, send_weekdays and send_day_of_month. The description only enriches the channels parameter by explaining that email means the project notification email and telegram means the reports bot; frequency and the conditional weekday/day-of-month requirement get no extra explanation.

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 the resource (a scheduled report), its contents (leads, dialogs, money for the period) and its delivery channels, which is more than a restatement of the title and clearly differs from dosai_send_report_now or dosai_update_report. The telegraphic phrasing ('A new report by schedule') is slightly clipped but an agent can still tell what it creates.

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?

Explicitly routes later changes to dosai_update_report and names the prerequisites for each channel (project notification email via dosai_set_notify_email, reports bot connected in the cabinet). It also states the 'Owner only' restriction and the 10-per-project cap, giving clear context, though it never mentions dosai_send_report_now or dosai_list_report_settings as adjacent alternatives.

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