Provides tools for AI agents to interact with WhatsApp, including sending messages, media, polls, and locations; reading chats and history; managing groups, communities, newsletters, contacts, presence, and profile.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@zaileys-mcp Send a WhatsApp to +1 555 1234 that the build passed"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Quick start • Why zaileys-mcp • Install • What you can build • Configuration • Docs
This README is ahigh-level overview. The complete guides, tool catalog, and configuration reference live in the documentation site at https://zeative.github.io/zaileys-mcp/.
This drives areal WhatsApp account through the unofficial Web API (via Zaileys/Baileys). WhatsApp may suspend numbers that use unofficial automation, and an AI agent with these tools can message anyone in your account. Use read-only or an allowlist when you don't need full access, and never point it at an account you can't afford to lose.
Add it to your MCP client — npx fetches it on demand. First launch prints a QR to scan in WhatsApp → Linked Devices; the session persists.
{
"mcpServers": {
"whatsapp": {
"command": "npx",
"args": ["-y", "zaileys-mcp"],
"env": { "ZAILEYS_SESSION": "my-wa" }
}
}
}That's it. Restart your client, then ask your agent:
"Send a WhatsApp to +62 812 3456 7890 that the deploy is done ✅"
"Summarize my last 20 messages in the family group."
Works with Claude Desktop, Cursor, and any MCP client that speaks stdio.
Related MCP server: WSAPI WhatsApp MCP Server
Full 1:1 with Zaileys — 60+ tools covering messaging, chats, groups, communities, newsletters, privacy, profile, presence, contacts, and business. Anything Zaileys can do, an agent can do.
Smart tool strategy — all 60+ tools exist, but only a small core stays in the agent's context; the rest are revealed on demand via a find_tools meta-tool. Full capability, small context — no bloating every request.
Zero-config auth — Zaileys handles the WhatsApp connection. First run prints a QR; the session persists, restarts connect silently.
Embeddable — already run a Zaileys bot? Expose it to AI agents in one line; it reuses your live session, no second login.
Safe by design — read-only mode and recipient allowlists for when an agent shouldn't have full reach.
Clean transport — stdio JSON-RPC stays uncorrupted; QR and logs go to stderr. Custom HTTP/SSE transport supported.
No install needed for the standalone server — npx handles it:
npx -y zaileys-mcpTo embed it in your own bot, add it as a dependency:
npm i zaileys-mcp zaileys # or: pnpm add • yarn add • bun addRequires Node.js v20+. Peer dependency: zaileys >= 4.7.
60+ tools, 1:1 with the Zaileys API — every to / chat / jid accepts a phone number or a JID interchangeably.
Agent: "add +62 811 111 111 to the Weekend group and make them admin"
→ find_tools("add member to group") → enables group_add, group_promote, …
→ group_add({ group, participants })
→ group_promote({ group, participants })Messaging — send_text, send_media, send_location, send_poll, send_contact, send_sticker, react, edit_message, delete_message, forward_message, pin_message, unpin_message
Chats — list_chats, get_messages, chat_archive/unarchive/pin/unpin/mute/unmute/mark_read/mark_unread/delete/clear, set_disappearing
Account & contacts — me, check_number, get_profile, save_contact, remove_contact
Presence — send_typing, send_recording, set_presence
Groups — group_metadata/list/create/add/remove/promote/demote/update_subject/update_description/leave/invite_code/invite_revoke/invite_info/invite_accept/join_requests/approve_join/reject_join/setting/join_approval/member_add_mode/toggle_ephemeral
Communities — community_metadata/list/subgroups/create/link_group/unlink_group/leave
Newsletters — newsletter_metadata/messages/create/follow/unfollow/mute/unmute/react
Privacy — privacy_get, blocklist, block, unblock
Profile — set_profile_name/status/picture, remove_profile_picture
Business — business_profile, business_catalog, business_collections
60+ tools is a lot to inject into an agent's context on every request. zaileys-mcp uses progressive tool disclosure (the default): only a small core (~13 tools) stays active, and the rest are revealed on demand via a find_tools meta-tool that enables matches and fires MCP's tools/list_changed.
ZAILEYS_TOOLS=progressive # ~13 core active, rest via find_tools (default)
ZAILEYS_TOOLS=full # all 60+ active
ZAILEYS_TOOLS=core # ~12 core, no discovery
ZAILEYS_TOOLS=send_text,get_messages # a hand-picked set (+ find_tools)Already run a Zaileys client? Expose it to AI agents in one line — it reuses your live session:
import { Client } from 'zaileys'
import { serveMcp } from 'zaileys-mcp'
const client = new Client()
await serveMcp(client) // AI agents can now drive this WhatsApp over stdioRead-only, allowlist, or a custom transport:
import { createMcpServer, serveMcp } from 'zaileys-mcp'
await serveMcp(client, { readOnly: true, allowlist: ['62812xxxxxxx'] })
const server = createMcpServer(client) // bring your own HTTP/SSE transport
await server.connect(myHttpTransport)Standalone (env vars) — programmatic options mirror these one-to-one:
Variable | Default | Description |
|
| Session id (auth persists under |
|
|
|
| — | Phone number (E.164 digits) for pairing-code login |
|
|
|
| — | Comma-separated numbers/JIDs; restricts outbound tools |
|
|
|
Two guardrails, usable in any mode: readOnly (write tools never registered) and allowlist (outbound tools refuse other recipients). Recommended: readOnly for summarizers/monitors, allowlist for personal/team notifiers, a dedicated number for full automation.
🌐 zeative.github.io/zaileys-mcp — full documentation: getting started, tools, tool strategy, safety
⚙️ zeative.github.io/zaileys — the WhatsApp engine underneath
🔌 Model Context Protocol — the MCP standard
Hit a problem or have a feature request? Open an issue.
⭐ Star the repo on GitHub
Distributed under the MIT License. See LICENSE for details.
Mark a chat as read (blue ticks).
| Name | Required | Description | Default |
|---|---|---|---|
| chat | Yes | Phone number or JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It says 'mark as read (blue ticks)' implying a state change, but doesn't mention side effects like triggering read receipts, whether it’s reversible, or if it works only on existing chats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loading the purpose. It is concise but could add a bit more context (e.g., clears unread badge) without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple action with 1 parameter and no output schema, the description provides basic completeness. However, it lacks any mention of prerequisites, permissions, or the effect on the UI (e.g., clearing unread count), which could help an agent invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning beyond the schema's 'Phone number or JID' for the chat parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark a chat as read (blue ticks)' clearly states the action (mark as read) and the resource (a chat), using a specific verb and noun. It distinguishes itself from sibling tools like send_text or list_chats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when a chat is new vs already read, or prerequisites like needing to have the chat loaded. The description lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether phone numbers are registered on WhatsApp.
| Name | Required | Description | Default |
|---|---|---|---|
| numbers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but offers minimal behavioral info. It does not disclose return format, error handling, rate limits, or validity checks for phone numbers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is appropriately sized for a simple tool, though it could benefit from slightly more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and minimal annotations, the description is incomplete. It does not explain the result structure (e.g., per-number boolean) or any constraints on input numbers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only mentions 'phone numbers' without specifying format requirements (e.g., international format). It adds little value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks whether phone numbers are registered on WhatsApp, using a specific verb and resource. It distinguishes from sibling tools that focus on sending messages or retrieving chats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or when not, but the tool's sole purpose is implied by its name and description. It is the only tool that performs this function among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the WhatsApp connection state (connected/connecting/disconnected) and the active account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read operation via 'Get', and specifies the returned data (connection state and active account). It does not disclose potential side effects or auth requirements, but for a status check, this is largely adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words with no redundant information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides sufficient information for an agent to understand what the tool returns. It covers the essential output fields (connection state and active account) and the read-only nature is clear. Sibling tools are action-oriented, making the tool's purpose unambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema is empty. The description adds meaningful value by specifying what the tool returns (connection state and active account), which is not present in the schema. Baseline for 0 parameters is 4, and the description exceeds this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'WhatsApp connection state (connected/connecting/disconnected) and the active account'. It distinguishes itself from sibling tools which are all action-oriented (send, mark, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit when-to-use or alternatives are mentioned, the context of the tool name and sibling tools strongly implies it is for checking connection status before performing other actions. A small gap exists in not explicitly stating this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover more WhatsApp tools that are not currently active. Call this FIRST whenever you need an action or data that the visible tools do not cover (managing groups, communities, newsletters, privacy, profile, business, deleting/forwarding/pinning messages, etc.) — this account has many more capabilities than the tools shown right now. Pass a short description of what you need (or a category: messaging, chat, group, community, newsletter, presence, profile, contact, privacy, business, account); matching tools become callable immediately after.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What you need, e.g. "add member to group", "block contact", or a category like "newsletter" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the behavioral effect: matching tools 'become callable immediately after.' With no annotations provided, the description carries full burden and transparently explains the tool's side effect of activating hidden tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a clear front-loaded purpose statement and helpful examples, but is slightly wordy; however, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter, no output schema, and no annotations, the description thoroughly explains the tool's role in the system, how to use it, and its outcome, making it fully complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'query' already has a good schema description, but the tool description adds rich context (examples, categories) beyond the schema, as schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool discovers more WhatsApp tools not currently active, with a specific verb 'discover' and resource 'WhatsApp tools'. It distinguishes its role from sibling tools by positioning it as a first-resort tool when visible tools don't cover the need.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Call this FIRST whenever you need an action or data that the visible tools do not cover.' Lists example categories and instructs to pass a short description, leaving no ambiguity about invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch recent messages for a chat from the store, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| chat | Yes | Phone number or JID | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is responsible for behavioral disclosure. It only mentions data source and ordering, but omits read-only nature, rate limits, side effects, pagination, or default limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with two parameters and no output schema, the description is adequate but lacks details on default limit, pagination, or return format, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only chat has a description). The tool description does not add meaning for the limit parameter or clarify chat format beyond the schema, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource 'recent messages for a chat', the source 'from the store', and the ordering 'newest first'. This distinguishes it from sibling tools like send_text or list_chats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidelines on when to use this tool versus alternatives like list_chats or get_profile. The purpose is implied but lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a contact/group profile picture URL and status text.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Phone number or JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It states it fetches data but does not mention if it is read-only, requires authentication, or what happens when the target does not exist. This leaves the agent uncertain about side effects and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loading the purpose. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the basic function. However, it omits potential edge cases (e.g., invalid target) and does not describe the return structure, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the only parameter. The description adds no new meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and explicitly states it retrieves a profile picture URL and status text for contacts or groups. This clearly distinguishes it from sibling tools like send_media or group_metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, or any prerequisites. For example, it does not clarify if the target must be a known contact or if this works for any JID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a group subject, description, and participants (with admin flags).
| Name | Required | Description | Default |
|---|---|---|---|
| group | Yes | Group JID (…@g.us) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states it retrieves data but does not mention any side effects, permissions needed, error conditions, or whether it is read-only. With zero annotations, the description should cover these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no extraneous information. Every word is necessary and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description is fairly complete in stating what is returned. However, it lacks usage guidance and behavioral details, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'group' is described in the schema as 'Group JID (…@g.us)'. The description adds no extra meaning beyond the schema. Baseline 3 since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies verb 'Get', resource 'group', and lists exact data returned: subject, description, participants with admin flags. This distinguishes it from siblings like send_media or send_text which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_messages or get_profile. There is no explicit context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent chats from the store.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states 'List recent chats' without explaining ordering, pagination, whether it's read-only, rate limits, or what constitutes 'recent'. Critical behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it omits necessary information. Conciseness should not come at the expense of clarity; this is under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description should at least explain the meaning of 'recent', the default limit, and the return format. It provides none of this, leaving the agent with insufficient context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (limit) with no description, and the tool description does not mention or explain it. With 0% schema description coverage, the description must compensate but fails to add any meaning to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (List) and resource (chats), with a qualifier (recent) and scope (from the store). It distinguishes from siblings like get_messages and send_text, but does not elaborate on what 'recent' means or whether it's all chats or filtered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus sibling tools like get_messages or chat_mark_read, nor does it specify prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the connected WhatsApp account (jid, number, name).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses the basic read-only nature (returning data) but does not mention any potential side effects, rate limits, or authentication requirements beyond what is obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that contains all needed information with no unnecessary words. Front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters, the description is fairly complete by listing return fields. However, no output schema exists, and the description could be enriched with additional context (e.g., typical use cases, format of jid). It is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (100% schema coverage), and the description adds value by listing the returned fields (jid, number, name). This provides meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the connected WhatsApp account with specific fields (jid, number, name). It uses a specific verb ('Return') and resource ('connected WhatsApp account'), distinguishing it from sibling tools that send messages, list chats, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing account info but offers no explicit guidance on when to use this tool versus alternatives or exclusions. No context about prerequisites or caveats is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
React to a message (empty emoji removes the reaction).
| Name | Required | Description | Default |
|---|---|---|---|
| chat | Yes | Phone number or JID | |
| emoji | Yes | ||
| fromMe | No | ||
| messageId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description discloses only that an empty emoji removes the reaction, but does not mention side effects, permissions, rate limits, or other behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loaded with the core action. No extraneous information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters (3 required), no output schema, and no annotations, the description is insufficient. It does not explain the 'fromMe' parameter, emoji format, or required behavior, leaving agents underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'chat' has a description). The description adds no information about parameters like 'emoji', 'fromMe', or 'messageId'. It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'React to a message' with the added nuance that an empty emoji removes the reaction. However, it does not differentiate from sibling tools like send_text or send_media, which are distinct actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about conditions, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a location pin.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Phone number or JID | |
| name | No | ||
| address | No | ||
| latitude | Yes | ||
| longitude | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'Send a location pin', omitting details like whether it creates a message, requires network, or handles errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but at the expense of completeness; a single phrase does not adequately describe the tool's operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain return values, error behavior, or parameter interdependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (only 'to' described). The description does not clarify the meaning or format of 'latitude', 'longitude', 'name', or 'address', leaving agents guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send a location pin' clearly states the action (send) and the resource (location pin), distinguishing it from siblings like send_media or send_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or any prerequisites. The description lacks contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send image/video/audio/document by URL or base64.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Phone number or JID | |
| url | No | ||
| type | Yes | ||
| base64 | No | ||
| caption | No | ||
| fileName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It only states the operation and input methods, but omits details on authentication, size limits, mutability, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no wasted words. Directly communicates the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and missing annotations, the description is too brief. It does not explain return behavior, error conditions, or prerequisites like network state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds value over the schema (which documents only 'to' parameter) by explaining that url and base64 are input methods and type is media category. However, it does not clarify parameters like caption or fileName beyond their names, and schema coverage is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Send image/video/audio/document by URL or base64', specifying verb (send), resource (media types), and delivery methods, distinguishing it from sibling tools like send_text or send_location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like send_text or send_location. Agent must infer based on media type, but no explicit when/when-not or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a text message. Supports bold, italic, strike, code.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Phone number or JID | |
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool supports markdown-like formatting, but omits key behavioral traits such as idempotency, rate limits, delivery guarantees, or error scenarios. This is insufficient for a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences totaling 17 words. Every sentence adds value (purpose + formatting). No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should cover more behavioral context. It lacks details on message length limits, delivery guarantees, error handling, or authentication requirements. This leaves gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'to' has description). The description adds value by noting that the 'text' parameter supports formatting, which compensates partially for the missing schema description. However, it does not provide additional constraints or format details beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a text message', which is a specific verb and resource. It distinguishes itself from sibling tools like send_media and send_location by explicitly focusing on text. The mention of formatting options adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for text messages but provides no explicit guidance on when to use it versus alternatives like send_media or send_location. No exclusion criteria or prerequisites are stated, leaving the agent to infer from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the typing indicator in a chat.
| Name | Required | Description | Default |
|---|---|---|---|
| ms | No | ||
| chat | Yes | Phone number or JID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits such as whether the typing indicator persists, how long it lasts, or if it requires an active chat session. The description provides only the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, fitting in a single sentence. However, it could be structured to front-load essential information like parameter usage. Length is appropriate but lacks detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is insufficient. It omits return behavior, error conditions, and prerequisites. Given the simple nature, more context is needed for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'chat' has a description). The description adds no semantic detail for the 'ms' parameter, which remains unexplained. It does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show the typing indicator in a chat' clearly states the tool's action and resource. However, it lacks context distinguishing it from sibling tools like send_text or chat_mark_read, so it's only minimally clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool (e.g., after receiving a message) or when not to. No alternatives or prerequisites are mentioned. The description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.2chat_mark_readcheck_numberconnection_statusfind_toolsget_messagesget_profilegroup_metadatalist_chatsmereactsend_locationsend_mediasend_textsend_typingEach tool has a clearly distinct purpose, covering different actions like sending various message types, reacting, checking status, and managing chats. There is no overlap or ambiguity.
Most tools follow a verb_noun pattern (e.g., send_media, list_chats), but 'me' and 'react' deviate, and 'group_metadata' uses noun_noun. Overall, the pattern is mostly consistent.
14 tools is well-scoped for a WhatsApp integration, covering messaging, media, reactions, typing, group info, account status, and more. Not too few or too many.
The static set lacks some common operations like group creation or message deletion, but the find_tools mechanism can dynamically activate missing tools. Therefore, notable gaps exist but are mitigable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give your AI agents a real WhatsApp number to send and receive messages.
WhatsApp CRM for AI agents: search contacts, read chats, manage the sales pipeline, send messages.
Drive WhatsApp from any MCP client: pair devices, send text and media, manage contacts and groups.
WhatsApp AI sales agent on your own number via QR, no Meta API: audit chats, edit playbook, orders.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zeative/zaileys-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server