Loading ToolBench
Self-hosted email API with MCP and REST support for Gmail, Outlook, and IMAP/SMTP
Fluxmail presents a well-structured email MCP server with solid naming conventions and comprehensive parameter schemas. All 15 tools follow verb_noun naming (list_*, get_*, create_*, send_*, modify_*, delete_*, forward_*, download_*). Most tools have detailed JSON Schema input definitions with typed parameters and descriptions. However, there are notable gaps: (1) output schemas are not documented in the provided code, responses are inferred from descriptions; (2) several tools lack actionable error guidance; (3) parameter descriptions sometimes use vague language like 'optional' without explaining consequences; (4) no tool has explicit security annotations (scope declarations, permission gates, or audit directives). The server demonstrates competent API design and would function well in practice, but falls short of A-grade polish due to missing output documentation and incomplete error handling.
Create a draft message
Delete a draft message
Download an attachment by message and attachment ID
Forward an existing message
Full message including body and attachment metadata
Retrieve a complete thread of messages
List all connected email accounts
Output schemas not documented. Tool descriptions state what is returned in natural language, but no structured response schemas are visible in the codebase. LLMs cannot reliably extract fields or plan downstream calls without explicit response type definitions.
modify_emails tool name is ambiguous. The description says 'Modify emails (mark as read, star, archive, apply labels, etc.)' but the tool name does not clarify which operation is performed. Renaming to reflect the action (e.g., mark_email_read, star_email, archive_email) or using an 'action' enum is clearer. The current design requires the LLM to reason about the action parameter to understand tool intent.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | <=2025-11-25 | v2 |
List all folders available in the account
List all user labels or categories
Metadata-level listing of messages without bodies
Discover provider-managed sender identities
Modify emails (mark as read, star, archive, apply labels, etc.)
Send an email message
Test connectivity and authentication for an account
Update an existing draft message
Error handling lacks recovery guidance. No visible error responses specify whether failures are retryable, user-fixable, or fatal. Descriptions do not provide fallback suggestions (e.g., 'If message not found, try list_messages() to verify ID').
No security declarations. Tools that modify or delete state (create_draft, send_email, delete_draft, modify_emails) lack explicit permission scope declarations (e.g., 'Requires: write:email'). No audit logging directives or confirmation patterns visible for destructive operations.
Parameter descriptions sometimes use generic language. E.g., 'Optional when exactly one account is connected' does not clarify what happens if omitted with multiple accounts (error? default to first?). 'Defaults to 25' in pageSize is clear, but most other parameters lack default value documentation.
Missing pagination bounds in list_messages and list_labels. pageSize has no stated min/max constraint. Unbounded numeric parameters can cause agent hallucination (e.g., requesting 1,000,000 messages).
modify_emails 'action' parameter uses a free-form string instead of an enum. The description lists valid actions (mark_read, mark_unread, etc.) but does not enforce them as enum values. LLMs may hallucinate invalid actions.
list_messages includes a 'rawProviderQuery' parameter that accepts provider-native syntax (Gmail/Outlook). This sidesteps the abstraction and locks the agent into a specific provider. Not immediately dangerous, but violates tool composability, agents cannot safely use this parameter without provider knowledge.