Enables sending text and media iMessages to E.164 numbers, checking delivery status, reading conversation history, and verifying whether numbers can receive iMessage versus SMS.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bluereacher-mcp Send an iMessage to +14155552671 saying I'm running late."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server for Blue Reacher. It lets an AI agent send iMessage, check delivery status, read conversations, and check iMessage capability over a dedicated line.
Built on the official @modelcontextprotocol/sdk, stdio transport
Four tools: send_imessage, get_message_status, list_conversations, check_imessage_capability
Reads your API key from the environment
No A2P registration required
Docs: https://docs.bluereacher.com
OpenAPI: https://docs.bluereacher.com/openapi.json
Tool | What it does |
| Send a text and/or media iMessage to an E.164 number. Paced by default, or instant. |
| Look up delivery status of a queued or sent message. |
| Read recent conversation history for a number or group. |
| Check whether numbers can receive iMessage vs SMS. |
Related MCP server: iMessage Max
npm install
npm run build
BLUEREACHER_API_KEY=brk_test_your_key node dist/index.jsA test key (brk_test_...) hits the simulator, so no message is ever sent. Keep live keys (brk_live_...) in the environment, never in a committed config.
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"bluereacher": {
"command": "npx",
"args": ["-y", "bluereacher-mcp"],
"env": {
"BLUEREACHER_API_KEY": "brk_test_your_key"
}
}
}
}Or point at a local build with "command": "node" and "args": ["/absolute/path/to/dist/index.js"].
Add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):
{
"mcpServers": {
"bluereacher": {
"command": "npx",
"args": ["-y", "bluereacher-mcp"],
"env": {
"BLUEREACHER_API_KEY": "brk_test_your_key"
}
}
}
}Blue Reacher also runs a hosted MCP endpoint if you would rather not run this server yourself: https://bluereacher.com/mcp (and a public endpoint at https://api.bluereacher.com/v1/mcp/public). See the docs for details.
Boots the server over an in-memory transport and confirms the tools register. Requires no API key and sends nothing.
npm run smokeMIT. Copyright 2026 Sagency International LLC (Blue Reacher).
Check whether phone numbers can receive iMessage vs SMS. Accepts up to 100 numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| phones | Yes | Phone numbers in E.164 format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It accurately states the core behavior and the input limit, but it does not disclose the return format, per-number result shape, or behavior for invalid/non-E.164 numbers. Basic operation is clear, but deep behavior is not.
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 short sentences with the purpose front-loaded. The second sentence about accepting up to 100 numbers duplicates the schema's maxItems, so it doesn't fully earn its place, but there is no unnecessary 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?
The input side is well covered by the schema, and the tool is simple. However, with no output schema, the description should specify what the tool returns or how to interpret the capability result; it currently leaves that to inference.
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 baseline is 3. The description only restates the maxItems constraint already present in the schema and adds no new meaning about E.164 validation, deduplication, or error handling.
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?
States a specific operation ('check whether phone numbers can receive iMessage vs SMS') on a concrete resource (phone numbers). The iMessage-vs-SMS distinction differentiates it clearly from send_imessage, get_message_status, and list_conversations.
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 use case is implied: check capability before sending an iMessage. However, the description never explicitly says when to use this tool versus send_imessage or get_message_status, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the delivery status of a queued or sent Blue Reacher message by its id.
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes | The message id returned by send_imessage. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The phrase 'look up' indicates a read-only operation, and 'delivery status' implies it returns state information. It doesn't describe error conditions, rate limits, or side effects, but for a simple status lookup, this is adequate. It avoids contradictions and provides enough 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, front-loaded sentence that states the purpose and scope efficiently. There is no waste or redundancy. It gets straight to the point and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides enough context. It tells the agent what the tool does and the parameter's origin. It doesn't describe the return format, but for a status lookup, the agent can infer that it returns a status value. Given the low complexity, the description is sufficiently 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%, as the parameter already has a meaningful description ('The message id returned by send_imessage'). The tool description does not add further parameter semantics beyond what the schema provides. Since the schema covers it well, 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 function: to look up the delivery status of a message by id. It names the specific resource (Blue Reacher message) and distinguishes it from siblings like send_imessage, list_conversations, and check_imessage_capability. The purpose is unambiguous and specific.
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 parameter description mentions the id is returned by send_imessage, which gives clear context that this tool is used after sending a message. It implies the workflow of sending first then checking status. While it doesn't explicitly say when not to use it, the intended usage is well implied. No alternatives are named, but the sibling list makes the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read recent conversation history for a phone number or group chat over a Blue Reacher line.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max messages to return. | |
| phone | No | Phone number in E.164 format for a 1:1 thread. | |
| group_chat_id | No | Group chat id for a group thread. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states 'Read', which signals a non-destructive operation. However, it does not disclose any potential side effects (none expected), rate limits, pagination behavior, or default ordering. The 'recent' qualifier hints at a time-based filter but adds minimal context. It does not contradict annotations but leaves room for more behavioral detail.
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 that front-loads the action ('Read') and the resource ('recent conversation history'). It is concise with no wasted words or redundant information. Every part contributes to the core meaning.
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 list operation with three optional parameters and no output schema, the description is reasonably complete but has gaps. It does not explain the return format, the default limit, or the mutual exclusivity of 'phone' and 'group_chat_id' (though 'or' hints at it). It also does not mention sorting or pagination. Given the simplicity of the tool, these omissions are acceptable but not ideal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds only the clarification that the tool works for a phone number or group chat, which mirrors the schema's descriptions. It does not add meaningful detail about the 'limit' parameter or specify that 'phone' and 'group_chat_id' are mutually exclusive, so the value added over the schema is minimal.
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 states a specific verb ('Read') and a clear resource ('recent conversation history') with a scope ('for a phone number or group chat over a Blue Reacher line'). It clearly distinguishes from siblings like send_imessage, get_message_status, and check_imessage_capability by focusing on reading history, not sending or status checking.
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 reading history, but it does not explicitly mention alternatives or when not to use this tool. It does not name sibling tools or provide conditions that select between them, leaving the agent to infer that reading history is the purpose based on the verb. This is implied usage, not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a text and/or media iMessage to an E.164 number over a Blue Reacher line. Paced (drip) by default; pass send_mode 'instant' to dispatch now.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient phone number in E.164 format, e.g. +13035550101 | |
| message | No | Message text. Required unless media_urls is set. | |
| send_mode | No | drip (default) paces through the pipeline; instant dispatches now. | |
| media_urls | No | 1 to 10 https:// URLs to attach. | |
| message_effect | No | Optional iMessage effect (instant only), e.g. confetti. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It usefully reveals the default pacing and the existence of an instant mode, plus the transport line. However, it does not disclose side effects, return behavior, or constraints such as message_effect being instant-only, which are either left to the schema or unstated.
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 two concise sentences with no filler. It front-loads the action and recipient details, then follows with the mode selection guidance that an agent needs most.
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?
Between the description and the fully documented schema, an agent has enough to invoke the tool correctly: recipient format, message/media combination, send mode, and media URL constraints. The main gap is that no output schema or return-value explanation is provided, and there is no explicit link to check_imessage_capability before sending.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description mentions send_mode and text/media but adds no meaning beyond what the schema's parameter descriptions already provide, so the baseline of 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 uses a specific verb ('Send'), names the exact resource ('text and/or media iMessage'), and specifies the recipient format (E.164) plus the delivery channel ('Blue Reacher line'). This makes it clearly distinct from sibling tools like get_message_status, list_conversations, and check_imessage_capability.
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 gives clear, actionable guidance: drip pacing is the default, and passing send_mode 'instant' is how to dispatch immediately. It does not explicitly name sibling alternatives or state when not to use this tool, but the sending context is clear enough for an agent to select it appropriately.
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.
v0.1.0check_imessage_capabilityget_message_statuslist_conversationssend_imessageScored across 4 tools
Each tool has a distinct responsibility: sending, checking delivery status, reading conversation history, and verifying iMessage capability. There is no meaningful overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern using snake_case: send_imessage, get_message_status, list_conversations, check_imessage_capability. The naming is predictable and uniform.
Four tools is a reasonable, focused size for an iMessage-sending server. The set feels slightly lean but each tool earns its place and the count is not a problem.
The core iMessage workflow is covered: send, check status, view conversation history, and verify capability. Minor gaps exist, such as no explicit message-content retrieval by ID or inbound message handling, but agents can work around these.
Give your AI agents a real WhatsApp number to send and receive messages.
Phone, SMS & email for AI agents — one remote MCP endpoint, OAuth login, zero install.
Communication stack for AI agents: SMS, AI voice calls, phone numbers, and account events.
Give AI agents a phone number. Voice calls, SMS, and phone number management for MCP clients.
