Two tools with basic descriptions and schemas, but significant gaps in parameter documentation, error handling, and security. SendEmail and SendHtmlEmail have descriptions (10-word baseline met) and input schemas with types, but parameter descriptions are minimal (1-3 words each). No output schema documented. Error handling returns generic strings without recovery guidance. No input validation, no enum constraints, no idempotency markers. Credentials (SMTP_USERNAME, SMTP_PASSWORD) are injected server-side (good), but the tools lack permission gates, audit logging, and actionable error messages. Parameter descriptions do not explain format, constraints, or when to use each tool variant.

• Expand parameter descriptions to 50-100 chars each. Example: 'to: Recipient email address (RFC 5322 format, e.g. [email protected]). Required.' Include format, constraints, and examples as formal constraints (enums, regex patterns in schema), not prose.
• Document output schema explicitly. Return structured JSON: {success: boolean, message_id?: string, error?: string, retry_after?: number}. This enables LLM to parse results and chain to downstream tools.
• Implement categorized error handling. Distinguish: (1) validation errors (invalid email format) → user-fixable, (2) SMTP connection errors → retryable with backoff, (3) authentication errors → fatal, requires credential check. Return {success: false, error_code: 'invalid_email', error_message: '...', retry: boolean}.
• Add input validation before SMTP operations. Validate email format (regex or library), subject length (1-998 chars per RFC 5322), body encoding. Return clear error: 'Invalid recipient email: got "user@", must be valid RFC 5322 address.'
• Add tool annotations in schema: destructiveHint=true, idempotentHint=false (sending email twice creates duplicates). This signals to LLM that retries are unsafe and confirmations may be needed.

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

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