Loading ToolBench
MCP server for managing Apple Contacts with tools for listing, searching, creating, updating, and deleting contacts, as well as managing contact groups
Contactbook provides 8 tools with complete JSON schemas and basic descriptions. All tools are properly named with action verbs (contacts_list, contacts_search, contacts_get, contacts_create, contacts_update, contacts_delete, groups_list, groups_members). Schemas include type definitions and required field markers. However, descriptions are minimal (10-80 chars, well below the 194-char baseline for A+ tools), parameter descriptions lack context about constraints and formats, and output schemas are undocumented. Error handling returns JSON strings rather than structured guidance. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Missing pagination support for list operations.
Create a new contact. At least one of firstName, lastName, or organization required. Optional: email, phone, jobTitle, note.
Delete a contact. Required: id (string).
Get a contact by ID with full details. Required: id (string).
List all contacts from Apple Contacts. Optional: limit (int) to cap results.
Search contacts by name, email, phone, or organization. Required: query (string).
Update an existing contact. Required: id (string). Optional: firstName, lastName, organization, jobTitle, note.
List all contact groups.
Descriptions are too brief (10-80 chars vs 194-char baseline). LLMs cannot determine when to select tools or distinguish between similar operations. E.g., 'List all contacts from Apple Contacts. Optional: limit (int) to cap results.' lacks context about when to use this vs search.
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields. E.g., contacts_list returns JSON but structure is undocumented, does it return [Contact] or {contacts: [Contact], total: int}?
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. contacts_delete is DESTRUCTIVE but unmarked; contacts_list is READ_ONLY but unmarked. Agents cannot reason about safety or retry semantics.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
Get members of a specific group. Required: name (string).
Error handling returns raw JSON strings ('Contact not found', 'Invalid params') instead of structured recovery guidance. LLMs cannot determine next steps, should they retry, call search_*, or ask the user?
No pagination support. contacts_list accepts optional 'limit' but no offset/cursor or total count. Large contact databases will be truncated silently, and agents cannot iterate through results.