Skip to main content
Glama

Delete a sent message for everyone

delete_message
Destructive

Permanently deletes a WhatsApp message sent by this instance for all chat participants; use only on explicit request because the action is irreversible.

Instructions

Deletes a message sent by this instance for all participants of the chat. Irreversible. Only works on messages the instance itself sent. Use only on explicit user request.

Input Schema

NameRequiredDescriptionDefault
numberNoChat the message belongs to (recommended).
message_idYesId of the sent message.
instance_idNoZapZap instance id (a connected WhatsApp number). Optional when ZAPZAP_INSTANCE_ID is configured; otherwise call list_instances first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the description is not carrying the safety burden alone. It still adds value beyond the annotations by disclosing the scope ('for all participants') and the ownership constraint (only instance-sent messages), which the annotations do not express. It stops short of stating failure modes such as attempting to delete a message outside the platform's deletion window or a message already deleted.

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?

Four short sentences, zero redundancy, and the highest-stakes fact (irreversible, affects all participants) is placed early. Nothing could be removed without losing an instruction the agent needs.

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

Completeness4/5

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

With no output schema, the description would normally need to cover return behavior, but for a deletion call the meaningful gap is narrower: what happens on failure (message too old, not owned by the instance). The ownership and authorization rules are present, so an agent can decide correctly; only the error path is unstated.

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 description coverage is 100% and every parameter is documented in the schema itself, so the baseline of 3 applies. The description only indirectly hints at instance scoping via 'sent by this instance' and adds no syntax or format guidance for message_id or the optional number.

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 (deletes), resource (a message sent by this instance), and blast radius (all participants of the chat), which cleanly separates it from the sibling edit_message. An agent can distinguish it from every other send_/react_/edit_ 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?

Gives an explicit precondition ('only works on messages the instance itself sent') and an explicit authorization gate ('use only on explicit user request'), which is exactly the guardrail needed for an irreversible action. No sibling alternative is named, but none is applicable here.

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