Loading ToolBench
MCP server exposing Mac capabilities (iMessage, Mail, Calendar, Notes, Reminders, WhatsApp) for AI agents
Machina MCP provides 17 tools across iMessage, Notes, Reminders, Calendar, Mail, and WhatsApp with functional schemas and descriptions. However, the server exhibits significant gaps in parameter documentation, schema completeness, error handling guidance, and output structure documentation. Most tool descriptions are brief and lack context about when to use each tool or what happens on failure. Many parameters lack descriptions entirely or are under-specified. No documented output schemas are visible in the source. Tool names follow verb_noun patterns correctly, but parameter naming could be more explicit about accepting multiple input types (contact name vs phone vs email). The composition is strong, tools are single-responsibility, but chains lack clarity about which IDs/fields are returned to enable downstream calls.
List events from Apple Calendar
Get a conversation formatted for LLM analysis. Returns messages in a structured format with clear identification of who sent each message (you vs others), conversation metadata, and attachment references. Ideal for AI assistants analyzing message history.
List all conversations/chats with recent activity
Get details about a message attachment by ID
Read recent messages from a specific contact or conversation
Get most recent messages across all conversations
Output schemas not documented. The source code shows no documented return types for any tool. Callers cannot plan downstream tool invocations or extract required chaining fields (e.g. what fields does imessage_read return to feed into imessage_get_attachment?). This violates the schema documentation pattern and forces LLMs to guess about response structure.
Parameter descriptions are minimal or missing context. Most read tools (imessage_read, imessage_recent, imessage_search, imessage_conversations, calendar_list, notes_list) have descriptions of 40-50 chars that lack actionable context: when should the LLM choose imessage_read vs imessage_recent vs imessage_search? What does 'limit' actually control? Are results paginated? Is there a next_cursor? This forces LLMs to guess at tool selection and behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Search messages by text content
Send an iMessage to a contact. Accepts contact name, phone number, or email. Returns disambiguation options if multiple contacts match.
Send an email via Apple Mail
Create a new note in Apple Notes
List notes from Apple Notes
Read the content of a specific note
Search notes by content or title
Create a new reminder
List reminders from Apple Reminders
Read recent messages from a WhatsApp contact or group
Send a WhatsApp message via WhatsApp Web connection
Parameter 'contact' and 'to' accept multiple input types (name, phone, email) but lack explicit documentation of this flexibility or disambiguation behavior. The imessage_send description notes 'Returns disambiguation options if multiple contacts match' but does not explain what structure those options have or how the LLM should handle them. This ambiguity forces trial-and-error calls.
Error handling guidance is absent. No tool description explains what happens on failure, how to recover, or what intermediate steps the LLM should take. For example, if imessage_send fails because contact is ambiguous, what should the LLM do? Look for a disambiguation response? Call a different tool? This leaves agents stranded on errors.
Tool composition clarity is weak. For read operations on messages/notes/reminders, the descriptions do not explain the distinction between them or when to prefer one over another. E.g., imessage_read vs imessage_recent vs imessage_search, when should an LLM pick each? The descriptions are too similar and lack dependency hints.
No confirmation or dry-run support for destructive operations. Tools like imessage_send, mail_send, notes_create, reminders_create, whatsapp_send are write operations but lack any mention of confirmation, dry-run, or preview. Agents could inadvertently send messages or create records without an explicit go-ahead.
Pagination and result limits not documented. Many tools return lists (imessage_read with limit, imessage_conversations with limit, notes_list with limit) but descriptions do not explain: Is the limit a hard cap? Are results paginated with next_cursor? What happens if there are more results? Do results return a total count? This ambiguity breaks tool composition.
Parameter naming could be more explicit. 'contact' is used across multiple tools but sometimes means a name, phone, email, or group name. Naming convention like 'contact_identifier' or explicit separate parameters (contact_name, contact_phone, contact_email) would reduce ambiguity. Current names force LLMs to infer valid input types from descriptions alone.