Skip to main content
Glama
Sign In

WA MCP

by com.wa-mcp
OverviewDiscussionsAdmin

mark_as_unread

Idempotent

Marks a chat as unread: the unread dot appears on it on the user's phone and other devices, like "Mark as unread" on the phone. Useful as a reminder to come back to a chat. It only sets the dot: blue ticks already sent stay sent, and the sender sees nothing. mark_as_read clears it. Call this only when the user asks. If it answers that WhatsApp is re-syncing, ask the user to open WhatsApp on their phone and try again in a minute. Returns { status: "unread", chat }, 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 +).

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": {
      "jid": "<jid>"
    },
    "name": "mark_as_unread"
  }
}

Input Schema

NameRequiredDescriptionDefault
jidYesThe chat to mark as unread: a contact name, a phone number with country code, or a chat JID (person or group).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare the generic mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false); the description goes well beyond by scoping the blast radius ("blue ticks already sent stay sent, and the sender sees nothing") and documenting the re-sync error path with a concrete retry instruction. That is exactly the side-effect and failure-mode context annotations cannot express.

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?

The core effect and the mark_as_read distinction are front-loaded in the first two sentences, and the safety caveat follows immediately. The final parenthetical enumerating every contact field is dense and slightly over-stuffed, though it substitutes for a missing output schema.

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 no output schema, the description compensates by naming the return shape (status/chat) and decoding the contact fields including name_source, canonical_jid, phone_jid/lid_jid nullability, and phone_display format. Combined with the side-effect and retry guidance, an agent has everything needed to call this correctly and interpret the result.

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 coverage is 100% and the jid property description already lists the accepted forms (contact name, phone number with country code, chat JID for person or group), so the description adds essentially nothing new about the input. It does reinforce the JID concept via canonical_jid in the return section, but that is return-value semantics rather than parameter semantics. Baseline 3 applies.

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 ("Marks a chat as unread") plus the concrete observable effect (unread dot on the user's phone and other devices). It explicitly contrasts with the sibling mark_as_read ("mark_as_read clears it"), so the agent can distinguish the pair 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 a positive use case ("useful as a reminder to come back to a chat"), a hard precondition ("Call this only when the user asks"), a named alternative (mark_as_read), and recovery guidance for the re-sync failure mode. When-to-use, when-not-to-use, and what to do on error are all present.

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

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