Skip to main content
Glama

send_group_file

Destructive

Send one real file — a document such as a PDF, an image, or a video — from the workspace's WhatsApp number into one WhatsApp group, after the user confirms. Every member of that group receives it and it cannot be recalled. file_url must be a DIRECT url to the file: if the file is a Google Drive / Dropbox share link, or only exists as bytes you generated, call upload_file first (pass the link as source_url) and use the url and filename it returns. Works on a number connected by QR code, and on an official green-tick Cloud API number (not Coexistence) for groups created with Meta's Groups API (their chat_id contains letters). Identify the group with "group_id", set to the group's "chat_id" from get_groups (e.g. 120363041234567890@g.us); "chat_id" is accepted as an alias. Group names are not accepted. One group per call: not a broadcast tool. For text only, use send_group_message.

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": {
      "file_url": "<file_url>",
      "confirm": "<confirm>"
    },
    "name": "send_group_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
captionNoOptional text shown with the file in the group.
chat_idNoAlias of "group_id", accepted because get_groups calls this value "chat_id". Pass the group in "group_id" OR "chat_id", not both.
confirmYesConsent 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 post this file into the group.
file_urlYesDirect https url of the file — typically the `url` returned by upload_file. Not a Drive/Dropbox/OneDrive share page.
filenameNoDisplay name INCLUDING the extension (e.g. "proposal.pdf") — pass the `filename` upload_file returned. WhatsApp uses the extension to pick the file type, so a name without one arrives as an unopenable "BIN" attachment and is refused. Required whenever file_url has no filename in its path.
group_idNoThe group's "chat_id" exactly as returned by get_groups (e.g. 120363041234567890@g.us), for ONE group. The digits without @g.us are also accepted. Group names and the numeric "id" field are refused. This is the preferred argument.
media_typeNoHow WhatsApp shows it: "document" (default — a downloadable file with its name, right for PDFs and office files), "image" (shown inline; jpg/png/webp) or "video" (played inline; mp4).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark the tool destructive, non-idempotent, and open-world, and the description adds crucial context beyond them: every group member receives the file and it cannot be recalled. It also explains the consent gate, platform compatibility, and direct-URL requirement, which materially improves safe invocation.

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 description is front-loaded with the action and scope, then layers prerequisites and constraints in a logical order. Despite its length, each sentence carries operational value for a destructive group-send tool.

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?

For a complex destructive tool with seven parameters and no output schema, the description covers the essential call flow, prerequisites, group identification, platform limits, and confirmation behavior. An agent has enough information to invoke it correctly and safely.

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 schema already documents most parameters. The description still adds useful workflow semantics, notably the upload_file prerequisite for share links or generated bytes and the group_id/chat_id relationship, though it mostly reinforces rather than replaces schema details.

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?

The description states a specific verb and resource: send one real file into one WhatsApp group, from the workspace's WhatsApp number. It also distinguishes scope from a broadcast and routes text-only use to send_group_message, so an agent can identify the correct tool 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 Guidelines5/5

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

It gives explicit when-to-use guidance and alternatives: use upload_file first for share links or generated bytes, use send_group_message for text only, identify the group via get_groups, and do not use for multiple groups. The confirmation workflow is also clearly specified.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources