Loading ToolBench
MCP server for accessing macOS contacts database
This server has 7 tools, all READ_ONLY, with consistent naming patterns and present input schemas. Most tools have reasonable descriptions (60-120 chars), meeting the baseline average of 194 chars for description length, though some descriptions are generic. Input schemas are well-formed JSON Schema with type declarations and parameter descriptions. However, output schemas are not documented, a critical gap per the rubric's requirement that 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.' Additionally, error handling is absent from the code sample; no recovery guidance or categorization is visible. The server lacks tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite being explicitly READ_ONLY, and does not demonstrate structured output patterns. Tools are narrowly focused on contact retrieval with good naming discipline (search_contacts, get_contact_by_name, get_all_contacts, etc.), meeting verb_noun conventions. However, parameter descriptions lack depth, e.g., 'Filter by name' tells an LLM what the parameter filters but not the matching semantics (case-insensitive, partial match). Some parameters have constraints (has_birthday: boolean, limit: number with default) but are described without explicit minimum/maximum guidance beyond defaults.
Check if the required permissions are granted to access Contacts and provide troubleshooting information
Get all contacts (limited to 200 by default for performance)
Get contacts by exact or partial name match
Simple test: just return the total number of contacts in the address book
Simple test: get just the names of the first few contacts (no emails/phones)
Search contacts with various filters including name, email, organization, phone, and notes
Test contact processing with a small sample to diagnose performance issues
No output schemas documented for any tool. LLMs cannot plan downstream calls or structure extracted data without knowing field types and names. This violates the pattern:tool requirement that 'Document the output schema.'
No error handling or recovery guidance. Tool descriptions do not indicate what happens on failure (e.g., 'User not found. Try search_contacts() with a partial name'). Agents have no guidance on retry vs. abort.
Parameter descriptions lack depth. E.g., 'Filter by email address' does not explain case sensitivity, partial vs. exact match behavior, or handling of multiple emails per contact. Descriptions should follow the pattern: 'The [field] ([format/constraint], [examples if enum]).'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
No tool annotations present. All tools are READ_ONLY per the metadata, but tool definitions lack readOnlyHint annotations. Per Spec Alignment (current MCP 2026-07-28), tool annotations should be used to declare tool safety properties explicitly.
Three tools (test_contact_processing, get_contact_count, get_contact_names) are labeled as 'test' tools in their descriptions, suggesting they are diagnostic rather than primary interfaces. This naming/positioning is confusing, LLMs may not invoke them when appropriate, or may invoke them unnecessarily. If these are meant to be primary, rename and reposition. If diagnostic-only, remove from the public tool list.
Pagination support is incomplete. get_all_contacts has limit and unlimited params, but no cursor, offset, or page mechanism documented. description mentions '200 by default' but does not explain how to iterate through larger result sets. Baseline pattern:paginated-result expects limit, offset/cursor, and total count in response.
No guidance on parameter relationships or mutual exclusivity. For example, search_contacts has both a generic 'query' param and specific filter params (name, email, organization, phone). The interaction is undefined, does 'query' override filters? Are they combined? Description does not explain.