LetsBot

send_file

Destructive

Send a document/file to a WhatsApp number. file_url must be a DIRECT url to the file itself. If you generated the file yourself, or it is not already at a direct public url, call upload_file first (it takes the bytes as base64 and returns a url plus the filename to pass here). A Google Drive / Dropbox / OneDrive share link is not a direct url — it points at a download page, and the file arrives as an unopenable "BIN" attachment.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "phone": "<phone>",
      "file_url": "<file_url>",
      "confirm": "<confirm>"
    },
    "name": "send_file"
  }
}

Input Schema

Name	Required	Description
`phone`	Yes	WhatsApp number in international format without + (e.g. 201234567890), or the contact's phone / chat_id as listed by get_conversations_awaiting_reply (website chat, Messenger, Instagram, Telegram…)
`caption`	No	Optional caption for the file
`confirm`	Yes	Consent gate — REQUIRED on every call. Pass false first: the tool then performs no action and returns a preview of exactly what would happen. Show that preview to the user, get their explicit approval, and only then call again with true to send this file.
`file_url`	Yes	URL of the file to send
`filename`	No	Display name INCLUDING the extension (e.g. invoice.pdf). WhatsApp shows this name and uses the extension to pick the file type, so a name without one arrives as a generic "BIN" attachment the recipient cannot open. Required whenever file_url has no filename in its path.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the destructiveHint/openWorldHint annotations by disclosing the consent gate (a false call performs no action and returns a preview), the failure mode of share links (file arrives as an unopenable BIN), and the filename-extension requirement with its consequence. This is exactly the kind of operational context the annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core constraint (direct URL) is front-loaded in the second sentence, and the upload_file fallback and the BIN warning follow in a logical order. Every sentence carries a distinct, actionable point with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world send operation with no output schema, the description covers the consent protocol, the URL requirement and the main failure mode. It leaves out what a successful send returns and any rate-limit or group-send behavior, which are minor for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns above that by adding real semantics to file_url ('must be a DIRECT url to the file itself' plus the share-link anti-pattern) and reinforcing why filename needs an extension. It does not add anything for caption or phone beyond what the schema already says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Send a document/file to a WhatsApp number'), which clearly separates it from send_text_message, send_image and send_video. It does not explicitly distinguish itself from the sibling send_group_file, so the group-vs-individual routing is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete pre-condition and names the alternative: if the file was generated locally or is not at a direct public URL, call upload_file first, and it explains that upload_file returns both the url and filename to pass here. It also spells out the confirm=false preview-then-approve workflow. The only gap is no guidance on when to prefer send_group_file.

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

All LetsBot tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?