Skip to main content
Glama
razvangirgiz

wazap-mcp

by razvangirgiz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Get one WhatsApp message in full

get_message
Read-onlyIdempotent

Retrieve a complete WhatsApp message by ID, including quoted content, reactions, poll votes, media, and read receipts; omit account ID to search across all accounts.

Instructions

One message in full, its words never cut: the message it quotes, each reaction with who left it, poll votes and event answers by person, its media, and on the user's own messages who it reached and who read it. Without account_id the id is looked for on every account.

Input Schema

NameRequiredDescriptionDefault
account_idNo
message_idYes

Output Schema

NameRequiredDescriptionDefault
textYes
chat_idYes
timestampYes
account_idYes
message_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.6.0
    • removedInput schema / properties / account_id / description
      Removed value: -"Account id"
  2. Changed3 schema fields changedv1.0.3
    • changedInput schema / properties / account_id / description
      Previous value: -"Registry account id (default, work, …). Omit to resolve from chat_id or message_id, or the default account."New value: +"Account id"
    • removedInput schema / properties / message_id / description
      Removed value: -"Message id from read_messages / search_messages / get_message, e.g. \"false_4072...@s.whatsapp.net_3EB0...\""
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "account_id": {
+      "type": "string"
+    },
+    "chat_id": {
+      "type": "string"
+    },
+    "message_id": {
+      "type": "string"
+    },
+    "text": {
+      "type": "string"
+    },
+    "timestamp": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "message_id",
+    "chat_id",
+    "text",
+    "timestamp",
+    "account_id"
+  ],
+  "type": "object"
+}
  3. Changed1 schema field changedv0.15.0
    • addedInput schema / properties / account_id
      Added value: +{
+  "description": "Registry account id (default, work, …). Omit to resolve from chat_id or message_id, or the default account.",
+  "minLength": 1,
+  "type": "string"
+}
  4. First observedv0.9.3

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds one genuinely useful behavioral fact: without account_id the id is looked up across every account. The rest is a return-content inventory (quotes, reactions, poll votes, media, read receipts) that an existing output schema already carries.

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?

A single dense sentence front-loads the core promise ('One message in full') and then enumerates contents efficiently. The only waste is the return-content inventory, which duplicates what the output schema already declares.

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 an output schema present, return values need little prose, and the annotations cover the safety profile; the only real gap an agent would care about is the lack of routing guidance versus read_messages or search. The account_id fallback note fills the other notable hole.

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 0%, so the description must carry parameter meaning, and it does explain account_id's optionality and its cross-account fallback behavior. message_id is left to the name and its minLength constraint, so the compensation is only partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title and the opening 'One message in full' state the specific resource and scope, and 'one message' implicitly separates it from bulk readers like read_messages. The description text itself, though, never says the verb plainly and never names a sibling to distinguish against, leaving the differentiation to the title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative among siblings such as read_messages or search. That this is the single-message, full-fidelity fetch is only implied by 'One message in full'.

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

Deploy Server

Other Tools