Skip to main content
Glama
razvangirgiz

wazap-mcp

by razvangirgiz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Get the WhatsApp connection status

get_status
Read-onlyIdempotent

Check WhatsApp account connection, sync, history freshness, webhook delivery, and version status. Use it to diagnose NOT_CONNECTED, NOT_LINKED, or SYNC_IN_PROGRESS states and list all accounts with the default.

Instructions

Whether the account works: status (connected, not_linked, linking with its pairing code…), sync, how fresh the history is, webhook delivery, versions. accounts lists every account, with default. Call it on NOT_CONNECTED, NOT_LINKED or SYNC_IN_PROGRESS.

Input Schema

NameRequiredDescriptionDefault
account_idNo
include_pictureNoAdd picture_url, the account's own profile photo (the link expires)

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
    • addedInput schema / properties / include_picture
      Added value: +{
+  "default": false,
+  "description": "Add picture_url, the account's own profile photo (the link expires)",
+  "type": "boolean"
+}
  3. Changed1 schema field 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"
  4. Changed2 schema fields changedv0.15.0
    • addedInput schema / additionalProperties
      Added value: +false
    • 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"
+}
  5. 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds some useful context about what is inspected (sync, history freshness, webhook delivery, versions) and that accounts are listed with a default. It says nothing about authentication requirements, rate limiting, or failure behavior when the account is unreachable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and the most useful content (the return-field inventory) comes first, but the structure is telegraphic: a colon list inside a sentence fragment with a trailing ellipsis, followed by a non-sequitur about accounts. Tightening into two clean sentences would cost nothing and read much better.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the enumeration of returned data (status, sync, history freshness, webhook delivery, versions, accounts) carries real weight and is the strongest part. What is missing is the meaning of the enumerated status values and of account_id, which an agent needs to act on the result rather than just fetch it.

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 50%: include_picture is documented in the schema (including the expiring link), but account_id has no description anywhere. The phrase "accounts lists every account, with default" hints at default-account behavior but never states what account_id defaults to or how it selects an account, so the description only partially compensates for the gap.

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 description makes clear this is a health/diagnostic read of the account: connection status, sync progress, history freshness, webhook delivery, versions, and the account list with the default marked. It is distinguishable from siblings like list_chats or link_account, though the verb is implied rather than stated ("Whether the account works") and the parenthetical with an ellipsis is loose.

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?

It gives explicit trigger conditions: "Call it on NOT_CONNECTED, NOT_LINKED or SYNC_IN_PROGRESS." That is more than most definitions offer. However, those state names are never defined or sourced, and no alternative is named for the NOT_LINKED case (link_account is an obvious sibling that is not mentioned).

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