Loading ToolBench
Connect a coding agent to Messages on macOS — read, search, send, react — behind a policy engine whose layers can only ever narrow. MCP server for Claude Code and Codex.
Strong tool definitions with clear naming (verb_noun pattern), comprehensive descriptions (avg 180 chars), and complete JSON schemas with typed parameters. All 9 tools have descriptions and input schemas. However, output schemas are not formally documented, and error handling lacks recovery guidance. Tool composition is excellent, each tool has one responsibility, and parameters accept human-friendly identifiers (chat names, phone numbers, emails) alongside system IDs. Missing: explicit output schema documentation, error classification guidance, and confirmation patterns for destructive operations.
Reads a file attached to a message. Only files inside the Messages attachments directory can be read, and only up to the size the policy allows.
Binds a conversation to a project or session, so imsg_send and imsg_react can omit the chat argument.
Lists iMessage conversations, most recently active first, with participants and a preview of the last message. Use this to find the guid of a conversation before reading or sending.
Lists the phone numbers and email addresses known to Messages.
Reacts to a message with a tapback (emoji reaction). Removing a reaction is done by reacting with the same emoji again.
Reads recent messages from one conversation, newest first, with reactions folded onto the messages they decorate. Reactions the sender later removed are not shown.
Output schemas not formally documented. Tools return structured data (text + data fields) but LLMs cannot see the schema of the 'data' object to plan downstream calls or extract fields reliably.
Error handling lacks recovery guidance. Errors (e.g., 'No conversation given and nothing is bound') tell the user what went wrong but not what to do next. Should include actionable next steps like 'Pass `chat`, or run imsg_bind first.'
Destructive operations (imsg_send, imsg_send_file, imsg_react) lack confirmation/dry-run pattern. Tool mentions 'If the policy requires approval this returns a draft with a token instead of sending' but this is policy-dependent, not guaranteed. Should support explicit confirmation step.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2025-06-18+ | v2 |
Searches message text across conversations. There is no index — message bodies live inside a binary archive and have to be decoded — so this reports how many rows it examined and whether it stopped early, which distinguishes "nothing matched" from "stopped looking". Narrow with `chat` or `from` when you can.
Sends a message to a conversation. If the policy requires approval this returns a draft with a token instead of sending; show the draft to the person running the agent.
Sends a file to a conversation. If the policy requires approval this returns a draft with a token instead of sending; show the draft to the person running the agent.
Parameter 'emoji' in imsg_react lacks format constraints. Description says 'Emoji to react with' but does not specify: single emoji only? Multiple? Skin tone variants? Should include regex pattern or enum of valid tapback types.
imsg_bind description is vague about scope. 'Binds a conversation to a project or session' does not explain: what is a project? How does binding affect subsequent calls? When should an agent use this vs. passing 'chat' inline? Needs clarity on binding lifecycle and precedence.