Skip to main content
Glama

WhatsMCP: MCP for WhatsApp

by com.whatsmcp.app
OverviewDiscussionsAdmin

Report to WhatsMCP

wa_report

Send a bug report, feature request or feedback about WhatsMCP to the WhatsMCP team. Use it when the person asks to report a problem, suggest a feature or leave feedback — not to contact a WhatsApp user (that is wa_send_message). The report is emailed to the team with the workspace and the sender's address, so a reply reaches the person by email. Write it in the person's words; for a bug include what was done, what happened, what was expected and any error text. Never include passwords, API keys or message contents the person did not ask to share.

Input Schema

NameRequiredDescriptionDefault
typeYeswhat kind of report this is,enum=bug,enum=feature_request,enum=feedback
titleYesa one-line summary, at most 120 characters
messageYesthe report itself, at most 5000 characters: for a bug, what was done, what happened and what was expected, and which number it was on

Output Schema

NameRequiredDescriptionDefault
statusYesok when the report was accepted for delivery, refused when it was not
messageNowhat happens next, for the person
refusalNopresent only when the report was not sent

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / refusal / properties / candidates
      Added value: +{
+  "description": "on an account_ambiguous refusal: the accounts to choose from — retry with one of these as account_id",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "account_id": {
+        "description": "the id to retry with as account_id",
+        "type": "string"
+      },
+      "name": {
+        "description": "the account's WhatsApp display name",
+        "type": "string"
+      },
+      "phone": {
+        "description": "the account's phone number, E.164",
+        "type": "string"
+      },
+      "status": {
+        "description": "whether the number works right now — live, connecting, or why not, as wa_list_accounts reports it",
+        "type": "string"
+      }
+    },
+    "required": [
+      "account_id"
+    ],
+    "type": "object"
+  },
+  "type": [
+    "null",
+    "array"
+  ]
+}
  2. Changed3 schema fields changed
    • addedOutput schema / properties / refusal / properties / account_status
      Added value: +{
+  "description": "when the number is not working: its status — starting, not_running, whatsapp_down, suspended, pairing, unlinked or locked",
+  "type": "string"
+}
    • addedOutput schema / properties / refusal / properties / account_status_reason
      Added value: +{
+  "description": "the detail of account_status, e.g. no_egress, stopped, no_plan",
+  "type": "string"
+}
    • addedOutput schema / properties / refusal / properties / since
      Added value: +{
+  "description": "when the number stopped working, RFC3339, when known",
+  "type": "string"
+}
  3. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations declare a non-read-only, open-world, non-idempotent, non-destructive call, but not what happens to the payload. The description adds that the report is emailed to the team along with the workspace and the sender's address, so a reply reaches the person by email, and it sets a privacy boundary (no passwords, keys, unshared message contents). It doesn't mention rate limits or duplicate-submission behavior, so not 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?

Four sentences, front-loaded with purpose then usage then content then safety; each sentence does work. The privacy sentence is slightly tacked-on but is genuinely necessary for a tool that forwards user text externally.

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?

With an output schema, full parameter documentation and annotations present, the description only needed to add routing, behavioral destination and content expectations — and it does all three. Nothing an agent needs to call this correctly is missing.

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 baseline is 3, but the description adds semantic content beyond the field docs: it prescribes writing in the person's words and enumerates the structure a bug report should contain (what was done, what happened, what was expected, error text), which goes past the schema's shorter phrasing.

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 and resource ('send a bug report, feature request or feedback about WhatsMCP to the WhatsMCP team') and explicitly contrasts with the nearest sibling, wa_send_message. An agent can route between the two without opening either 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 both the trigger ('when the person asks to report a problem, suggest a feature or leave feedback') and the exclusion ('not to contact a WhatsApp user (that is wa_send_message)'). Coverage guidance ('write it in the person's words') further shapes correct use.

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

All WhatsMCP: MCP for WhatsApp toolsInspect
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