Skip to main content
Glama
wsapi-chat

WSAPI WhatsApp MCP Server

whatsapp_post_text_status

Post a text status/story visible to contacts allowed by status privacy for 24 hours, and return the status message ID needed to delete it later.

Instructions

Post a text status (story), visible to contacts allowed by the status privacy settings for 24 hours. Not idempotent. Returns the status message ID, which whatsapp_delete_status needs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesStatus text content

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare idempotentHint=false, so 'Not idempotent' largely restates structured data, but the description adds real value beyond it: the 24-hour ephemeral lifetime, the visibility scope tied to status privacy settings, and the returned status message ID. These are behavioral facts the annotations cannot convey.

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?

Two tight sentences, front-loaded with the action and scope; the cross-reference to whatsapp_delete_status is placed last where it belongs. No filler.

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?

Compensates for the absent output schema by naming the return value, and covers lifetime and audience scope. Only minor gaps remain, such as any auth/session requirement for posting.

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?

Only one parameter ('text') with 100% schema description coverage, and the description adds no formatting, length, or encoding guidance beyond the schema. Under the high-coverage baseline, the schema carries this dimension.

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?

Specific verb+resource (post a text status/story) with enough scoping detail to separate it from the sibling media variants whatsapp_post_image_status and whatsapp_post_video_status. An agent can route on the name plus the 'text' qualifier 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 Guidelines4/5

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

Gives clear context (status visible to privacy-permitted contacts, expires in 24 hours) and implies the intended use case, but never explicitly states when to prefer this over the image/video status siblings or any prerequisite such as an active session.

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