An MCP server for email management with semantic search capabilities, supporting IMAP/SMTP email operations, configuration management, and vector-based email search
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server has 12 tools with basic JSON Schema definitions and descriptions, but exhibits multiple critical quality gaps. Tool names follow verb_noun conventions appropriately (list_, add_, update_, delete_, send_, read_, search_, get_, semantic_search_, generate_). However, parameter descriptions are sparse or missing entirely, input schemas lack depth (no descriptions for most parameters), and output schemas are completely undocumented. The server stores credentials as parameters (inbound_password, outbound_password in add_email_config and update_email_config), violating secret injection patterns. Error handling is not evident in the code provided. Most tools score 35-50 individually; the average reflects significant structural gaps that would prevent confident production use.
Credentials exposed as tool parameters. add_email_config and update_email_config accept inbound_password and outbound_password directly. Secrets in parameters are logged in agent traces, audit logs, and prompt history, creating compliance and security violations.
Output schemas completely undocumented. No tool in the source code shows what fields or structure responses contain. LLMs cannot plan downstream calls or extract needed data without knowing response structure.
CRITICAL: Move inbound_password and outbound_password out of tool parameters. Implement server-side credential storage (e.g., environment variables, vault, or encrypted config file). Add a 'config_id' or 'config_name' parameter instead. Validate that the calling user has permission to access the stored credential.
CRITICAL: Document output schemas for all 12 tools. Specify the structure of responses (e.g., 'Returns {configs: [{name, inbound_host, inbound_port}, ...], total_count: number}') so LLMs know what fields to expect and can chain tools correctly.
CRITICAL: Add descriptions to every input parameter. For each property in the inputSchema, include a description explaining what it controls, valid values, and constraints. E.g., 'inbound_port' → 'IMAP server port (1 - 65535, typically 993 for IMAPS)'.
HIGH: Add tool annotations. Mark add_email_config, update_email_config with writeOnlyHint:true; delete_email_config with destructiveHint:true; read_email, search_emails, get_* with readOnlyHint:true. This enables agents to reason about side effects.
HIGH: Fix list_email_configs schema. Change 'required': [''] to either [] (command optional) or remove the command parameter entirely if it is unused.
HIGH: Implement pagination. Add 'offset' and 'limit' parameters (or cursor-based pagination) to get_all_emails, search_emails, semantic_search_emails, and get_emails_by_date. Document the default limit and maximum allowed limit in tool descriptions.
HIGH: Add input validation and constraints. For inbound_port and outbound_port, enforce 1 - 65535. For batch_size, set min 1, max 1000. For limit, set reasonable defaults (20 by default, max 500) to prevent context window exhaustion. Add enum constraints for inbound_ssl and outbound_ssl if they only accept 'true'/'false' or specific protocol strings.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Parameter descriptions almost entirely absent. Most input schema properties lack descriptions. E.g., list_email_configs includes a 'command' property with no description of its purpose or valid values. LLMs cannot determine when/how to use parameters without descriptions.
No error handling documented. Code shows handler functions but no visible try/catch, validation, or error recovery guidance in tool definitions. LLMs have no way to diagnose failures or know if they should retry, ask the user, or abort.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. Tool definitions lack metadata about side effects, making it impossible for agents to classify operations or reason about safety and retry behavior.
list_email_configs has required field 'command' that appears to be a schema error. The required array contains an empty string: "required": [""], not ["command"]. This is a schema malformation that prevents proper validation.
No pagination support evident. Tools like get_all_emails, search_emails, and semantic_search_emails accept 'limit' but no offset, page, or cursor parameters. Returning thousands of results risks context window exhaustion.
No validation constraints on numeric or string parameters. Email ports can be any integer (should be 1 - 65535). Batch sizes are unbounded (should have min/max). No regex patterns, length limits, or enum constraints on free-form strings.
Destructive operations lack confirmation or dry-run support. delete_email_config and send_email are irreversible; agents should have a confirm-before-execute pattern to prevent accidental deletion or spam.
Tool descriptions are generic and lack specificity. E.g., 'Read latest 5 unread emails' does not explain when to use this vs search_emails or get_emails_by_date, what structure the response has, or what happens if there are no unread emails.
read_emaillist_email_configsget_email_count
HIGH: Add error handling guidance. Document what happens if a configuration is not found, email delivery fails, or credentials are invalid. Include recovery hints: 'Configuration not found. Try list_email_configs to see available configs.' Update handlers to return structured error responses with actionable next steps.
HIGH: Implement a confirmation mechanism for destructive operations. For delete_email_config, require a separate 'confirm=true' parameter or add a dry-run preview step. For send_email, optionally return a draft preview and require explicit confirmation before sending.
MEDIUM: Enhance tool descriptions with context and comparison. E.g., 'Read latest 5 unread emails from the specified configuration. Use this to check for urgent new mail. For broader search, use search_emails or get_emails_by_date.' This helps LLMs select the right tool.
MEDIUM: Add idempotent hints to tools that support retries without side effects (read_email, search_emails, get_emails_by_date, get_all_emails, get_email_count, semantic_search_emails). This signals to agents that retries are safe.
MEDIUM: Document default values clearly. E.g., 'limit defaults to 10 if not provided; max 100. end_date defaults to today.' This prevents ambiguity and unexpected behavior.
MEDIUM: Add field-naming consistency. If send_email returns a 'message_id', ensure it matches the parameter name expected by other tools. If no tool consumes message_id, explain what the agent should do with it.
LOW: Consider batch variants for common patterns. E.g., add_email_config_batch() to add multiple configurations in one call instead of looping, or update_email_configs() to update multiple at once. This reduces token overhead for agents performing bulk operations.