ads_telegram_account_send

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

With no annotations, the description carries the full burden and does substantial work: it discloses a hard plan entitlement (Telegram Premium), an out-of-band approval requirement, a mandatory confirmation flag, and that the unread-dialog preflight is read-only and non-blocking. Remaining gaps are failure behavior, rate limits, and idempotency of retries.

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, front-loaded with the action, and every clause carries a constraint rather than filler. Some density (GramJS/TDLib, 'unread-human-dialog preflight') makes it harder to parse at a glance, but nothing is redundant.

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 no annotations and no output schema, the definition covers entitlement, approval, confirmation, and non-bulk scope. It only partially addresses what the call returns (the preflight is mentioned but its payload and the send result are not), leaving a modest gap given there is no output schema to fall back on.

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 coverage is 67%: 'to' and 'confirm' are already documented in the schema, and the description's confirm=true mention restates that. The one added meaning is that 'text' must be plain text (no markup), which is real value since 'text' has no schema description. Overall it stays near the schema baseline.

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: 'Send one plain-text Telegram message through the selected local GramJS/TDLib account.' The scope limiters ('one', 'plain-text', 'bulk outreach is not supported') separate it from batch siblings like ads_client_profile_batch_send. It does not explicitly distinguish itself from ads_telegram_channel_direct_send or ads_telegram_chat_reply, so sibling differentiation is partial rather than complete.

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 concrete preconditions for use: Telegram Premium, prior approval of the exact text, and explicit confirm=true, plus a negative condition (no bulk outreach). What is missing is an explicit named alternative for the cases it excludes (e.g. which sibling to use for bulk or channel posts), so the agent must infer the routing.

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