askmywa

Overview Schema Source Related Servers Discussions Admin

Send a file

send_file

Destructive

Previews a file attachment for a WhatsApp recipient and delivers it only after the user approves that exact file and recipient, preventing accidental sends.

Instructions

Send a file (image, video, document, or an audio file as a plain attachment) with an optional caption. The file must be under the daemon's send root directory.

Safety: with confirm=false (the default) NOTHING is sent; the tool returns a preview. Show it to the user and call again with confirm=true only after they approved that exact file and recipient. Never set confirm=true on the first call.

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": {
      "recipient": "<recipient>",
      "media_path": "<media_path>"
    },
    "name": "send_file"
  }
}

Input Schema

Name	Required	Description
`caption`	No	optional caption (images, videos, documents)
`confirm`	No	false (default) only previews; true sends, after the user approved the preview
`recipient`	Yes	phone number with country code (no +), a JID or a contact name
`media_path`	Yes	absolute path of the file, under the send root directory

Output Schema

Name	Required	Description
`sent`	Yes	true only when the message left the account
`message`	Yes	human-readable status
`preview`	No
`timestamp`	No	server timestamp of the sent message
`message_id`	No
`needs_confirmation`	Yes	true when this was a preview: repeat the call with confirm=true after the user approved

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 11, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description explains precisely why and how to avoid the destructive path: the default call sends nothing and only returns a preview. It also discloses the send-root containment constraint, which is a real behavioral limit the schema only implies.

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?

Two tight paragraphs: capability and constraint first, safety procedure second. The 'NOTHING is sent' emphasis and the explicit 'Never set confirm=true on the first call' are load-bearing rather than padding.

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

Completeness5/5

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

With an output schema covering return values and annotations covering the safety profile, the description supplies exactly the missing piece: the preview/confirm gate and the path restriction. Nothing an agent needs to call this correctly is absent.

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

Parameters3/5

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

Schema description coverage is 100%, so all four parameters are already documented. The description mostly restates them ('optional caption', path under send root) rather than adding syntax or format detail; its only value-add is reinforcing the confirm workflow, so the baseline of 3 applies.

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

Purpose5/5

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

Names a specific verb and resource ('Send a file') and enumerates the media classes accepted, including the subtle distinction that audio goes 'as a plain attachment' rather than as a voice note, which separates it from send_audio_message. An agent can tell what this does and what it does not without opening the schema.

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 an explicit two-step procedure: call with confirm=false to preview, show the user, then call again with confirm=true only after approval of that exact file and recipient, plus the precondition that the path lives under the send root. It stops short of naming alternatives (e.g. send_audio_message for a voice note) or stating what to do when the path is outside the root.

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

Deploy Server