Skip to main content
Glama
razvangirgiz

wazap-mcp

by razvangirgiz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Send a drafted WhatsApp message

confirm_send
Idempotent

Send a user-approved draft to the specified recipient. The only call that sends once per draft, ensuring messages are dispatched only after explicit approval.

Instructions

Send a draft the user approved — this text, this recipient: the only call that sends, once per draft. A yes about something else: show the preview again and ask. Expired, missing or stale: draft again, show the new preview, ask again. SEND_OUTCOME_UNKNOWN: read_messages, never redo it unasked.

Input Schema

NameRequiredDescriptionDefault
draft_idYesFrom send_message; one with send_at is scheduled, not sent
account_idNo

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. Changed1 schema field changedv1.4.0
    • changedInput schema / properties / draft_id / description
      Previous value: -"From send_message"New value: +"From send_message; one with send_at is scheduled, not sent"
  3. Changed2 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"
    • changedInput schema / properties / draft_id / description
      Previous value: -"The draft_id returned by a send_* tool"New value: +"From send_message"
  4. Addedv0.15.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses key behavioral traits: it sends only the approved draft text to the approved recipient, sends once per draft, and must not be retried unasked after an unknown outcome. This adds meaningful safety and side-effect context for a high-stakes mutation tool.

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?

The description is short, front-loaded with the main send action, and every sentence carries operational value. The terse error-handling clauses are efficient rather than wasteful.

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?

For a high-stakes send operation, it covers approval requirements, staleness, idempotency, and unknown-outcome recovery well. It does not describe successful return behavior or explain account_id, leaving a small completeness gap given there is no output schema.

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?

The schema documents draft_id but leaves account_id undocumented, and the description does not explain account_id either. It reinforces draft uniqueness and approved-recipient semantics but only partially compensates for the 50% schema coverage gap.

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?

The description uses a specific verb and resource ('Send a draft') and clarifies scope with 'this text, this recipient' and 'the only call that sends, once per draft.' It distinguishes the action from draft creation and from other sending-like siblings.

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?

It explicitly states when to send, what to do when the user's yes is about something else, what to do for expired/missing/stale drafts, and how to handle SEND_OUTCOME_UNKNOWN. These are concrete when/when-not and recovery instructions.

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