Skip to main content
Glama
razvangirgiz

wazap-mcp

by razvangirgiz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Draft a WhatsApp media message

send_media

Draft WhatsApp media from a local file path or public URL, preview it, then confirm before sending. Supports images, video, audio, documents, and GIFs up to 100 MB.

Instructions

Draft an image, video, audio file, document or GIF, from a local path on the machine running wazap or from a public URL. Does not send. Exactly one of file_path / url. Maximum 100 MB. Show the preview; after the user says yes, call confirm_send. A GIF is sent with as_gif: an mp4 goes out looping, a .gif is converted to mp4 first (needs ffmpeg on the machine running wazap).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoPublic http(s) URL to fetch and send
as_gifNoSend a .gif or an mp4 as a looping GIF, the way WhatsApp plays them
captionNoText shown under the media
chat_idYesChat id as returned by another tool ("<digits>@s.whatsapp.net" or "<id>@g.us"), or a phone number in international format
as_voiceNoSend an audio file as a voice note (push-to-talk)
file_pathNoAbsolute path of a local file to send
account_idNoRegistry account id (default, work, …). Omit to resolve from chat_id or message_id, or the default account.
as_documentNoSend as a plain document instead of rendered media

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.15.0
    • addedInput schema / properties / account_id
      Added value: +{
+  "description": "Registry account id (default, work, …). Omit to resolve from chat_id or message_id, or the default account.",
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / as_gif
      Added value: +{
+  "default": false,
+  "description": "Send a .gif or an mp4 as a looping GIF, the way WhatsApp plays them",
+  "type": "boolean"
+}
  2. First observedv0.9.3

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare mutation and non-destructiveness but say nothing about limits or side effects; the description supplies that the call only drafts, caps at 100 MB, and requires ffmpeg on the host for GIF conversion (.gif converted to mp4, mp4 loops). This is exactly the extra behavioral context annotations cannot carry.

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

Conciseness4/5

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

Front-loaded with the core action and source options, then the draft/confirm workflow, then limits and format detail. Every sentence carries information, though the GIF/ffmpeg clause is dense enough to be slightly hard to parse on first read.

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 no output schema and 8 parameters, the description covers the drafting-vs-sending distinction, the mutually exclusive inputs, the size ceiling, dependency requirements, and the handoff to confirm_send. Nothing an agent needs to invoke it correctly is missing.

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 per-field descriptions do the bulk of the work (baseline 3). The description still adds non-obvious constraints absent from the schema: exactly one of file_path/url is required, and the as_gif semantics for mp4 vs .gif. That pushes it above baseline.

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?

States a specific verb (Draft) plus the resource types (image, video, audio, document, GIF) and the source locations (local path or public URL). It is clearly distinguishable from send_message, download_media, and confirm_send, which all deal with adjacent but different actions.

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?

Explicitly says 'Does not send' and routes the agent to the follow-up tool: 'after the user says yes, call confirm_send.' It also clarifies the alternation between file_path and url. The when-to-use and what-happens-next are both spelled out.

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

Deploy Server

Other Tools