Skip to main content
Glama
razvangirgiz

wazap-mcp

by razvangirgiz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Link a WhatsApp account

link_account

Pair wazap with WhatsApp when status shows not_linked, logged_out, session_corrupt, or auth_failure. Show the returned code, guide phone-number linking, and poll status every 10 seconds until connected.

Instructions

Pair wazap with the user's WhatsApp when get_status says not_linked, logged_out, session_corrupt or auth_failure. Show the user the code it returns: WhatsApp → Settings → Linked devices → Link a device → Link with phone number instead. Then poll get_status every 10 s until connected.

Input Schema

NameRequiredDescriptionDefault
phoneYese.g. +15550100
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. 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 / phone / description
      Previous value: -"International format, e.g. +15550100"New value: +"e.g. +15550100"
  3. Addedv0.15.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare the safety profile (not read-only, non-idempotent, open-world); the description adds what the agent actually needs: the tool returns a pairing code that must be shown to the user, the exact WhatsApp menu path the user follows, and the required polling cadence until the connection succeeds. That is substantial context beyond the structured fields.

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?

Three sentences, front-loaded with the trigger conditions, then the user-facing procedure, then the polling requirement. No filler; each sentence carries information the agent needs to act.

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?

No output schema exists, so the description usefully explains that a code is returned and how to use it, plus the completion check via get_status. The only gap is the undocumented account_id parameter, which is minor for the primary linking flow.

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

Parameters2/5

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

Schema description coverage is only 50% (phone has an example, account_id has nothing), and the description never mentions either parameter. It neither clarifies the phone format required nor explains when account_id should be supplied, so it fails to compensate for the 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?

States a specific verb and resource (pair the app with the user's WhatsApp) and ties it to a concrete precondition surfaced by the sibling get_status. An agent can distinguish this from status-checking or messaging tools without opening any 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?

Explicitly names the four get_status values that should trigger the call (not_linked, logged_out, session_corrupt, auth_failure) and specifies the follow-up loop (poll every 10 s until connected). It also gives the human-facing procedure to hand to the user, leaving little to inference.

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