Turbo Notify: WhatsApp for AI agents

Send an image, video, audio, document or sticker

send_media

Send media by URL: an image, video, audio clip, document or sticker.

Set exactly one recipient: number, group_id, or contact_id.

url must still be reachable when the send happens: Turbo Notify fetches the bytes from it. A copy is kept in the organization's own object storage afterwards when that is configured, which never blocks the send and is not required for one.

caption applies to image, video and document only; audio and stickers have nowhere to render one. filename applies to document only. Pairing either with a kind that cannot carry it is rejected here, before anything is sent.

After sending, only the caption of an image, video or document can be changed, with edit_media_caption. The file itself, an audio clip and a sticker cannot be edited: delete_message is the only change for them.

mime_type is optional and does not change how the message is sent. The type WhatsApp receives comes from what the URL's own server serves, so point url at a file that server labels correctly.

Input Schema

Name	Required	Description	Default
`url`	Yes	Link to the file to send. It must still be reachable when the message goes out.
`kind`	Yes	What the file is: image, video, audio, document or sticker.
`number`	No	Recipient phone number in E.164 form, digits only, country code first (e.g. `5511999999999`). Set exactly one of `number`, `group_id` or `contact_id`.
`caption`	No	Text shown with an image, video or document, up to 1024 characters. Audio and stickers cannot carry one.
`filename`	No	The file name the recipient sees on a document, up to 255 characters. Documents only.
`group_id`	No	Recipient group id (`grp_…`), from `list_groups`. A group id belongs to one number: an id from one inbox does not address the same group in another. Set exactly one of `number`, `group_id` or `contact_id`. Addressing a group needs a plan that includes group messaging: without it the call answers `payment_required: feature_not_available`, and retrying will not change that.
`mime_type`	No	The media's MIME type, recorded alongside the message. It does not change how the file is sent: the type WhatsApp receives comes from what the URL's own server serves. Optional.
`contact_id`	No	Recipient contact id (`ct_…`), from `list_contacts`. A contact id belongs to one number: an id from one inbox does not address the same person in another. Set exactly one of `number`, `group_id` or `contact_id`.
`number_alias`	No	Which of the organization's WhatsApp numbers this acts on: `main`, the alias of an extra number, or the number's `id` (`num_…`), which stays the same when the alias is renamed. Call `list_numbers` to see them. Defaults to the main number.	main
`idempotency_key`	No	Any printable ASCII text you choose, 1 to 255 characters, for example the id of the event you are answering. Reusing it for the same number suppresses a duplicate if you retry. Without it, retrying after a timeout may deliver the message twice, and the recipient sees both.
`quoted_message_id`	No	Quote an earlier message (`msg_…`) so it appears above yours. Do this only when your text depends on something said a while ago, yours or theirs; do not quote the message you are answering right now, send a normal message instead.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true and destructiveHint=false, so the description's job is to add context, and it does: the URL must still be reachable at send time, a copy is stored in the org's object storage without blocking the send, and post-send mutability is limited to captions. It does not discuss rate limits or failure modes beyond the caption/filename rejection, which keeps it just short of a 5.

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?

Paragraphs are short and front-loaded, with the recipient constraint immediately after the purpose. The mime_type paragraph partially restates the schema description, which is the only mild redundancy; everything else earns its place.

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 an 11-parameter mutation tool with an output schema, the description covers the essentials an agent needs: recipient exclusivity, kind-dependent optional fields, URL reachability, and what can be changed afterwards. Return values need not be explained because an output schema exists.

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, but the description adds real meaning: it explains that mime_type is recorded only and does not affect delivery (the URL server's type wins), and it reinforces the mutually exclusive recipient parameters and the kind-dependent caption/filename rules. That is value beyond the schema text.

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 first sentence names a specific verb (send) and enumerates the exact resource kinds (image, video, audio, document, sticker), which cleanly separates it from send_text, send_location, send_contact_card and send_cta_button. An agent can pick this 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 states the recipient rule explicitly ('Set exactly one recipient: number, group_id, or contact_id') and gives when-not guidance by naming the follow-up alternatives: edit_media_caption for captions, delete_message as the only change for audio and stickers. It also warns that invalid caption/filename pairings are rejected before sending.

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

All Turbo Notify: WhatsApp for AI agents 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.