Provides tools for analyzing iMessage data on macOS
Server has 7 tools with basic descriptions and input schemas, but significant gaps in parameter documentation, output schema clarity, and error handling guidance. All tools are READ_ONLY (good for safety), but descriptions lack LLM-optimized structure. Parameter descriptions exist but are minimal (avg ~40 chars, below 72-char baseline). No output schemas documented. Error handling returns generic error dicts without recovery guidance. Tool names follow verb_noun pattern (positive), but descriptions don't explain WHEN to use each tool or dependencies between them.
Get basic statistics about your iMessage conversations. Returns: Dictionary containing total messages, unique senders, average message length, etc.
Get detailed statistics for a specific contact. Args: contact: Phone number or handle of the contact Returns: Dictionary with message count, average length, and conversation ratio
Retrieve full conversation history with a specific contact. ⚠️ PRIVACY WARNING: This tool returns actual message content. All data is processed locally and never sent over the network. Args: contact: Contact name, phone number, or email to get conversation with limit: Maximum number of messages to return (default: 100, max recommended: 500) days_back: Only include messages from last N days (optional) Returns: Dictionary containing conversation messages, metadata, and statistics
Analyze conversation patterns and who talks more with each contact. Args: top_n: Number of top conversations to analyze (default: 5) Returns: Dictionary containing conversation statistics and patterns
Get the most frequently used words in your messages. Args: top_n: Number of top words to return (default: 10) Returns: Dictionary of word frequencies
Output schemas not documented. Tool descriptions state 'Returns: Dictionary...' but do not specify field names, types, or structure. LLMs cannot plan downstream calls or extract data reliably.
Error handling returns generic {'error': str(e)} without recovery guidance. LLMs cannot determine if error is retryable, user-fixable, or fatal. E.g., 'Failed to fetch messages. Check Full Disk Access permissions.' is good, but tool errors lack this specificity.
Parameter descriptions are minimal (avg 40 chars vs 72-char baseline). E.g., 'top_n: Number of top words to return (default: 10)' lacks context on valid range, when to use different values, or what 'top' means (by frequency? recency?). Descriptions should be 50-200 chars with actionable constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
List all your contacts with message counts. Args: limit: Maximum number of contacts to return (default: 20) Returns: List of contacts with their message counts
Search through your messages for specific content. Args: query: Text to search for in messages limit: Maximum number of results to return (default: 10) Returns: List of matching messages with sender and content
No pagination support. list_contacts returns up to 20 items, search_messages up to 10, get_conversation up to 1000, but no offset/limit flexibility, no total_count, no next_cursor. Large result sets will blow context windows.
Tool descriptions do not explain WHEN to use each tool or dependencies. E.g., should an LLM call get_contact_statistics before get_conversation? Should it search_messages first to find a contact? No guidance forces the LLM to guess.