Server has 6 tools with explicit schemas and descriptions, but quality is inconsistent. Tool names follow verb_noun convention (create_mailbox, list_messages, send_mail, renew_mailbox, pay_order, order_status). Descriptions are present but brief (avg ~60 chars, below the 194-char baseline). Parameters have type definitions and descriptions, but lack constraints (enums, ranges, patterns). No output schemas documented. Error handling is minimal, tools return raw API responses without recovery guidance. Security concern: credentials passed as optional parameters (address, key) rather than server-side injection. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE, IRREVERSIBLE operations).

• Move address and key to server-side environment variables (KANKAN_ADDRESS, KANKAN_MAIL_KEY) only. Remove them as optional parameters. If per-mailbox operations are needed, accept a mailbox_alias or mailbox_id instead, resolved server-side.
• Add tool annotations: mark send_mail and create_mailbox with destructiveHint=true; mark pay_order with destructiveHint=true and idempotentHint=false; mark list_messages and order_status with readOnlyHint=true.
• Document output schemas for each tool. E.g., create_mailbox returns {address: string, mail_key: string, expires_at: string}. list_messages returns {messages: [{id, from, subject, body, received_at}], total: number, next_cursor?: string}.
• Expand descriptions to 100-200 chars. E.g., 'List all messages received by a mailbox. Supports incremental polling via after_id. Returns up to 50 messages per call; use pagination for large inboxes.'
• Add error recovery hints. E.g., 'If mailbox not found, call create_mailbox first.' For pay_order failures, explain whether the error is retryable (network) or user-fixable (invalid payment method).