Apple Messages MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_chatsA | List conversations, most recently active first. In Claude the result renders as an inline card, so don't repeat its contents in your reply — a one-line summary or the answer to the user's question is enough. Args: limit: Maximum conversations to return (default 30). offset: Conversations to skip, for paging through the list. |
| get_chat_messagesA | Read messages from one conversation, returned oldest-first. In Claude the result renders as an inline card, so don't repeat its contents in your reply — a one-line summary or the answer to the user's question is enough. Args:
chat_id: Conversation id from |
| search_messagesA | Search message bodies across every conversation, over all history. Backed by a local index of decoded message bodies, which is brought up to date automatically. The first search on a large history has to build that index and may take a while; later searches are fast. In Claude the result renders as an inline card, so don't repeat its contents in your reply — a one-line summary or the answer to the user's question is enough. Args:
query: Text to look for (case-insensitive substring match). Leave it
out to search on the filters alone — |
| get_messageA | Read one message in full, including attachments and delivery times. In Claude the result renders as an inline card, so don't repeat its contents in your reply — a one-line summary or the answer to the user's question is enough. Args:
message_id: Message id from |
| get_statsA | Overview of the Messages database: message and chat totals, unread count, attachment count, a per-service breakdown (iMessage / SMS / RCS), and the date range covered. |
| get_attachmentA | Retrieve an attachment's bytes, base64-encoded. Args:
attachment_id: Attachment id from |
| refresh_search_indexA | Update the local search index, and report on it.
Args: rebuild: Discard the index and decode every message again. Needed only to pick up edits to messages older than the recent-edit window. |
| compose_messageA | Open Messages with a recipient and text prefilled, WITHOUT sending. This is the safe way to write a message: it puts the text in front of the
user in Messages and stops, so they read it and press send themselves.
Prefer it over Args: handle: Recipient phone number or email, e.g. "+15551234567". body: Text to prefill. May be empty to just open the conversation. service: "imessage" or "sms" — which transport Messages preselects. |
| send_messageA | Send a message to an existing conversation. This delivers immediately. IRREVERSIBLE — the message goes out as soon as this runs, and scripting
cannot unsend it. Confirm the exact recipient and wording with the user
before calling, and pass confirm=True to acknowledge that. If they have
not clearly asked for it to be sent, use Messages picks the transport (iMessage, SMS, or RCS) for the conversation
itself, which is why this addresses a chat rather than a raw handle. To
start a new conversation, use Args:
chat_id: Conversation id from |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| message_preview | Interactive card that renders Messages results inline in the chat: a conversation list, a bubble transcript, search hits, or one message with its delivery details. Rendered by hosts that support MCP Apps. |
TDQS
Scored across 9 tools
Each tool has a clear primary purpose: listing chats, reading messages, single-message lookup, attachments, stats, compose, send, and index refresh are all distinct. The only mild overlap is between get_chat_messages and search_messages when search is given a chat_id with no query term, but the descriptions explicitly clarify this boundary.
All tools use snake_case with a verb_noun shape (list_chats, get_message, send_message, compose_message, search_messages, refresh_search_index). No mixed conventions or vague standalone verbs.
Nine tools is well-scoped for a Messages client: a compact read/search surface plus the two write paths (compose/send) and one maintenance operation. Nothing feels redundant or missing by count.
Core lifecycle is covered: discover chats, read messages, search, fetch attachments, send and draft messages, plus stats and index maintenance. Minor gaps remain (e.g. group-chat creation or participant management, reactions, marking read), but agents can work around them.