wazap-mcp

Get the media of a WhatsApp message

get_media

Read-only

Retrieve a WhatsApp message's media—voice note transcripts or saved audio files, photos, and attached files—by message ID, saving files to a chosen directory when needed.

Instructions

What a message's media holds: a voice note or audio as its transcript (kept once made; an API provider bills it), or with save_to its file; a photo attached as an image; any file saved at path on the machine running wazap; a copy kept on arrival answers first. MEDIA_UNAVAILABLE: gone, none kept.

Input Schema

Name	Required	Description
`save_to`	No	Absolute directory; default <data-dir>/media. A recording: its file, and no new transcript
`language`	No	What is spoken, e.g. "ro"
`account_id`	No
`message_id`	Yes

Output Schema

Name	Required	Description
`mime`	No
`path`	No
`size`	No
`type`	Yes
`sender`	Yes
`source`	No	kept: the copy wazap kept when it arrived; whatsapp: downloaded now
`caption`	Yes
`filename`	No	The name it was saved under
`account_id`	Yes
`message_id`	Yes
`transcript`	No
`image_attached`	No	The photo, or a small preview of it, is attached
`original_filename`	Yes
`transcript_unavailable`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.6.0Oct 22, 2026
- removedInput schema / properties / account_id / description
```
Removed value: -"Account id"
```

Changed1 schema field changedv1.4.0Oct 15, 2026

addedOutput schema / properties / source

Added value: +{
+  "description": "kept: the copy wazap kept when it arrived; whatsapp: downloaded now",
+  "enum": [
+    "kept",
+    "whatsapp"
+  ],
+  "type": "string"
+}

Addedv1.0.3Sep 23, 2026

TDQS

B3/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint/not destructive, openWorld), the description adds genuinely useful behavior: transcripts are billed by an API provider, save_to writes a file to the local machine, and a MEDIA_UNAVAILABLE outcome means the media is gone. These cost and failure-mode disclosures are exactly what annotations cannot convey, though the save_to disk-write side effect on a 'read-only' tool could have been called out more explicitly.

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

Conciseness3/5

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

It is short, but the elliptical fragments ('a photo attached as an image; any file saved at path on the machine running wazap; a copy kept on arrival answers first') are dense and hard to parse on first read, so compactness comes at the cost of clarity.

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

Completeness3/5

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

An output schema exists so return values need not be spelled out, and the description covers media variants and the MEDIA_UNAVAILABLE case. However, for a tool that takes an account_id and writes files via save_to, the absence of any note on account scoping or where files land by default leaves real gaps.

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 coverage is 50%: save_to and language are documented in the schema, and the description reinforces save_to's effect ('with save_to its file'), while message_id and account_id receive no explanation anywhere. With half the parameters undocumented, the description only partially compensates.

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

Purpose3/5

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

The phrase 'What a message's media holds' plus the enumeration (transcript, image, file) makes clear it fetches a message's attachments, but there is no verb-led statement of the action and no differentiation from the sibling get_message, which an agent could easily confuse it with.

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

Usage Guidelines2/5

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

No explicit when-to-use or when-not-to-use guidance is given, and nothing says to prefer this over get_message or search. The only routing-like hint, 'a copy kept on arrival answers first,' concerns caching order, not tool selection, so usage must be inferred.

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