MailAtlas provides 9 tools with complete input schemas and descriptions. Naming follows verb_noun convention (list_, get_, export_, draft_, send_, receive_). Descriptions are present but brief (avg 60 chars, below 194-char baseline). Parameters are well-typed with descriptions. Critical gaps: no output schemas documented, no error handling guidance, secrets exposed as parameters (SMTP/Gmail credentials), no tool annotations (readOnlyHint/destructiveHint), and composition issues (draft_email and send_email overlap significantly). Pagination implemented correctly (limit/offset). Risk classification present but not integrated into tool metadata.

• Move all credentials (smtp_password, gmail_access_token, cloudflare_api_token, imap_password) out of tool parameters. Load from environment variables or a secure vault server-side. Document which env vars each tool reads (e.g., MAILATLAS_SMTP_PASSWORD, MAILATLAS_GMAIL_TOKEN).
• Document output schemas for all tools. For list tools, specify the structure of each item in the returned array and include total_count or has_more for pagination. For send_email, document the returned message ID, timestamp, and delivery status fields.
• Add tool annotations to the MCP tool registration: readOnlyHint=true for list/get/export/receive_status; destructiveHint=true for send_email; idempotentHint=true for draft_email (if idempotency_key is provided). This enables LLM clients to warn users before irreversible actions.
• Clarify draft_email → send_email composition. Either (a) have draft_email return a draft_id that send_email accepts, or (b) document that send_email is self-contained and draft_email is optional for auditing. Currently agents must duplicate email data.
• Add error handling guidance to tool descriptions. E.g., 'mailatlas_send_email: Returns error if provider credentials are invalid (user-fixable: check env vars) or if recipient list is empty (user-fixable: add recipients). Retryable on network timeout.' This guides agent recovery.