Allows sending iMessages and SMS messages to phone numbers or Apple ID emails via the macOS Messages app.
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., "@imessage-send-mcp send 'See you soon' to +14155551234"
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 minimal MCP server that sends iMessages via the macOS Messages app using osascript. No Full Disk Access required — write-only, never reads your message history.
Exposes one tool to Claude Code (or any MCP client):
send_imessage(recipient, message) — sends an iMessage or SMS to a phone number or Apple ID email
Related MCP server: mac-messages-mcp
macOS (uses osascript + Messages app)
Messages app must be open and signed in to iMessage
Python 3.11+
pip install imessage-send-mcpOr from source:
git clone https://github.com/andyjianzhou/imessage-send-mcp
cd imessage-send-mcp
pip install -e ".[dev]"claude mcp add-json "imessage-send" '{
"command": "python3",
"args": ["-m", "imessage_send_mcp.server"]
}'Then restart Claude Code. The send_imessage tool will be available in your next session.
Once connected, Claude can send messages like:
send_imessage("+14155551234", "Hello from Claude!")Recipients can be:
Phone number in E.164 format: +14155551234
Apple ID email: example@icloud.com
No Full Disk Access needed — this server only sends messages, never reads chat.db
No network requests — runs entirely locally via AppleScript
Minimal surface area — ~50 lines of code, fully auditable
pip install -e ".[dev]"
pytest # run tests
ruff check . # lint
mypy src # type checkMIT
Send an iMessage or SMS via the macOS Messages app.
Args: recipient: Phone number in E.164 format (e.g. +14155551234) or an Apple ID email address. message: Text content to send. Newlines are preserved.
Returns: Confirmation string on success.
Raises: RuntimeError: If osascript exits non-zero (Messages not open, recipient not found, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| recipient | Yes | ||
| message | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses that sending uses osascript, that success returns a confirmation string, and that errors occur if Messages is not open or recipient not found, offering good behavioral insight.
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, structured with clear Args, Returns, and Raises sections, with every sentence contributing essential 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?
For a simple two-parameter tool with an output schema, the description covers purpose, parameters, return value, and errors, making it 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?
Despite 0% schema coverage, the description fully enriches both parameters: recipient format (E.164 or email) and message content (text with newlines preserved), far exceeding the bare 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 sends an iMessage or SMS via the macOS Messages app, specifying the action and resource with precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit format constraints for recipient (E.164 or email) and explains error conditions, but lacks explicit when-to-use or when-not-to-use guidance, though no siblings exist.
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.0send_imessageScored across 1 tool
Only one tool exists, so there is no possibility of ambiguity or confusion with other tools.
With a single tool, naming consistency is not a concern; the name follows a clear verb_noun pattern.
A single tool for iMessage is extremely limited. While sending is a core function, the server lacks any ability to read messages, list conversations, or manage chats, making it feel incomplete for the domain.
The server only covers sending messages. Essential operations like reading, searching, or managing conversations are missing, leaving significant gaps for typical iMessage use cases.
MCP connector for iMessage & Contacts via a local Mac agent + Vercel relay
Let ChatGPT, Claude & Cursor use your Mac: email, calendar, iMessage, Teams, files. Local, free.
Explore your Messages SQLite database to browse tables and inspect schemas with ease. Run flexible…
MCP connector that lets ChatGPT list, search, and run your Apple Shortcuts via a local Mac agent
