Provides tools to send WhatsApp messages, list sessions, and get session QR codes via SendAPI.
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., "@SendAPI MCP Server send a WhatsApp message to +1234567890 saying 'Your order is ready'"
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.
Official Model Context Protocol server for SendAPI.
Give any MCP-compatible AI agent (Claude Code, Claude Desktop, ChatGPT/Codex, Cursor, Windsurf, Cline) the ability to send WhatsApp messages, SMS, OTP codes, and email through one REST API.
You need a SendAPI API key. Create one in your dashboard.
The server runs over stdio via npx, so there is nothing to install globally.
Add to your MCP config (claude_desktop_config.json, or .mcp.json in a project):
{
"mcpServers": {
"sendapi": {
"command": "npx",
"args": ["-y", "@sendapi/mcp-server"],
"env": {
"SENDAPI_API_KEY": "sk_live_xxxxxxxxxxxx"
}
}
}
}Same shape: a stdio server with command: npx, args: ["-y", "@sendapi/mcp-server"], and SENDAPI_API_KEY in env.
Related MCP server: WhatsApp Business API MCP Server
Mode | Transport | Best for |
Local ( | stdio | Coding agents on your machine (Claude Code, Cursor, Windsurf, Cline, Codex CLI). |
Hosted ( | streamable HTTP | One-click connectors with no install (Claude/ChatGPT remote connectors, n8n MCP Client node). |
No install. Point your client at the remote URL and authenticate with your API key:
URL: https://sendapi.co/mcp
Auth: Authorization: Bearer sk_live_xxxxxxxxxxxx (or the X-SendAPI-Key header)
The hosted server is multi-tenant and stateless: your key is used only for the lifetime
of each request and never stored server-side. Self-host it yourself with the included
Dockerfile (docker build -t sendapi-mcp . && docker run -p 8080:8080 sendapi-mcp),
then connect to http://localhost:8080/mcp.
Env var | Required | Default | Used by | Notes |
| stdio only | — | stdio | Your SendAPI API key (Bearer token). |
| no |
| both | Override for self-hosted or staging. |
| no |
| hosted | Port the HTTP server listens on. |
Messaging
send_whatsapp — send a WhatsApp message from a connected session
send_bulk_whatsapp — send to many recipients (max 500)
send_sms / send_bulk_sms
send_email / send_bulk_email
Verification
send_otp — send a one-time code (SMS, WhatsApp, or email)
check_otp — verify a code
validate_phone — validate / look up a number
Status & usage (read-only)
get_email_status, get_sms_status, get_whatsapp_message
get_usage — remaining quota across channels
Setup helpers (read-only)
list_whatsapp_sessions, get_whatsapp_session_qr
list_sender_ids, list_email_domains, list_email_templates
Auth, billing, API-key, and team-admin endpoints are intentionally not exposed to agents.
Every send still flows through SendAPI's normal limits and abuse protection. Bulk tools are annotated as high-impact so clients can prompt for confirmation. Errors surface SendAPI's code/message so the agent can self-correct (for example sending_limited or content_blocked).
npm install
npm run build # compile TypeScript to dist/
SENDAPI_API_KEY=sk_test_xxx npm startMIT
Check a one-time password (OTP) the recipient entered against the code that was sent.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient the OTP was sent to (phone or email). | |
| code | Yes | The code the user entered. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and openWorldHint=true. The description adds no additional behavioral context beyond the core action; it does not disclose potential side effects like OTP consumption or invalidation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, clear and front-loaded. It could be slightly more concise but effectively communicates the 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 no output schema, the description does not hint at the response format (e.g., success/failure). It covers the core function but lacks completeness regarding return behavior.
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 does not add extra meaning beyond the schema's parameter descriptions; it merely restates the purpose without detailing parameter semantics.
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 uses the verb 'Check' and specifies the resource: 'a one-time password (OTP) the recipient entered against the code that was sent.' It effectively distinguishes from sibling tools like 'send_otp' which handles sending.
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 after sending an OTP to verify user input, but it does not explicitly state when to use this tool versus alternatives, nor provides when-not or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get delivery status and details for a previously sent email by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Email message ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds 'delivery status and details' but does not disclose additional behavioral traits like potential latency or authorization needs. It is consistent with annotations but contributes little new information.
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-structured sentence that front-loads the action and resource. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter, the description is adequate. However, lacking an output schema, it could be more specific about 'details' (e.g., delivery statuses returned). With annotations covering safety and openness, it is sufficient but not maximally 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 coverage is 100% with the 'id' parameter described. The description does not add beyond the schema's 'Email message ID.' Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'delivery status and details for a previously sent email', and the method 'by its ID'. It distinguishes from sibling tools like get_sms_status (different channel) and send_email (different action).
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 checking status of sent emails but does not explicitly state when not to use or list alternatives. Given sibling names, context is clear but guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get delivery status and details for a previously sent SMS by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | SMS message ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that it returns 'delivery status and details', which provides some context but no extra behavioral traits like error handling or auth requirements.
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 12-word sentence that directly states the tool's purpose with no unnecessary words. It is front-loaded and efficient.
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 one parameter and annotations providing readOnlyHint, the description is adequate. It lacks details on output format but is sufficient given the low complexity.
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 single parameter 'id' described as 'SMS message ID.' The tool description does not add additional semantics beyond the schema, so baseline 3 applies.
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 retrieves delivery status and details for a previously sent SMS using its ID. It uses a specific verb and resource, and distinguishes from sibling tools like send_sms or get_email_status.
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 after sending an SMS to check status, but does not explicitly state when to use versus alternatives or provide exclusions. However, the purpose is clear enough for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current account usage and remaining quota across channels. Useful to check limits before sending in bulk.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds that data is 'current' and covers 'remaining quota across channels,' but does not contradict 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?
Two concise sentences: purpose first, then guidance. No unnecessary words, effectively 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?
With zero parameters, comprehensive annotations, and no output schema, the description fully covers what the tool does and when to use it. No 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?
No parameters exist, so the description does not need to explain them. Baseline 4 applies due to zero parameters.
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 'Get current account usage and remaining quota across channels,' specifying the verb and resource. It differentiates from sibling tools like send_* and other get tools by focusing on account limits.
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?
Explicitly advises using this tool to 'check limits before sending in bulk,' providing clear context and a specific use case. This implicitly advises against using send tools for limit checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get status and details for a WhatsApp message by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | WhatsApp message ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's mention of retrieving status and details adds minimal behavioral context. No side effects or failure modes are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant information. Every word is necessary.
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 1-parameter tool without an output schema, the description is adequate but lacks details on response format, error handling, or message not found scenarios.
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 the 'id' parameter described as 'WhatsApp message ID.' The description adds no further parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (get), resource (WhatsApp message), and output (status and details). It distinguishes from sibling tools like send_whatsapp and check_otp.
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 explicit guidance on when to use this tool versus alternatives like get_email_status or get_sms_status. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the QR code payload to pair a WhatsApp session by scanning it in the WhatsApp app.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | WhatsApp session ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds only that it returns a payload, but doesn't clarify side effects, behavior for already-paired sessions, or format of the payload.
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 key action, no wasted words.
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?
Adequate for a simple tool with one parameter and no output schema. Explains return value is QR payload, but could mention format (e.g., base64 image) or prerequisites.
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 already provides 100% coverage with description 'WhatsApp session ID.' Description adds no additional meaning beyond 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?
Clearly states the verb 'Get', the resource 'QR code payload', and the purpose 'to pair a WhatsApp session'. Distinguishes it from sibling tools like get_whatsapp_message or send_whatsapp.
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?
Implied usage for pairing a session via QR, but no explicit when-to-use or when-not-to-use compared to alternatives like list_whatsapp_sessions or check_otp.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sending domains and their verification status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description need not restate safety. However, it does not mention any additional behavioral traits such as pagination, sorting, or whether the list is comprehensive, which would be helpful.
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, concise sentence that uses active voice and includes the key action and output. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no parameters and no output schema, the description provides the essential information. It could hint at whether the list includes all domains or only verified ones, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 parameters, schema coverage 100% by emptiness), so the description carries no burden here. Per guidelines, baseline is 4 for zero parameters.
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 ('List') and clearly identifies the resource ('sending domains') and the relevant attribute ('verification status'). It distinguishes itself from sibling list tools (e.g., list_email_templates, list_sender_ids) by the object 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 states what the tool does but offers no guidance on when to use it versus alternatives. Given multiple list tools among siblings, explicit context on when to choose this tool would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List saved email templates that can be used with send_email via template_id.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds only the notion of 'saved' templates. This is adequate but does not significantly expand behavioral disclosure beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant information, perfectly front-loaded and concise.
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 (no parameters, no output schema), the description covers all essential aspects: what it does and its relation to send_email. No additional 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?
The tool has no parameters, so schema coverage is trivially 100%. The description does not need to add parameter details; the baseline score of 4 applies per rubric.
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 'List saved email templates' with a specific verb and resource, and adds the usage context 'that can be used with send_email via template_id', which distinguishes it from sibling list tools like list_email_domains and list_sender_ids.
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 when to use this tool (to obtain template_ids for send_email), but does not explicitly exclude other use cases or mention alternatives. This provides sufficient guidance given the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured SMS sender IDs and their approval status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds that it lists approval status, which is helpful but minimal. No contradictions. For a read-only tool with these annotations, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that directly states the tool's function. No superfluous words, well 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 no parameters and no output schema, the description fully covers what the tool does and what it returns (list with approval status). Complexity is low, and description is sufficient.
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?
Input schema has zero parameters and schema description coverage is 100% (vacuously). Baseline of 4 applies; description doesn't need to explain parameters since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List' and resource 'configured SMS sender IDs', clearly stating what data is provided (approval status). It differentiates from sibling list tools like list_email_domains and list_whatsapp_sessions which cover different resources.
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. Among 17 siblings, no when-to-use or when-not-to-use context is provided, leaving the agent to infer from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List connected WhatsApp sessions and their status. Use a session's id with send_whatsapp.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that it lists status, providing behavioral context beyond the annotations without contradiction.
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?
Two concise sentences with no wasted words. Front-loaded with purpose, followed by a usage tip. Every sentence is meaningful.
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?
Adequate for a zero-parameter list tool with good annotations. Could mention pagination or ordering, but not essential for basic operation. The link to send_whatsapp enhances 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?
No parameters in schema, so description doesn't need to add parameter details. It adds value by indicating the output includes sessions and status, compensating for the lack of output 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?
Clearly defines the tool as listing connected WhatsApp sessions and their status. The second sentence connects it to send_whatsapp, distinguishing it from other sibling tools like get_whatsapp_message or send_whatsapp.
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?
Explicitly states when to use the tool and provides a direct link to send_whatsapp. Does not explicitly state when not to use, but the sibling contexts make it clear this is the session list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send the same email to many recipients (max 500). High-impact: confirm the list before calling.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Verified sender address. | |
| html | No | HTML body. Optional if text or template_id is provided. | |
| text | No | Plain-text body. Optional if html or template_id is provided. | |
| subject | Yes | Email subject line. | |
| from_name | No | Display name for the sender (optional). | |
| recipients | Yes | Recipient email addresses. | |
| template_id | No | ID of a saved email template. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, consistent with a mutation tool. The description adds a behavioral warning about high impact and the max recipient limit. It does not contradict annotations and provides useful context for agent decision-making.
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?
Two sentences with no wasted words. The key action and constraint are front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and no output schema. The description mentions the max recipient limit and a warning, but omits details on success/failure behavior, async processing, or error handling. Adequate but not fully complete.
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 parameters. The description adds no additional insight into parameter semantics, such as the relationship between html, text, and template_id. 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 'Send the same email to many recipients (max 500)' with a specific verb, resource, and constraint. It distinguishes from sibling tools like send_email (single recipient) and send_bulk_sms.
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 includes a warning 'High-impact: confirm the list before calling,' implying caution but does not explicitly state when to use this tool versus alternatives like send_email for single recipients or send_otp for one-time codes. No when-not-to guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send the same SMS to many recipients (max 500). High-impact: confirm the list before calling.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | SMS text sent to every recipient. | |
| sender_id | No | Approved alphanumeric sender ID (optional). | |
| recipients | Yes | Phone numbers in international format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readonly (readOnlyHint=false) and open world (openWorldHint=true). The description adds value by explicitly warning 'High-impact: confirm the list before calling,' highlighting potential consequences beyond the annotations. No contradiction detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: the first clearly states the purpose and constraint, and the second adds a critical warning. No unnecessary words, front-loaded and efficient.
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 simplicity of the tool (3 params, no output schema), the description covers the essential context: the operation, the maximum recipients, and a safety note. It could mention response handling or asynchronous nature, but it is largely complete for the use case.
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% with each parameter having a description. The tool description does not add any additional parameter meaning beyond the schema, so the 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 verb (send), resource (the same SMS to many recipients), and a key constraint (max 500). It effectively distinguishes this tool from siblings like 'send_sms' (single recipient) and 'send_bulk_whatsapp' (different 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?
The description provides context by labeling it as 'High-impact' and advising to 'confirm the list before calling,' implying a precautionary usage guideline. However, it does not explicitly state when to use this tool versus alternatives like 'send_sms' for single messages or 'send_bulk_email' for email, though the bulk SMS purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send the same WhatsApp message to many recipients (max 500) from a connected session. High-impact: this contacts many people. Confirm the recipient list before calling.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Message type. Defaults to 'text'. | |
| content | Yes | Message body sent to every recipient. | |
| recipients | Yes | Phone numbers in international format. | |
| session_id | Yes | ID of the connected WhatsApp session to send from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write operation (readOnlyHint false) and side effects (openWorldHint true). Description adds specific behavioral warning about high impact and need for confirmation, which goes beyond 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?
Two sentences: first states core function with key constraints (max 500, connected session), second provides a critical usage warning. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (4 parameters, no output schema), the description covers the main purpose, recipient limit, and prerequisites. Missing details on return value or error conditions, but adequate for a bulk send 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?
Input schema covers 100% of parameters with descriptions. The tool description does not add any additional parameter-level meaning beyond what the schema already provides, 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?
Description clearly states 'Send the same WhatsApp message to many recipients (max 500)', specifying verb (send), resource (WhatsApp message), and scope (many recipients, max 500). It distinguishes from sibling 'send_whatsapp' which targets a single recipient.
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?
Description provides context: 'High-impact: this contacts many people. Confirm the recipient list before calling.' It implies careful usage but does not explicitly contrast with alternatives like 'send_whatsapp'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a single transactional email. Provide html or text (or a template_id with variables).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient email address. | |
| from | No | Verified sender address, e.g. 'Name <you@yourdomain.com>'. | |
| html | No | HTML body. Optional if text or template_id is provided. | |
| text | No | Plain-text body. Optional if html or template_id is provided. | |
| subject | Yes | Email subject line. | |
| from_name | No | Display name for the sender (optional). | |
| variables | No | Key-value variables to render into the template. | |
| template_id | No | ID of a saved email template. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, but the description does not disclose any behavioral traits beyond the sending action, such as rate limits, authentication needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence without fluff. It is front-loaded with the core purpose, though an additional sentence on usage context would improve structure without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, nested objects, no output schema, and side-effect potential (openWorldHint), the description is too brief. It lacks information on return values, error handling, and attachments, making it 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 coverage is 100%, so the baseline is 3. The description adds value by summarizing the relationship between html, text, template_id, and variables, which is not captured in individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send') and the resource ('single transactional email'). It hints at the distinction from bulk sending but does not explicitly differentiate from send_bulk_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?
The description only provides input requirements ('Provide html or text or a template_id with variables') but gives no guidance on when to use this tool versus alternatives like send_bulk_email or send_otp.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a one-time password (OTP) to a recipient over SMS, WhatsApp, or email.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number or email, depending on channel. | |
| ttl | No | Code lifetime in seconds. Defaults to 300. | |
| length | No | Code length (4-8). Defaults to 6. | |
| channel | No | Delivery channel. Defaults to 'sms'. 'auto' picks based on the recipient. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, so the write nature is implied, but the description adds no additional behavioral context such as whether the OTP is generated automatically, any side effects, or constraints. The description simply restates the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence of 15 words, efficiently conveying the core action. It is front-loaded and to the point, though it lacks additional details that could be included without being 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 tool's complexity (sending OTP with multiple channels and parameters, no output schema), the description is too minimal. It does not explain the return behavior, the fact that it generates a code automatically, or any success/failure indicators. The agent has to rely on external knowledge.
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 all parameters are already described in the input schema. The description adds no extra meaning beyond what is in the schema. 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 (send) and resource (one-time password) and lists possible channels (SMS, WhatsApp, email). However, it does not explicitly differentiate from sibling tools like send_sms or send_email, which could confuse an agent about when to use this OTP-specific tool.
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 or when not to use it. There is no mention of prerequisites or context for usage, leaving the agent to infer 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 a single SMS message to a phone number.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number in international format, e.g. +15551234567. | |
| content | Yes | SMS text (up to 1600 characters). | |
| sender_id | No | Approved alphanumeric sender ID (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutation (readOnlyHint=false) and openWorldHint=true. The description adds no additional behavioral context such as delivery guarantees, cost, or error handling. It is consistent but lacks depth.
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 extraneous words. It is appropriately minimal for a simple tool, though could be expanded with usage notes.
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 straightforward tool with a rich schema but no output schema, the description is adequate but does not cover potential edge cases, return values, or prerequisites (e.g., approved sender ID).
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 provides 100% coverage with clear descriptions for all parameters (to, content, sender_id). The description adds no extra meaning beyond the schema, meeting 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 action (Send), the resource (a single SMS message), and the target (a phone number). It effectively distinguishes from sibling tools like send_bulk_sms (bulk) and send_whatsapp (different 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 vs alternatives (e.g., send_bulk_sms for multiple recipients, send_otp for OTPs). Usage is implied but not clarified with conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a WhatsApp message from a connected session to one recipient. Requires a session_id of an already-paired WhatsApp number (see list_whatsapp_sessions).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number in international format, e.g. +15551234567. | |
| type | No | Message type. Defaults to 'text'. | |
| content | Yes | Message body. For non-text types this may be a URL or structured payload. | |
| session_id | Yes | ID of the connected WhatsApp session to send from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutable action (readOnlyHint=false, openWorldHint=true). The description adds the prerequisite of an existing session but does not disclose rate limits, error conditions, or side effects beyond sending.
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?
Two sentences, no wasted words. The first sentence states the main action, the second adds the critical prerequisite and cross-reference. Front-loaded and efficient.
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 send tool with four parameters and no output schema, the description covers the core purpose and prerequisite. It lacks mention of error handling or return value, but is adequate overall.
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 covers all four parameters with descriptions, achieving 100% coverage. The tool description does not significantly add meaning beyond the schema, so score is at 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 tool sends a WhatsApp message to one recipient from a connected session, using specific verb and resource. It distinguishes from siblings like send_bulk_whatsapp by emphasizing single recipient and references list_whatsapp_sessions for prerequisites.
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?
It provides clear context: requires a session_id from an already-paired session and links to list_whatsapp_sessions. However, it does not explicitly state when not to use this tool or mention alternatives for bulk sending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate and look up details (format, country, carrier) for a phone number.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | Phone number to validate, ideally in international format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds context about the specific details looked up (format, country, carrier), enhancing transparency without contradiction. No behavioral traits beyond annotations are omitted.
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 efficiently conveys the tool's purpose without unnecessary words 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 tool has only one parameter, no output schema, and low complexity, the description adequately hints at the output (details like format, country, carrier). It is sufficiently complete for the agent to understand the tool's behavior.
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% with a clear parameter description for 'number'. The tool description does not add significant meaning beyond the schema, so baseline score applies.
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 'Validate and look up details' and the resource 'phone number', specifying the retrieved details (format, country, carrier). It distinguishes from sibling tools like check_otp or send_sms which serve different purposes.
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 clear context but no explicit guidance on when to use this tool versus alternatives or when not to use it. Usage is implied but not stated.
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.0check_otpget_email_statusget_sms_statusget_usageget_whatsapp_messageget_whatsapp_session_qrlist_email_domainslist_email_templateslist_sender_idslist_whatsapp_sessionssend_bulk_emailsend_bulk_smssend_bulk_whatsappsend_emailsend_otpsend_smssend_whatsappvalidate_phoneEach tool targets a distinct action on a specific channel (email, SMS, WhatsApp, OTP, phone validation, or usage). There is no ambiguity between single and bulk send tools, and check_otp is clearly separate from send_otp.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., send_email, get_sms_status, list_whatsapp_sessions, validate_phone. No mixing of styles or vague verbs.
With 18 tools covering email, SMS, WhatsApp, OTP, phone validation, and usage, the count is well-scoped for a messaging API server. Each tool serves a clear purpose without unnecessary duplication.
The tool surface covers all core messaging operations: sending (single and bulk), status retrieval, OTP lifecycle, listing of resources (domains, templates, sender IDs, sessions), usage monitoring, and phone validation. No obvious gaps for the intended domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Phone, SMS & email for AI agents — one remote MCP endpoint, OAuth login, zero install.
Unified inbox MCP for WhatsApp, Telegram, Email, voice — read/send messages, search, AI agents.
Give AI agents real phone numbers, messages, and voice calls via MCP.
Connect any AI agent to 11+ social platforms: schedule, publish & track posts via hosted MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SendAPI-co/sendapi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
