Provides tools for sending WhatsApp messages (text, template, media), listing WhatsApp templates, and receiving inbound WhatsApp messages via webhooks, as part of the Convertway omnichannel communication platform.
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., "@Convertway WhatsApp MCP Server Send a WhatsApp message to +1234567890 saying 'Your order has shipped!'"
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.
MCP Server for WhatsApp Business API via Convertway by Unicommerce — omnichannel communication layer for WhatsApp, SMS, and Email. Built for AI coding tools (Claude Code, Cursor, etc.).
3 Channels — WhatsApp (text/template/media), SMS, Email (CC/BCC)
11 MCP Tools — send, receive, list templates, check delivery, log conversations
15 Message Templates — across 7 modules: shipment, payment, mis, support, alerts, b2b, escalation
Dual Transport — stdio (local CLI) or HTTP (remote server)
Inbound Webhooks — receive and process incoming messages
Conversation Store — file-based persistence
Related MCP server: WhatsApp Cloud API MCP Server
npm install
cp .env.example .env
# Edit .env: set CONVERTWAY_LICENSE_KEY
npm run dev # stdio mode (local)
npm run dev:http # HTTP mode (remote)Run as a remote MCP server for Claude Code, Cursor, or any MCP client:
npm run start:httpThe server exposes a unified Express app on a single port:
Endpoint | Method | Purpose |
| POST / GET | MCP Streamable HTTP endpoint |
| POST | Convertway webhook callbacks |
| GET | Health check |
{
"mcpServers": {
"convertway": {
"url": "http://localhost:3000/mcp"
}
}
}Tool | Description |
| Send WhatsApp text, template, or media messages |
| List approved WhatsApp templates |
| Send SMS with sender ID |
| Send email with CC/BCC |
| Check delivery status by message ID |
| Pull inbound messages from webhook queue |
| Log a conversation record |
| Retrieve conversation history |
| List all template modules |
| List templates for a specific module |
| List all templates across modules |
Variable | Default | Description |
| — | Convertway API license key |
|
| Transport mode: |
|
| HTTP server port |
|
| MCP endpoint path |
|
| Webhook callback path |
| — | SMTP server for email fallback |
src/
├── config.ts # Env-based configuration
├── server.ts # McpServer setup (stdio + HTTP)
├── index.ts # Entry point
├── convertway/
│ ├── client.ts # Convertway API client (Axios, Basic Auth)
│ └── types.ts # TypeScript types
├── templates/
│ └── index.ts # 15 templates with variable interpolation
├── tools/
│ ├── index.ts # Tool registry (11 tools)
│ ├── whatsapp.ts # WhatsApp send + template listing
│ ├── sms.ts # SMS send
│ ├── email.ts # Email send
│ ├── delivery.ts # Delivery status
│ └── conversations.ts # Conversation CRUD
├── webhooks/
│ ├── handler.ts # Inbound message queue
│ ├── router.ts # Express webhook routes
│ └── server.ts # Standalone webhook server
└── storage/
└── conversations.ts # File-based conversation storedocker build -t convertway-mcp .
docker run -e CONVERTWAY_LICENSE_KEY=cw_your_key -e MCP_TRANSPORT=http -p 3000:3000 convertway-mcpRetrieve conversation history for a customer across all channels
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of entries to return (default: 20) | |
| customerId | Yes | Customer identifier to retrieve history for |
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. However, it lacks details such as ordering, pagination behavior, authentication needs, or data limitations, leaving significant unknowns for an agent.
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, front-loaded sentence with no unnecessary words. While concise, it could be slightly more efficient by integrating the parameter scope directly.
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 (2 parameters, both documented) and lack of output schema, the description is minimally adequate. However, it omits return format and sorting details, which would improve completeness.
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 each parameter already described in the schema. The description adds no additional meaning beyond the schema, so a baseline score of 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 clearly states the action ('Retrieve') and the resource ('conversation history for a customer across all channels'). It effectively distinguishes the tool from sibling tools like send_whatsapp or send_sms, 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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or filters. It simply states the function without contextualizing its role among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the delivery status of a previously sent message
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | Channel the message was sent on | |
| messageId | Yes | Message ID returned from a send operation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks details beyond 'Check'. With no annotations, the description should disclose if the tool is read-only, what status values are returned, or any rate limits. The description simply states the purpose without behavioral 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, clear sentence with no unnecessary words. It is appropriately sized for the tool's simplicity.
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 tool with two parameters and no output schema, the description is functional but minimal. It does not hint at return values (possible statuses) or usage constraints, leaving the agent without full 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 coverage is 100%, so the schema fully describes the parameters. The description adds no extra meaning beyond what the schema provides. 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 clearly states the tool's purpose: 'Check the delivery status of a previously sent message'. It uses a specific verb ('Check') and resource ('delivery status') and is distinct from sibling tools like 'send_whatsapp' or 'get_conversation_history'.
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 (e.g., get_conversation_history) or prerequisites (e.g., message must be sent via this system). There is no mention of 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.
List available WhatsApp message templates grouped by module
| Name | Required | Description | Default |
|---|---|---|---|
| module | No | Filter templates by module name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only states the basic action, omitting any mention of permissions, rate limits, pagination, or whether it includes only approved templates. This leaves the agent with insufficient information for safe invocation.
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 concise sentence with no redundant information. It is front-loaded with the core action. However, it could benefit from slightly more structure to note the grouping behavior explicitly.
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, the description should explain the return format of the grouped templates. It only says 'grouped by module' without details on the grouping structure, list size, or any nested data. This incompleteness impairs the agent's understanding of the tool's output.
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 clear description for the single parameter. The description adds context about grouping by module but does not clarify filter behavior (e.g., exact match or substring). Since the schema already covers the parameter well, the baseline of 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 clearly states the tool lists WhatsApp templates grouped by module, which is a specific verb-resource combination. However, it does not differentiate this tool from sibling tools like list_templates_by_module or list_all_templates, which also list templates.
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. With multiple sibling tools for listing templates, the description should explain when grouping is preferable or when to use filtering vs full listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available message templates across all modules and channels
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | Filter by channel: whatsapp, sms, or email |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavior. It implies a read-only listing operation. However, it doesn't mention pagination, rate limits, or what 'available' means. Adequate for a simple list 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?
A single, clear sentence with no redundant information. Every word is necessary and front-loaded.
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 1 parameter, no output schema, and no annotations, the description adequately explains the tool's purpose and scope. It could mention return format, but not essential.
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 baseline is 3. The description adds no new meaning beyond the schema's param description. The phrase 'across all channels' minorly conflicts with the required channel filter.
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', resource 'message templates', and scope 'across all modules and channels'. It effectively distinguishes from siblings like 'list_template_modules' and 'list_templates_by_module'.
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 this tool vs alternatives like 'list_templates_by_module'. The description implies broad listing but doesn't specify when filtering by module is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available template modules (e.g. shipment, payment, support, alerts)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates a simple read operation (listing), but does not disclose any behavioral traits such as authentication, rate limits, or whether the list is static or dynamic. Adequate for a basic list tool, but could be more explicit.
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 sentence, front-loaded with verb and resource, no extraneous information. Perfectly concise for a simple tool.
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, no output schema, and low complexity, the description is nearly complete. Could optionally mention return format (e.g., array of strings), but not required for a straightforward list tool.
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?
Tool has no parameters, so schema coverage is 100%. The description adds value by providing concrete examples of module names, giving semantic context 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 lists all available template modules, with examples (shipment, payment, etc.). It distinguishes from siblings like list_templates_by_module and list_all_templates by focusing on module names rather than templates.
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 this tool versus list_templates_by_module or list_all_templates. The usage is implied: to discover available modules before querying templates by module, but not stated.
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 specific module
| Name | Required | Description | Default |
|---|---|---|---|
| module | Yes | Module name (e.g. shipment, payment, support, alerts, b2b, escalation) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It only states 'List all templates', which is a read operation, but does not mention any behavioral traits such as pagination, ordering, rate limits, or result format. The minimal description leaves significant 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, front-loaded sentence with no wasted words. Every word contributes meaning, and it is appropriately concise for the simple tool.
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 parameter, no output schema), the description is nearly complete. It states the purpose and the filtering aspect. Minor improvement could be a note about return type, but it is sufficient for a basic list endpoint.
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% for the sole parameter 'module', which already includes a list of example values. The tool description ('for a specific module') adds no extra meaning beyond the schema. Baseline of 3 is appropriate given complete 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 verb 'List', the resource 'templates', and the scope 'for a specific module'. This distinguishes it from sibling tools like 'list_all_templates' (no module filter) and 'list_template_modules' (lists modules themselves).
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 that the tool is for retrieving templates for a given module, but it does not explicitly state when to use this tool over alternatives like 'list_all_templates' or 'list_template_modules'. The usage context is implied by the name and scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log a conversation entry to the conversation history store
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | Message delivery status | |
| channel | Yes | Communication channel used | |
| content | Yes | Message content | |
| metadata | No | Additional metadata (tags, campaign name, etc.) | |
| direction | Yes | Direction of the message | |
| messageId | No | Provider message ID for cross-referencing | |
| customerId | Yes | Customer identifier (phone number, email, or user ID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose behavioral traits like side effects, idempotency, or failure modes (e.g., whether duplicate logs are allowed).
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 concise sentence that is front-loaded and clear. It could include more detail without being verbose, but it is not wasteful.
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 7 parameters (5 required) and no output schema, the description is incomplete. It lacks information about return values, side effects, or preconditions for such a data-writing tool.
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 baseline is 3. The description adds no extra meaning beyond the schema; it does not explain parameter relationships or usage patterns.
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 logs a conversation entry, with a specific verb ('Log') and resource ('conversation history store'). It distinguishes from sibling tools like send_whatsapp (sending) and get_conversation_history (retrieving).
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 (e.g., when to log vs. send). The description only states the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve inbound messages received via webhook (WhatsApp, SMS, or Email)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of messages to return (default: 10) | |
| channel | No | Filter by channel | |
| markAsProcessed | No | Mark returned messages as processed (remove from queue) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states what the tool retrieves but fails to disclose that markAsProcessed can remove messages from the queue or that messages are stored in a queue. This is insufficient for a tool with write-like 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, clear sentence with 11 words. It is appropriately concise and front-loaded with the key action.
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 annotations and output schema, the description provides the basic purpose but omits context about the queue behavior, rate limits, or the effect of markAsProcessed. It is marginally adequate for a simple retrieval tool.
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 schema already documents all three parameters. The description does not add additional semantics beyond what the parameter descriptions provide.
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 ('Retrieve') and resource ('inbound messages') and clarifies the channels (WhatsApp, SMS, Email). It clearly distinguishes from sibling tools that are about sending templates or messages.
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 retrieving inbound messages but provides no explicit when-to-use or when-not-to-use guidance compared to alternatives like get_conversation_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an email via Convertway — supports plain text, HTML, CC/BCC, and templates
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | CC recipients | |
| to | Yes | Recipient email address | |
| bcc | No | BCC recipients | |
| body | Yes | Email body content (plain text or HTML) | |
| subject | Yes | Email subject line | |
| templateId | No | Template ID for pre-formatted emails (e.g. mis_daily_report) | |
| templateParams | No | Template variable values |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only mentions supported formats and features. It does not disclose side effects (e.g., delivery guarantees), authentication needs, rate limits, error handling, or whether the tool is idempotent. This is insufficient for a mutation tool with no 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?
A single sentence that is front-loaded with the action and includes key differentiators. It is appropriately sized, though it could be slightly expanded with usage guidance 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 complexity of 7 parameters, no output schema, and no annotations, the description is too sparse. It does not explain return values, error behavior, or constraints (e.g., maximum recipients). The presence of nested objects (templateParams) is unaddressed. The description leaves significant gaps for an agent to safely invoke the tool.
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 schema already documents all 7 parameters. The description adds minimal value by summarizing capabilities (plain text, HTML, CC/BCC, templates) but does not explain when to use templateId versus body, or how templateParams interact. It meets the baseline but does not exceed it.
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 email), the service (Convertway), and lists supported features (plain text, HTML, CC/BCC, templates). It distinguishes itself from sibling tools like send_whatsapp and send_sms by specifying the email channel.
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 this tool versus alternatives. While the sibling tools are for different channels, the description does not mention any prerequisites, limits, or exclusions. The agent is left 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.
Send an SMS message via Convertway
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number with country code | |
| message | Yes | SMS text content (max 160 characters per segment) | |
| senderId | No | SMS sender ID / DLT header |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'send', omitting details like delivery expectations, rate limits, or whether the operation is synchronous.
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, straightforward sentence with no redundancy or fluff. It efficiently conveys the tool's function.
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?
Lacks important context for a simple send tool, such as behavior on failure, confirmation, or queuing. No output schema, and description does not compensate.
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 descriptions for each parameter. The description adds no additional parameter context beyond the schema, achieving the baseline.
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 'send' and resource 'SMS message' via 'Convertway', effectively distinguishing it from sibling tools like send_whatsapp and send_email.
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_whatsapp or send_email. No conditions, prerequisites, or context for selection are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a WhatsApp message via Convertway — supports text, templates, and media messages
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number with country code (e.g. +919876543210) | |
| message | No | Text message content | |
| mediaUrl | No | URL of media to send (image/video/document) | |
| mediaType | No | Type of media being sent | |
| templateId | No | Template ID from the template library | |
| templateParams | No | Template variable values as key-value pairs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility for disclosure. It fails to mention side effects (e.g., message delivery behavior, idempotency), authentication requirements, rate limits, or consequences of invalid inputs (e.g., non-existent template, malformed number). Only basic supported message types are listed.
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, well-formed sentence that efficiently captures the tool's purpose and supported message types. It is front-loaded and contains no filler. However, it could be shortened by removing 'via Convertway' if that is a branding 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?
The tool has 6 parameters, nested objects (templateParams), and no output schema or annotations. The description only lists high-level message types, ignoring crucial details like parameter dependencies (e.g., templateId requires templateParams, mediaUrl requires mediaType), error handling, or response format. This is insufficient for correct agent operation.
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 schema already describes each parameter. The description adds minimal value by grouping parameters under 'text, templates, and media messages', but does not explain how parameters interact (e.g., which combinations are required or mutually exclusive). This is adequate but not above baseline.
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 WhatsApp message' as the core action, visually distinguishing it from sibling tools like send_sms and send_email. It explicitly lists supported message types (text, templates, media), which fully defines the tool's scope.
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 this tool versus sibling tools such as get_whatsapp_templates or list_templates. The description does not mention prerequisites, alternatives, or conditions for choosing text/template/media, leaving the agent to infer usage from the schema alone.
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.
v1.0.0get_conversation_historyget_delivery_statusget_whatsapp_templateslist_all_templateslist_template_moduleslist_templates_by_modulelog_conversationreceive_inboundsend_emailsend_smssend_whatsappTools generally have distinct purposes, but there is overlap among template listing tools (list_template_modules, get_whatsapp_templates, list_templates_by_module, list_all_templates) which could confuse an agent.
Naming conventions are inconsistent: mix of 'list_', 'get_', 'send_', 'log_', 'receive_' verbs, and some tool names like 'list_template_modules' are not verb_noun consistently.
11 tools is well within the recommended 3-15 range; each tool contributes to the server's messaging and template management scope.
Covers sending, receiving, status checking, conversation history, and template listing across three channels. Minor gaps like template creation or contact management are not critical for the core communication use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Send and schedule SMS and WhatsApp messages, manage contacts and templates, and track delivery.
Run WhatsApp Business campaigns from any AI assistant: contacts, segments, and broadcasts.
Send and receive across email, SMS, WhatsApp, and voice. One API, one contract.
Send WhatsApp, SMS and email for South African businesses: contacts, campaigns, templates, webhooks
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/QalaLabs/convertway-whatsapp-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
