Loading ToolBench
Local MCP server wrapping the imsg CLI so Poke can read/send iMessages
Server has 7 tools with clear action verbs and reasonable descriptions (avg 120 chars). All tools have input schemas with type definitions and parameter descriptions. However, output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal (no recovery guidance, no categorization). Security is strong (auth checks, rate limiting, audit logging). Composition is good (single responsibility per tool, proper chaining via chat_id). Missing: tool annotations (readOnlyHint/destructiveHint), structured error messages, and output schema documentation.
Get a quick summary of recent messages across all chats — useful for 'what did I miss'.
Look up a contact by name and return their phone number(s) and/or email(s).
List recent conversations with chat_id, last message, and (when known) a resolved contact name.
Read recent messages from a conversation, with each sender's contact name resolved when known (useful for group chats).
Search for messages matching a query across all chats.
Send an iMessage or SMS to a recipient. ALWAYS confirm the recipient and exact message text with the user before sending.
Output schemas not documented. LLMs cannot predict response structure (fields, types, nesting). Breaks downstream tool chaining and forces agents to guess field names.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). send_message is destructive but unmarked; read tools are not marked read-only. Agents cannot distinguish safe from risky operations.
Error handling lacks recovery guidance. Subprocess errors (imsg timeout, JSON parse failures) return raw error strings with no actionable next steps for the LLM.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Check the health and status of the iMessage bridge.
send_message lacks dry-run or confirmation step. Irreversible operation (sends SMS/iMessage) should support confirmation before execution to prevent accidental sends.
Parameter descriptions lack format/constraint details. 'limit' params have no min/max bounds; 'hours' in catch_up has no range. Unbounded numeric params invite absurd LLM values.