Server has 6 tools with basic naming (verb_noun pattern) and descriptions present. However, critical gaps undermine quality: (1) Parameter descriptions are minimal or missing detail on format/constraints. E.g., 'emails' param in create_contact has no guidance on object structure (should it be {type, value}?). (2) Array item schemas lack specificity, 'items: {type: object}' provides no field definitions, forcing LLMs to guess structure. (3) No output schemas documented anywhere, LLMs cannot predict response fields or plan chaining. (4) Error handling absent, no guidance on retryability, user-fixable vs fatal errors, or recovery paths. (5) Descriptions are functional but generic (avg ~60 chars), lacking WHEN/WHY context. Tool names are clear (list_*, get_*, create_*, update_*, delete_*) but descriptions do not explain prerequisites or dependencies.

• Define item schemas for array parameters. E.g., 'emails': {type: 'array', items: {type: 'object', properties: {type: {type: 'string', enum: ['work', 'home', 'other']}, value: {type: 'string', format: 'email'}}, required: ['value']}}
• Document output schemas for all tools. Specify fields returned by list_address_books (e.g., name, href, color), list_contacts (contact_id, full_name, emails), and get_contact (full vCard structure).
• Expand parameter descriptions with format/constraint details. E.g., 'address_book: The CardDAV href (URL path) of the address book, e.g. /carddav/addressbooks/user/contacts/'
• Add error handling guidance. E.g., 'If contact_href is invalid, returns 404, verify href from list_contacts. If auth fails, check CARDDAV_USERNAME/PASSWORD env vars.'
• Add confirmation step for delete_contact. E.g., 'This operation is irreversible. Recommend calling get_contact first to confirm the contact, then delete_contact to remove it.'