mcp-email has 8 tools with complete input schemas and descriptions present in internal/tools/registry.go. Naming follows verb_noun convention consistently (list_*, fetch_*, send_*, search_*, get_*, save_*, sync_*). Descriptions are adequate (ranging 40-150 chars) but lack depth about when to use each tool or LLM-optimized guidance. Parameters have types and descriptions, meeting basic requirements. However, parameter descriptions are brief and lack format/range guidance. Output schemas are not documented, LLMs cannot understand what fields to expect from tool responses. Error handling is not visible in the code provided. No tool annotations (readOnlyHint/destructiveHint) despite clear semantic differences between read and write operations. No output schema documentation. Search tool has good parameter coverage but descriptions could guide LLM selection better. Most tools default account to 'optional, uses default' which is reasonable, but sync_emails lacks clarity on what 'all folders' means.

• Document output schemas for all 8 tools. For each tool, define the response structure with field names, types, and descriptions. E.g., list_accounts should return {accounts: [{name: string, email: string, default: bool}]}. This is critical for LLM reasoning and downstream tool chaining.
• Add tool annotations to the MCP protocol response. Modify server.go tools/list handler to include readOnlyHint=true for read-only tools (list_*, fetch_*, get_*, search_*) and include destructiveHint=true for write tools (send_email, save_draft, sync_emails). Example: {name: 'send_email', description: '...', inputSchema: {...}, readOnlyHint: false, destructiveHint: true}.
• Expand parameter descriptions with format and validation rules. E.g., 'from' and 'to' in fetch_emails: 'IMAP sequence numbers (positive integers, e.g. 1, 50). Start of range must be <= end.' For date_from/date_to in search_emails: 'ISO 8601 format: YYYY-MM-DDTHH:mm:ssZ or date only YYYY-MM-DD.'
• Add error recovery guidance. In the tool description, state common failure modes and next steps. E.g., send_email: 'If account not found, call list_accounts to discover valid names. If SMTP fails, check credentials and retry.'
• Clarify tool selection logic in descriptions. For fetch_emails vs search_emails: 'fetch_emails retrieves emails from a folder by sequence range (use when you want a recent batch). search_emails uses indexed queries (use when looking for specific senders, subjects, or date ranges).' For get_email vs fetch_emails: 'get_email retrieves details of a cached email by ID (fast, requires prior fetch or search). fetch_emails fetches new emails from the IMAP server.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry