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

Annotations already signal destructiveHint and openWorldHint, and the description reinforces this with 'This is a real external send action.' That is valuable plain-language confirmation, but it mostly paraphrases the annotations rather than adding new behavioral details like irreversibility, rate limits, or failure behavior.

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 short sentences with no filler: action, capabilities, and prerequisite/side-effect are each clearly separated. The most important facts are front-loaded in the first sentence.

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 nested, side-effecting tool with no output schema, the description supplies the key selection facts and the chat-lookup prerequisite. It leaves nested attachment semantics and provider-specific option details largely to inference, making it adequate for selection but not fully complete for invocation.

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 names text, base64 file attachments, and provider-specific options, which loosely maps to the text, attachments, and specifics parameters. However, schema description coverage is only 40% and the description does not explain send_mode, voice_note, or how to structure provider-specific options, so it only partially compensates.

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?

Clear verb and resource: send a message in an existing chat, with the provider scope explicitly stated (LinkedIn, WhatsApp, Instagram, Telegram). The phrase 'existing chat' differentiates it from chat-starting tools, and the provider list distinguishes it from email and social tools.

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 instructs the agent to locate/read the chat first if chat_id is not already known, which is a clear precondition for correct use. It does not explicitly name alternatives like messaging_start_chat or provider-specific send_message tools, but the context strongly implies them.

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