MCP tool provider for Android Contacts. Exposes the device's contacts as MCP tools that the LLM System Service can invoke. Reference implementation showing how any app can become an MCP server.
This Android Contacts MCP service has basic tool definitions but significant quality gaps. All 5 tools have names and descriptions, but descriptions are minimal (10-50 chars, well below the 50-200 char LLM-optimized baseline). Input schemas are present but lack depth: parameters have type and description, but no enums, ranges, or validation constraints. Output schemas are not documented. Error handling returns generic JSON error objects without recovery guidance. The service exposes write operations (add_contact, update_contact) without confirmation patterns or permission gates. No tool annotations (readOnlyHint, destructiveHint) despite clear risk differentiation. Tool composition is reasonable (5 focused tools), but parameter naming could be more explicit (e.g., 'contact_name' vs 'name' for disambiguation).
Add a new contact with name, phone, and/or email.
Get full details for a contact by name.
List starred contacts.
Search contacts by name, phone number, or email.
Update an existing contact's phone and/or email.
Descriptions are too short (10-50 chars vs 50-200 char baseline). LLMs cannot determine when to select tools or understand nuanced differences. E.g., 'Search contacts by name, phone number, or email' lacks guidance on when to use search_contacts vs get_contact.
No output schemas documented. LLMs cannot plan downstream calls or extract required fields. searchContacts returns a JSONObject with 'contacts' array and 'count', but this structure is not declared in tool metadata.
Write operations (add_contact, update_contact) lack confirmation or dry-run patterns. Agents can irreversibly modify contacts without user approval. No destructiveHint annotation present.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 32 | <=2025-11-25 | v2 |
Parameter 'name' is ambiguous in get_contact and update_contact. Does it match display name, first name, or full name? Should accept multiple identifier types (name, phone, email) to match chat data model where users say 'Update John's email' not 'Update contact ID 12345'.
Error handling returns generic error() JSON without recovery guidance. E.g., 'Unknown tool' or 'Failed to query contacts' tells LLM nothing about what to do next. Should include actionable suggestions like 'Try search_contacts() with a partial name'.