Integrates with Meta's WhatsApp Business API platform for managing WhatsApp Business accounts and accessing messaging services through Meta's developer infrastructure.
Provides comprehensive integration with WhatsApp Business API for sending text, media (images, videos, documents, audio), interactive messages (lists and buttons), and managing message templates with dynamic parameters.
Click on "Deploy 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., "@WhatsApp MCP Server send a text message to +1234567890 saying 'Your order is ready for pickup'"
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.
A comprehensive Model Context Protocol (MCP) server for WhatsApp Business API integration. This server provides powerful tools for sending various types of messages, managing templates, and handling interactive communications through WhatsApp Business API.
Text Messages - Send plain text and template messages
Media Messages - Send images, videos, documents, and audio files
Interactive Messages - Send lists and button menus
Template Messages - Send approved templates with dynamic parameters
Create Templates - Design new message templates
Check Status - Monitor template approval status
List Templates - View all available templates
Clean Architecture - Modular, maintainable codebase
Error Handling - Robust error handling and logging
Type Safety - Full type hints for better development experience
Environment Based - Secure credential management
Related MCP server: WhatsApp Cloud API MCP Server
git clone <repository-url>
cd whatsapp-mcp
pip install -e .pip install whatsapp-mcpCreate a .env file in your project root:
# Nango Configuration for WhatsApp Business API
NANGO_CONNECTION_ID=your_nango_connection_id
NANGO_INTEGRATION_ID=whatsapp-business
NANGO_BASE_URL=https://api.nango.dev
NANGO_SECRET_KEY=your_nango_secret_key
# WhatsApp Business Configuration (Optional - can be set per call)
WHATSAPP_PHONE_NUMBER_ID=your_whatsapp_phone_number_id
WHATSAPP_BUSINESS_ACCOUNT_ID=your_whatsapp_business_account_idEnvironment Variables: Set your phone number ID and business account ID once in environment variables, then use them across all function calls without needing to specify them each time.
Flexibility: You can still override the environment variables by passing explicit values to individual function calls when needed.
Simplicity: For most use cases, you'll only need to set the environment variables once and then use simpler function calls:
# Simple - uses environment variables
send_text_message(to="+1234567890", message="Hello!")
# Explicit - overrides environment variables
send_text_message(to="+1234567890", message="Hello!", phone_number_id="different_id")Set up a Nango account
Create a WhatsApp Business integration in Nango
Set up your WhatsApp Business API connection
Get your Nango connection ID and secret key
Set up a WhatsApp Business Account
Create a Meta Developer App
Add WhatsApp Business API to your app
Configure the integration in Nango with your WhatsApp credentials
# Run using the installed command
whatsapp-mcp
# Or run directly from source
python main.py
# Or as a module
python -m whatsapp_mcp.server
# Show help
python main.py --helpNote: This server uses the MCP stdio transport protocol and is designed to be run by MCP clients like Claude Desktop. It communicates via stdin/stdout and should not be run directly in interactive mode.
Add this configuration to your Claude Desktop config file:
~/Library/Application Support/Claude/claude_desktop_config.json
%APPDATA%/Claude/claude_desktop_config.json
~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"whatsapp": {
"command": "uvx",
"args": ["git+https://github.com/ampcome-mcps/whatsapp-mcp.git"],
"env": {
"NANGO_CONNECTION_ID": "your_nango_connection_id",
"NANGO_INTEGRATION_ID": "whatsapp-business",
"NANGO_BASE_URL": "https://api.nango.dev",
"NANGO_SECRET_KEY": "your_nango_secret_key",
"WHATSAPP_PHONE_NUMBER_ID": "your_whatsapp_phone_number_id",
"WHATSAPP_BUSINESS_ACCOUNT_ID": "your_whatsapp_business_account_id"
}
}
}
}send_text_messageSend text messages or templates to WhatsApp users.
Parameters:
to (str): Recipient's phone number with country code
message (str, optional): Text message content
template_name (str, optional): Template name to use
language_code (str): Language code for templates (default: "en_US")
phone_number_id (str, optional): Your WhatsApp Business phone number ID (uses env var if not provided)
Example Usage:
# Send text message (using environment variable for phone_number_id)
send_text_message(
to="+1234567890",
message="Hello! How can I help you today?"
)
# Send text message with explicit phone_number_id
send_text_message(
to="+1234567890",
message="Hello! How can I help you today?",
phone_number_id="1234567890"
)
# Send template message
send_text_message(
to="+1234567890",
template_name="welcome_message",
language_code="en_US"
)send_image_messageSend images with optional captions.
Parameters:
to (str): Recipient's phone number
image_url (str): Public URL of the image
caption (str, optional): Image caption
phone_number_id (str, optional): Your WhatsApp Business phone number ID (uses env var if not provided)
send_video_messageSend videos with optional captions.
Parameters:
to (str): Recipient's phone number
video_url (str): Public URL of the video
caption (str, optional): Video caption
phone_number_id (str, optional): Your WhatsApp Business phone number ID (uses env var if not provided)
send_document_messageSend documents like PDFs, Word files, etc.
Parameters:
to (str): Recipient's phone number
document_url (str): Public URL of the document
caption (str, optional): Document caption
filename (str, optional): Filename for the document
phone_number_id (str, optional): Your WhatsApp Business phone number ID (uses env var if not provided)
send_audio_messageSend audio files and voice messages.
Parameters:
to (str): Recipient's phone number
audio_url (str): Public URL of the audio file
phone_number_id (str, optional): Your WhatsApp Business phone number ID (uses env var if not provided)
send_list_messageSend interactive list messages with selectable options.
Parameters:
to (str): Recipient's phone number
sections (list): List of sections with options
header_text (str): Header text (default: "Available Options")
body_text (str): Body text
footer_text (str): Footer text
button_text (str): Button text (default: "Options")
phone_number_id (str, optional): Your WhatsApp Business phone number ID (uses env var if not provided)
Example Usage:
sections = [
{
"title": "Main Menu",
"rows": [
{
"id": "option_1",
"title": "Product Info",
"description": "Get information about our products"
},
{
"id": "option_2",
"title": "Support",
"description": "Contact customer support"
}
]
}
]
send_list_message(
to="+1234567890",
sections=sections,
body_text="How can we help you today?"
)send_button_messageSend interactive messages with up to 3 buttons.
Parameters:
to (str): Recipient's phone number
body_text (str): Main message text
buttons (list): List of buttons (max 3)
header_text (str, optional): Header text
footer_text (str, optional): Footer text
phone_number_id (str, optional): Your WhatsApp Business phone number ID (uses env var if not provided)
send_template_messageSend approved template messages with dynamic parameters.
Parameters:
to (str): Recipient's phone number
template_name (str): Name of approved template
parameters (list, optional): List of parameters for template variables
language (str): Template language code (default: "en")
phone_number_id (str, optional): Your WhatsApp Business phone number ID (uses env var if not provided)
Example Usage:
parameters = [
{"type": "text", "text": "John Smith"},
{"type": "text", "text": "December 25, 2024"}
]
send_template_message(
to="+1234567890",
template_name="appointment_reminder",
parameters=parameters,
language="en"
)check_template_statusCheck the approval status of a template.
Parameters:
template_name (str): Name of the template to check
business_account_id (str, optional): WhatsApp Business Account ID (uses env var if not provided)
list_templatesList all templates for your business account.
Parameters:
status_filter (str, optional): Filter by status (APPROVED, PENDING, REJECTED)
business_account_id (str, optional): WhatsApp Business Account ID (uses env var if not provided)
create_templateCreate a new message template.
Parameters:
template_name (str): Name for the new template
language (str): Language code
category (str): Template category (MARKETING, UTILITY, AUTHENTICATION)
components (list): List of template components
business_account_id (str, optional): WhatsApp Business Account ID (uses env var if not provided)
whatsapp-mcp/
āāā src/
ā āāā whatsapp_mcp/
ā āāā __init__.py
ā āāā server.py # Main server entry point
ā āāā tools/ # MCP tools
ā ā āāā __init__.py
ā ā āāā messages.py # Message sending tools
ā ā āāā interactive.py # Interactive message tools
ā ā āāā templates.py # Template management tools
ā āāā utils/ # Utilities
ā āāā __init__.py # Core utilities
ā āāā client.py # WhatsApp API client
āāā .env.example # Environment template
āāā pyproject.toml # Project configuration
āāā README.md # This filegit clone <repository-url>
cd whatsapp-mcp
pip install -e ".[dev]"black src/
isort src/mypy src/pytest# Send a simple text message (using environment variables)
result = send_text_message(
to="+1234567890",
message="Hello! Welcome to our service."
)# Send an image with caption
result = send_image_message(
to="+1234567890",
image_url="https://example.com/image.jpg",
caption="Check out our new product!"
)# Send an interactive list
sections = [
{
"title": "Services",
"rows": [
{
"id": "service_1",
"title": "Web Development",
"description": "Custom website development"
},
{
"id": "service_2",
"title": "Mobile Apps",
"description": "iOS and Android app development"
}
]
}
]
result = send_list_message(
to="+1234567890",
sections=sections,
body_text="What service are you interested in?"
)# Send template with dynamic content
parameters = [
{"type": "text", "text": "Alice Johnson"},
{"type": "text", "text": "Premium"},
{"type": "text", "text": "January 15, 2025"}
]
result = send_template_message(
to="+1234567890",
template_name="subscription_confirmation",
parameters=parameters
)Environment Variables: Store sensitive data like access tokens in environment variables
Input Validation: All inputs are validated before API calls
Error Handling: Secure error messages that don't expose sensitive information
Rate Limiting: Respect WhatsApp API rate limits
Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
Documentation: Check this README and inline code documentation
Issues: Report bugs and request features via GitHub Issues
WhatsApp API: Refer to WhatsApp Business API Documentation
Initial release
Basic message sending capabilities
Template management
Interactive messages
Claude Desktop integration
Clean modular architecture
Note: This MCP server requires a WhatsApp Business API account and valid access tokens. Make sure to comply with WhatsApp's terms of service and messaging policies.
Check the approval status of a WhatsApp template
| Name | Required | Description | Default |
|---|---|---|---|
| template_name | Yes | Name of the template to check | |
| business_account_id | No | WhatsApp Business Account ID (optional, uses env var if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('check') but doesn't describe what the check entails (e.g., returns approval state like 'pending', 'approved', 'rejected'), potential errors, or any side effects. This is a significant gap for a tool with no structured safety hints.
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, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It clarifies the purpose but lacks details on behavior, usage context, and return values, which are needed for full agent understanding. It meets the bare minimum but has clear gaps.
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 input schema has 100% description coverage, clearly documenting both parameters. The description adds no additional meaning beyond the schema, such as explaining the relationship between template_name and business_account_id or providing examples. Baseline 3 is appropriate since the schema does the heavy lifting.
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's purpose with a specific verb ('check') and resource ('approval status of a WhatsApp template'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_templates' or 'create_template', which might also involve template status information, so it falls short of a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_templates' (which might show statuses) or 'send_template_message' (which might require approved templates), nor does it specify prerequisites or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new WhatsApp message template
| Name | Required | Description | Default |
|---|---|---|---|
| template_name | Yes | Name for the new template | |
| language | Yes | Language code for the template | |
| category | Yes | Template category | |
| components | Yes | List of template components | |
| business_account_id | No | WhatsApp Business Account ID (optional, uses env var if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It states 'Create' which implies a write operation, but doesn't cover permissions needed, rate limits, whether the template is immediately usable, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, clear sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it efficient and easy to parse. Every word earns its place, with no redundancy or fluff.
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 complexity of creating a WhatsApp template (with 5 parameters, 4 required, and no output schema), the description is insufficient. It lacks details on behavioral aspects (like permissions or side effects), doesn't explain the relationship with sibling tools, and provides no guidance on usage. Without annotations or an output schema, the description should do more to compensate for these gaps.
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 description adds no parameter-specific information beyond what's in the input schema, which has 100% coverage with detailed descriptions for all parameters. Since the schema fully documents each parameter (e.g., 'template_name' as 'Name for the new template'), the description doesn't need to compensate, but it also doesn't provide additional context like examples or constraints not in the 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 action ('Create') and resource ('new WhatsApp message template'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'list_templates' or 'send_template_message' by focusing on creation rather than listing or sending. However, it doesn't explicitly differentiate from other creation tools (though none exist in the sibling list), keeping it from a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a business account), compare it to similar tools like 'send_template_message', or specify use cases (e.g., for marketing vs. authentication). This lack of context leaves the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all templates for a WhatsApp Business Account
| Name | Required | Description | Default |
|---|---|---|---|
| status_filter | No | Optional status filter (APPROVED, PENDING, REJECTED) | |
| business_account_id | No | WhatsApp Business Account ID (optional, uses env var if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'List all templates' which implies a read operation, but doesn't disclose behavioral traits like whether it requires authentication, rate limits, pagination behavior, or what format the list returns. For a tool with zero annotation coverage, this is insufficient.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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 annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain what 'list all templates' returns (structure, fields), how it handles optional parameters, or how it differs from related tools. For a listing tool in a rich WhatsApp API context, more context is needed.
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 100%, so the schema already documents both parameters fully. The description doesn't add any meaning beyond what the schema provides about 'status_filter' or 'business_account_id'. Baseline 3 is appropriate when the schema does all the parameter documentation work.
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 ('List all templates') and the resource ('for a WhatsApp Business Account'), providing specific verb+resource pairing. However, it doesn't explicitly differentiate from sibling tools like 'check_template_status' which might also involve template retrieval, making it a 4 rather than a 5.
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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'check_template_status' and 'send_template_message', there's no indication whether this is for bulk listing versus status checking or sending. No prerequisites, exclusions, or comparison context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an audio/voice message via WhatsApp Business API
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number with country code | |
| audio_url | Yes | Public URL of the audio file to send | |
| phone_number_id | No | WhatsApp Business phone number ID (optional, uses env var if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states what the tool does at a high level. It doesn't mention important behavioral aspects like whether this is a synchronous or asynchronous operation, error handling, rate limits, authentication requirements, or what happens if the audio URL is inaccessible. The description is insufficient for a mutation tool with zero annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality, making it easy to parse quickly.
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 mutation tool (sending messages) with no annotations and no output schema, the description is incomplete. It doesn't address what the tool returns, error conditions, success indicators, or how it fits within the broader WhatsApp Business API context. Given the complexity of messaging APIs and lack of structured metadata, more contextual information would be helpful.
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 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any additional meaning about parameters beyond what's in the schema (e.g., it doesn't explain format requirements for audio_url or provide examples). This meets the baseline expectation when schema coverage is complete.
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 ('send') and resource ('audio/voice message via WhatsApp Business API'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like send_document_message or send_video_message, which would require mentioning it's specifically for audio files rather than other media types.
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 provides no guidance on when to use this tool versus alternatives like send_text_message or send_video_message. There's no mention of prerequisites (such as needing a WhatsApp Business account), use cases for audio messages, or limitations compared to other messaging tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an interactive button message via WhatsApp Business API
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number with country code | |
| body_text | Yes | Main message text | |
| buttons | Yes | List of buttons (max 3) | |
| header_text | No | Optional header text | |
| footer_text | No | Optional footer text | |
| phone_number_id | No | WhatsApp Business phone number ID (optional, uses env var if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the WhatsApp Business API context but lacks critical behavioral details: authentication requirements, rate limits, error conditions, whether messages are queued or sent immediately, or what happens if buttons exceed the max. The description doesn't compensate for the missing annotations.
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, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('send', 'interactive button message', 'WhatsApp Business API') earns its place by defining scope and differentiation.
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 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the response format, error handling, or operational constraints. Given the complexity and lack of structured data, more context about behavior and outcomes is needed.
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 100%, so parameters are well-documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples, format details, or constraints explanation). Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('send'), the resource ('interactive button message'), and the platform ('via WhatsApp Business API'). It distinguishes this tool from sibling tools like send_text_message or send_template_message by specifying the button-based interaction type.
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 usage for sending button messages on WhatsApp, but provides no explicit guidance on when to choose this over alternatives like send_list_message or send_template_message. No prerequisites, limitations, or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a document message via WhatsApp Business API
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number with country code | |
| document_url | Yes | Public URL of the document to send | |
| caption | No | Optional caption for the document | |
| filename | No | Optional filename for the document | |
| phone_number_id | No | WhatsApp Business phone number ID (optional, uses env var if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Send') but doesn't mention critical aspects like authentication requirements, rate limits, error handling, or what happens on success (e.g., message ID returned). This is a significant gap for a tool that likely involves external API calls and mutations.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without 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?
Given the complexity of sending messages via an external API, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral traits, response format, or error scenarios, leaving the agent under-informed about how to use this tool effectively in practice.
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 input schema has 100% description coverage, clearly documenting all 5 parameters. The description adds no additional meaning beyond what the schema provides, such as explaining parameter interactions or constraints. Baseline score of 3 is appropriate since the schema does the heavy lifting.
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 ('Send') and resource ('document message via WhatsApp Business API'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like send_image_message or send_video_message beyond the document type, missing a clear distinction in purpose.
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 provides no guidance on when to use this tool versus alternatives like send_text_message or send_template_message. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an image message via WhatsApp Business API
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number with country code | |
| image_url | Yes | Public URL of the image to send | |
| caption | No | Optional caption for the image | |
| phone_number_id | No | WhatsApp Business phone number ID (optional, uses env var if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Send') but doesn't cover critical aspects like authentication needs, rate limits, error handling, or what happens on success/failure. This is a significant gap for a mutation tool in a messaging API context.
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, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity of a messaging API tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values, error cases, or behavioral traits, leaving the agent with insufficient context to use the tool effectively beyond basic parameter passing.
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 input schema has 100% description coverage, so parameters are well-documented in the schema itself. The description adds no additional semantic context beyond what the schema provides (e.g., format details for 'to' or 'image_url'), resulting in a baseline score of 3 as the schema does the heavy lifting.
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 ('Send') and resource ('image message via WhatsApp Business API'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings (like send_audio_message, send_video_message) beyond specifying the media type, missing an opportunity to clarify unique aspects.
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 provides no guidance on when to use this tool versus alternatives (e.g., send_text_message for text, send_template_message for templates). It lacks context about scenarios where sending an image is appropriate, prerequisites, or any exclusions, leaving usage decisions ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an interactive list message via WhatsApp Business API
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number with country code | |
| sections | Yes | List of sections with options | |
| header_text | No | Header text for the message | Available Options |
| body_text | No | Body text for the message | Please select from the following options: |
| footer_text | No | Footer text for the message | Select an option to proceed |
| button_text | No | Button text for the list | Options |
| phone_number_id | No | WhatsApp Business phone number ID (optional, uses env var if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'send' implies a write operation, the description doesn't cover critical aspects like authentication requirements, rate limits, error handling, or what happens upon successful sending. For a mutation tool with zero annotation coverage, this is a significant gap.
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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with zero wasted verbiage.
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 mutation tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It lacks behavioral context (e.g., side effects, error cases), usage differentiation from siblings, and any explanation of the interactive list message concept beyond the name. The schema covers parameters well, but the overall context for an agent is incomplete.
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 100%, so the schema already documents all parameters thoroughly. The description doesn't add any meaningful semantic context beyond what's in the schemaāit doesn't explain the structure of sections/rows, usage patterns, or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('send') and resource ('interactive list message via WhatsApp Business API'), making the purpose evident. However, it doesn't explicitly differentiate this tool from its siblings like send_button_message or send_template_message, which also send interactive messages via the same API.
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 provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for sending different message types (e.g., send_button_message, send_template_message), there's no indication of when a list message is appropriate or what distinguishes it from other interactive message types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a template message with dynamic parameters via WhatsApp Business API
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number with country code | |
| template_name | Yes | Name of the approved template | |
| parameters | No | List of template parameters | |
| language | No | Template language code | en |
| phone_number_id | No | WhatsApp Business phone number ID (optional, uses env var if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions sending via WhatsApp Business API but lacks critical behavioral details: whether this is a mutation (likely yes, but not stated), rate limits, authentication needs, error handling, or what happens on success/failure. This is inadequate for a tool with potential 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?
The description is a single, efficient sentence with zero waste. It is front-loaded with the core purpose and includes key details (dynamic parameters, WhatsApp Business API) without 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?
Given no annotations, no output schema, and a mutation-like tool (sending messages), the description is incomplete. It lacks information on behavioral traits, return values, error conditions, and usage context relative to siblings. This leaves significant gaps for an AI agent to operate effectively.
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 100%, so the schema fully documents all parameters. The description adds minimal value beyond the schema by mentioning 'dynamic parameters' and 'via WhatsApp Business API', but does not elaborate on parameter usage, constraints, or examples. Baseline 3 is appropriate as the schema does the heavy lifting.
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 specific action ('send'), resource ('template message'), and mechanism ('via WhatsApp Business API'), with dynamic parameters highlighted. It distinguishes from siblings like send_text_message or send_image_message by specifying template-based messaging.
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 usage for template-based WhatsApp messaging but does not explicitly state when to use this tool versus alternatives like send_text_message or send_button_message. No guidance on prerequisites (e.g., approved templates) or exclusions is provided.
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 or template message via WhatsApp Business API
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number with country code | |
| message | No | Text message to send (optional if template_name is provided) | |
| template_name | No | Template name to use (optional if message is provided) | |
| language_code | No | Language code for template | en_US |
| phone_number_id | No | WhatsApp Business phone number ID (optional, uses env var if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a 'send' operation (implying mutation) but doesn't mention authentication requirements, rate limits, error conditions, or what happens on success/failure. For a messaging tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place in conveying the core 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 messaging tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after sending (success indicators, message IDs, error responses), doesn't mention authentication or rate limiting, and provides no guidance on tool selection among 10 sibling messaging tools.
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 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (like explaining the relationship between message and template_name). Baseline 3 is appropriate when schema does the heavy lifting.
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 ('send') and resource ('text message or template message via WhatsApp Business API'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like send_template_message or send_button_message, which would require more specific scope definition to earn a 5.
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 provides no guidance on when to use this tool versus alternatives like send_template_message or send_button_message. There's no mention of prerequisites, use cases, or exclusions, leaving the agent with minimal context for tool selection among the messaging siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a video message via WhatsApp Business API
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number with country code | |
| video_url | Yes | Public URL of the video to send | |
| caption | No | Optional caption for the video | |
| phone_number_id | No | WhatsApp Business phone number ID (optional, uses env var if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Send') which implies a write/mutation operation, but doesn't mention authentication requirements, rate limits, error conditions, or what happens upon success. For a tool that interacts with an external API to send messages, this leaves significant behavioral aspects undocumented.
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, efficient sentence that states exactly what the tool does without any wasted words. It's appropriately sized for a straightforward tool and gets directly to the point with no unnecessary elaboration.
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 that sends messages via an external API with no annotations and no output schema, the description is insufficient. It doesn't cover authentication needs, error handling, rate limits, or what the tool returns. Given the complexity of API interactions and the lack of structured behavioral information, the description should provide more operational context.
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 100%, so the schema already documents all 4 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects that the schema does the heavy lifting for parameter documentation, and the description doesn't need to compensate.
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 ('Send') and resource ('video message via WhatsApp Business API'), making the purpose immediately understandable. It distinguishes from some siblings like 'send_text_message' by specifying the media type, but doesn't explicitly differentiate from other media-sending tools like 'send_audio_message' or 'send_image_message' beyond the obvious video vs. audio/image distinction.
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 provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for sending different message types (text, audio, image, document, template, etc.), there's no indication of when a video message is appropriate versus other media types or text messages. No prerequisites, constraints, or comparative context is mentioned.
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.
v1.0.0check_template_statuscreate_templatelist_templatessend_audio_messagesend_button_messagesend_document_messagesend_image_messagesend_list_messagesend_template_messagesend_text_messagesend_video_messageScored across 11 tools
Most tools have distinct purposes, with clear separation between template management (check_template_status, create_template, list_templates) and message sending functions. However, there is some potential confusion between send_template_message and send_text_message, as send_text_message's description mentions 'or template message' which overlaps with the dedicated template message tool.
All tools follow a consistent verb_noun pattern with snake_case throughout. The naming is highly predictable with clear action-object pairs like 'send_audio_message', 'list_templates', and 'create_template'.
With 11 tools, this server provides comprehensive coverage for WhatsApp Business API operations. The count is well-scoped for the domain, offering template management and multiple message types without being overwhelming.
The server covers core WhatsApp Business API functionality well with template lifecycle management and comprehensive message sending capabilities. A minor gap exists in message management operations like retrieving message status or deleting messages, but agents can work effectively with the provided tools.
Run WhatsApp Business campaigns from any AI assistant: contacts, segments, and broadcasts.
WhatsApp for your app or AI agent over OAuth2 ā the same connections WASync runs inside your CRM.
Send and schedule SMS and WhatsApp messages, manage contacts and templates, and track delivery.
Give your AI agents a real WhatsApp number to send and receive messages.
