A Model Context Protocol server that enables semantic search through iMessage history using ChromaDB and local embeddings. Allows searching messages by semantic similarity across all conversations or within specific chats.
The server defines 2 tools with reasonable parameter structure and clear intent, but has significant gaps in parameter descriptions, output schema documentation, and error handling guidance. Both tools are read-only semantic search operations with similar structure. Tool names follow verb_noun convention appropriately (search_messages, search_chat). However, the descriptions lack critical context about when to use one vs. the other, and output schemas are not documented. Parameter descriptions exist but are minimal. No error recovery guidance or validation constraints are evident in the code.
Search within a specific iMessage chat or conversation
Search through iMessage history using semantic similarity to find relevant messages and conversations
Output schema not documented. No description of what fields the response contains, making it impossible for LLMs to plan downstream operations or extract specific data.
Missing parameter type constraints. The 'category' parameter in search_messages accepts arbitrary strings with no enum constraint, inviting hallucinated categories like 'personal', 'work', 'family' which may not exist in the actual data.
Tool descriptions lack selection guidance. Both search_messages and search_chat perform semantic search but the descriptions do not explain when to call one vs. the other (e.g., 'Use search_messages to search across all chats; use search_chat when you already know the chat ID').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
No error recovery guidance in code. The VectorDBClient raises generic RuntimeError exceptions with minimal context. Code shows error logging but the errors returned to the LLM do not guide the agent on retry strategy or alternatives.
Parameter 'chat_id' in search_chat is opaque. No guidance on how to obtain a chat_id or whether human-friendly chat names are accepted. Users say 'search my chat with Jack', not 'search chat_id=12345'.
No input validation constraints. Numeric parameter 'n_results' has no documented minimum/maximum. Code defaults to 10 but does not prevent LLMs from passing unreasonable values like n_results=10000.