WA MCP

edit_message

DestructiveIdempotent

Edits the text of one of the user's own WhatsApp text messages for everyone in the chat (like "Edit" on the phone), in a 1:1 chat or a group. Paid plan only: on the free plan the call is refused with a note on how to subscribe. Pass the message's id from read_chat_history or search_messages and the full new text; the chat is looked up automatically. Only text messages the user sent (from "Me") can be edited, not captions of photos, videos or documents. If you are writing the text yourself rather than sending words the user gave you, call get_writing_style for this chat first and write it the way the user writes; skip that for dictated text. WhatsApp doesn't render Markdown: use bold, italic, ~~strikethrough~~ and "- " lists, and never send tables, # headings, double asterisks or text links. Write a table as short lines (e.g. "Ana: $200") and paste URLs plain. Only format when it suits the message. Everyone in the chat sees the new text marked as edited, so confirm the wording with the user first unless they gave it. Returns { message_id, status (edited or failed), chat, text, warning?, error? }: chat is the conversation, with the contact fields (name; name_source: address_book, push_name, group_subject, business, phone or unresolved; canonical_jid: the JID to pass to send_message and read_chat_history; phone_jid and lid_jid: the chat's phone-number and LID forms, null when unknown or for groups; phone_display: the number as +). warning is set when the message is more than about 15 minutes old: WhatsApp may not apply the edit; tell the user.

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": {
      "message_id": "<message_id>",
      "text": "<text>"
    },
    "name": "edit_message"
  }
}

Input Schema

Name	Required	Description	Default
`text`	Yes	The complete new text of the message (it replaces the old text entirely).
`message_id`	Yes	The `id` of the user's own text message, from read_chat_history or search_messages.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations flag destructiveHint=true but say nothing about what actually happens; the description fills that in — the edit is visible to all chat participants and marked as edited, edits older than ~15 minutes may not apply (surfaced as `warning`), and free-plan calls are refused rather than charged. That is materially beyond the annotation surface and drives correct agent behavior.

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 purpose, then constraints, then formatting rules, then return shape — a sensible order. The Markdown-formatting paragraph is lengthy for an edit tool and is effectively shared guidance with send_message, which costs a little density but is still relevant to the text being written here.

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?

No output schema exists, and the description documents the return object field by field (message_id, status, chat with its contact fields, text, warning, error) including when `warning` fires. Combined with the eligibility and plan constraints, an agent has everything needed to invoke and interpret the result.

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; the description still earns above baseline by sourcing message_id to read_chat_history/search_messages, stressing that `text` is the complete replacement, and noting the chat is resolved automatically so no chat parameter is needed.

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?

Names a specific verb+resource ("Edits the text of one of the user's own WhatsApp text messages") and states scope precisely: 1:1 or group, "for everyone in the chat", own sent messages only. This clearly distinguishes it from delete_message, send_message and react_to_message without needing 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 explicit when-not conditions (not photo/video/document captions, not messages from others), a plan precondition (paid plan; free plan refuses), an alternative path (call get_writing_style first when composing vs. skipping it for dictated text), and a confirmation rule before making the edit visible to everyone.

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

All WA MCP 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.