Send a WhatsApp media message

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

Annotations already provide readOnlyHint=false, idempotentHint=false, and destructiveHint=false, covering the mutation and non-idempotency profile. The description adds important constraints (maximum 100 MB and exactly one of file_path/url) but does not disclose other behavioral details such as what happens when both sources are provided or what result is returned after a successful send. That keeps it at baseline plus.

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, front-loaded sentences: first sentence states what and from where, second gives the exclusivity invariant, third gives the size cap. No filler words or repeated information from parameters.

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 tool with six parameters and no output schema, this description provides the essential usage context: media types, source origin, exclusivity, and size limit. The chat_id, caption, and flags are clearly described in the schema, so the description does not need to repeat them. It only leaves out optional or edge-case behavior that is still inferable.

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 description coverage is 100%, so the schema already documents each parameter. The description adds cross-cutting meaning: exactly one of file_path/url and a 100 MB size cap, which are not visible in any single parameter description. This goes beyond the schema and helps the agent avoid an invalid call.

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?

The description names a specific verb ('Send') and a precise resource ('an image, video, audio file or document'), which clearly distinguishes it from text-focused sibling tools like send_message, send_poll, and send_location. It also gives concrete source options (local path or public URL), making the scope unmistakable.

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 clearly states context for use: media messages from a local file or URL, with size and exclusivity constraints. However, it does not explicitly name alternatives or say 'use this when sending media, not text', so an agent must infer the distinction from the word 'image/video/audio/document.'

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