Apple MCP has 8 tools with complete schemas and descriptions, but significant quality gaps limit production readiness. All tools have input schemas with type definitions and descriptions, meeting baseline requirements. However, descriptions are generic (avg ~80 chars, below 194-char baseline), lack WHEN/WHY guidance, and omit output schema documentation. Parameter descriptions are present but often vague ('optional for X operation'). No tool declares output structure, pagination, or error recovery paths. Naming is reasonable (verb_noun style) but several tools bundle multiple operations (notes, messages, mail, calendar, reminders, maps) into single tools with operation enums, violating single-responsibility principle. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite WRITE operations. Error handling is absent from visible code.

• Split multi-operation tools into single-purpose tools: create_note, search_notes, list_notes instead of notes with operation enum. Same for messages (send_message, read_messages, schedule_message), mail (send_email, search_emails, list_unread_emails), calendar (create_event, search_events, list_events), reminders (create_reminder, search_reminders, list_reminders), maps (search_locations, save_location, get_directions, create_guide).
• Document output schemas for every tool. Add a 'Returns' section to each description specifying field names, types, and example structure. E.g., 'Returns: {contacts: [{id, name, email, phone}], total_count}' so LLMs know what to extract.
• Add tool annotations: mark mail.send_email, messages.send_message, notes.create_note, calendar.create_event, reminders.create_reminder, maps.save_location with destructiveHint=true. Mark read-only tools (contacts, webSearch) with readOnlyHint=true.
• Expand descriptions to 150-250 chars with WHEN/WHY guidance. E.g., 'Search contacts by name in Apple Contacts. Use this to find phone numbers or emails before sending messages. Returns contact ID, name, email, and phone. If name is empty, returns all contacts (may be slow).'
• Add error handling and recovery guidance in descriptions. E.g., 'If contact not found, try a partial name search. If multiple matches, ask user to clarify.' Include validation rules for parameters (e.g., 'phone number must be E.164 format').