Sautikit

delete_whatsapp_media

DestructiveIdempotent

Delete an uploaded WhatsApp media object at Meta. NOTE: uploading and downloading media are NOT available as tools — they move binary files, which the Model Context Protocol carries poorly. Use the REST endpoints directly: POST /v1/whatsapp/media (multipart upload) and GET /v1/whatsapp/media/{id} (streams the bytes).

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": {
      "media_id": "<media_id>"
    },
    "name": "delete_whatsapp_media"
  }
}

Input Schema

Name	Required	Description
`purpose`	No	Required on tools that read data or reports; recommended on every tool. One sentence: what you are doing and why (for example "finding this caller's open ticket to answer them"). Building a report, dashboard, analytics or an export is a SautiDesk Pro feature done by the report tools, not by pulling records.
`media_id`	Yes	Meta media id, taken from an inbound message's media object (e.g. image.id on a whatsapp.event.received webhook)
`number_id`	No	Sautikit number id (UUID) the media belongs to; mutually exclusive with connection_id
`connection_id`	No	WhatsApp connection UUID the media belongs to; mutually exclusive with number_id

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Beyond the standard annotations (destructive and idempotent), the description provides crucial behavioral context regarding the limitations of the Model Context Protocol (MCP) when handling binary media. It explains the necessity of using direct REST calls for binary data transport.

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 definition is exceptionally well-structured. It front-loads the core function, follows immediately with critical technical limitations, and provides the exact external remediation steps (REST endpoints) in a very efficient format.

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?

Given that this tool handles a highly technical and protocol-sensitive operation, the description is maximally complete. It addresses the failure modes (MCP binary transport) and dictates the correct external operational workflow, leaving no ambiguity for the agent.

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?

While the schema covers the definition of the media_id, the description clarifies its specific origin (Meta media id from an inbound message's webhook). This contextual semantic information is highly valuable for an AI agent selecting and populating the parameters.

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 purpose is clearly stated: to delete an uploaded WhatsApp media object at Meta. Furthermore, it immediately provides crucial boundary conditions by noting that media uploading and downloading are not handled by this tool.

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?

The definition provides explicit usage guidance by dictating that the agent must use external REST endpoints for uploads and downloads because the tool/protocol cannot handle them. This is the ultimate usage constraint for this function.

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

All Sautikit 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.

Resources

Need Help?