Loading ToolBench
Enhanced Apple MCP tools with email folder management, contacts, notes, messages, and mail integration
This server defines 7 tools with explicit schemas and descriptions visible in tools.ts and package.json. All tools have names, descriptions, and input schemas with enumerated operations. However, there are significant gaps in parameter descriptions, output schema documentation, error handling guidance, and pattern adherence. Most parameters lack descriptions explaining their purpose, constraints, or format. No output schemas are documented. Error handling is absent, no guidance on recovery, retryability, or actionable error messages. The tool names are mostly generic nouns (contacts, notes, messages, mail, reminders, calendar, webSearch) rather than action-verb patterns (search_contacts, create_note, send_message). This forces the LLM to infer intent from descriptions alone. Security concerns: sensitive operations (send messages, send emails, create calendar events) lack confirmation patterns or permission gates. The server is STDIO-only, which caps protocol readiness at 50 and prevents remote deployment.
Search, create, and open calendar events in Apple Calendar app
Search and retrieve contacts from Apple Contacts app
Interact with Apple Mail app - read unread emails, search emails, send emails, create folders, and organize emails
Interact with Apple Messages app - send, read, schedule messages and check unread messages
Search, retrieve and create notes in Apple Notes app
Search, create, and open reminders in Apple Reminders app
Search the web using DuckDuckGo and retrieve content from search results
No verb-driven tool names. Names are generic nouns (contacts, notes, messages, mail, reminders, calendar, webSearch) that force LLMs to read descriptions to infer intent. Best practice: 'search_contacts', 'create_note', 'send_message', 'send_email', 'create_reminder', 'create_event', 'search_web'. This increases LLM selection accuracy and reduces ambiguity when many tools are available.
Output schemas not documented for any tool. Tool descriptions do not specify what fields are returned, their types, or structure. This forces LLMs to guess what data they receive and plan downstream actions without knowing available fields. Example: does 'send_message' return a message_id, timestamp, or success boolean? Without documented output, agents cannot chain tools confidently.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-04-07 | F | 28 | - | v1 |
Conditional required parameters not marked in schema. Tools like 'mail' and 'calendar' accept an 'operation' enum, and required parameters depend on which operation is chosen (e.g., 'searchTerm' required only for operation='search'). JSON Schema does not support conditional 'required' arrays in the current definition, dependencies are only documented in prose descriptions, which LLMs may miss. This invites missing-parameter errors.
Parameter format constraints missing. Parameters like 'phoneNumber', 'scheduledTime', 'fromDate', 'toDate' lack inline format guidance. Example: is phoneNumber E.164 format ('+1-555-0100') or local ('555-0100')? Are dates ISO 8601 or another format? Constraints should be in parameter descriptions (e.g., 'ISO 8601 string') or JSON Schema pattern/format fields.
Destructive operations lack confirmation pattern or warning. Tools like 'send_message', 'send_email', 'moveEmails', and 'create_event' modify state irreversibly, but descriptions do not warn of side effects or offer dry-run/confirmation steps. Best practice: destructive operations should either document they are irreversible, support a 'dry_run' parameter, or require explicit confirmation (e.g., 'confirm=true').
No error handling or recovery guidance. Tool descriptions do not explain failure modes, how to recover, or what information the LLM should provide to retry. Example: if 'create_event' fails because the calendar doesn't exist, the description should suggest 'list available calendars' or 'use the default calendar'. Absent guidance forces LLMs into unproductive retry loops.
Security: sensitive tools lack permission gates or audit hints. Tools like 'send_message', 'send_email', and 'moveEmails' perform actions that should be auditable and possibly gated. No mention of what permissions are required, whether actions are logged, or how to restrict which agents can invoke sensitive tools.
No pagination or result-limit documentation. Tools like 'list_contacts', 'list_notes', 'list_events' do not specify maximum results returned or whether pagination is supported. Without limits, large result sets could exhaust context windows. Baseline: set reasonable caps (20-50 items default) and document them.
Parameter type inconsistency: 'limit' sometimes specified as 'number' without min/max bounds. Unbounded numeric parameters invite LLMs to pass absurd values (e.g., limit=999999). Best practice: specify min and max (e.g., limit 1-100, default 20).
Tool naming inconsistency: 'webSearch' uses camelCase while all others use snake_case. Standardize to snake_case for consistency and easier LLM parsing.