Skip to main content
Glama
razvangirgiz

wazap-mcp

by razvangirgiz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get the WhatsApp connection status

get_status
Read-onlyIdempotent

Check connection, sync progress, linked account, last message, and named contacts for a WhatsApp session. Use after NOT_CONNECTED or before sending to confirm the active account.

Instructions

Check the session: connection status ("connected" means the tools work, "not_linked" means the user must run npx wazap-mcp login), whether the initial history sync has finished, which account is linked, when a message last arrived, the versions and data directory in use, and how many contacts carry a name from the phone's address book (contacts_named: 0 means it never arrived).

Call this whenever another tool reports NOT_CONNECTED, NOT_LINKED or SYNC_IN_PROGRESS, or to confirm which account you are about to send from. Without account_id the top-level fields are the default account, plus accounts listing every live one. While a link is in progress the status is "linking" and pairing carries the code the user still has to type into their phone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_idNoRegistry account id (default, work, …). Omit to resolve from chat_id or message_id, or the default account.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. First observedv0.9.3

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark this as a safe, idempotent read, and the description adds substantial behavior beyond them: the meaning of each status value, the 'linking' intermediate state with a pairing code, the semantics of contacts_named: 0, and the default-account fallback. This is rich operational context an agent cannot get from annotations.

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?

Front-loads the core purpose and keeps the trigger conditions in the second paragraph. It is dense and long, but nearly every clause carries distinct information (status values, pairing code, contacts_named), so little is wasted.

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 carries the full burden of describing returns, and it does so thoroughly: status values and their meanings, sync state, linked account, last-message time, versions, data directory, and the accounts array. Nothing an agent needs to interpret the response is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter is fully documented in the schema (100% coverage), so baseline is 3. The description goes further by explaining the consequence of omitting account_id — top-level fields reflect the default account while `accounts` lists every live one — which adds meaning beyond the schema's wording.

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+resource ('Check the session: connection status') and enumerates the exact fields returned, so an agent knows precisely what this returns. It is clearly distinguished from siblings like link_account and list_accounts by its diagnostic scope.

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?

Explicitly names the trigger conditions ('whenever another tool reports NOT_CONNECTED, NOT_LINKED or SYNC_IN_PROGRESS') and a second use case ('to confirm which account you are about to send from'). It also explains what the not_linked state implies and the remediation command, which is exactly the routing guidance an agent needs.

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