Loading ToolBench
An MCP server for email management supporting Gmail and Outlook, enabling sending, drafting, reading, searching, replying to, deleting, archiving, and labeling emails with attachment support.
MailNet MCP Server has 12 tools with generally good naming and descriptions, but significant gaps in schema documentation and parameter descriptions. All tools start with action verbs (send_, draft_, reply_, delete_, archive_, toggle_, download_, load_, update_, search_, read_). Descriptions are present and reasonably detailed (averaging ~150 chars), meeting the 10-1024 character guideline. However, critical issues emerge: (1) Parameter descriptions vary widely in completeness, many lack explicit format/constraint guidance; (2) Output schemas are completely undocumented, no tool shows what fields will be returned; (3) Error handling is not visible in the code excerpt; (4) Some parameters lack type specificity (e.g., 'provider' string enum is clear, but label_name and prompt_prefix lack constraints). The HTTP transport with FastAPI/uvicorn is current. Tool composition is reasonable, separate tools for send/draft/reply rather than combined operations. Input validation exists (MAX_EMAIL_BODY_SIZE, MAX_SUBJECT_LENGTH, MAX_RESULTS_LIMIT) but is not documented in parameter descriptions where LLMs can see it.
Archives the specified message (e.g., removes it from the inbox).
Deletes the specified message.
Downloads an attachment from a specific email message.
Save an email as draft. If the user attached files, their file IDs appear as attachment values in the conversation (type=url). Pass those IDs as attachment_ids to include the files in the draft.
Loads email settings from local configuration file. Must be called before using other email tools in local mode.
Reads recent emails received within the past `days_back` days. Used to retrieve inbox context for summarization, triage, or reply.
Missing output schemas for all tools. No documentation of what fields are returned, their types, or their structure. Forces LLMs to discover output structure through trial-and-error or parse unstructured responses. Violates pattern:tool and mxe:strip-api-responses guidelines.
Parameter constraints not documented in descriptions where LLMs read them. MAX_EMAIL_BODY_SIZE, MAX_SUBJECT_LENGTH, MAX_RESULTS_LIMIT are enforced in code but LLMs never see these limits, they may propose values that fail validation. Pattern recommends documenting constraints (length, range, enum) directly in parameter descriptions for LLM visibility.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Reply to an email. If the user attached files, their file IDs appear as attachment values in the conversation (type=url). Pass those IDs as attachment_ids to include the files in the reply.
Searches for emails matching the given filters. Used to locate specific messages or threads. Returns a list unless `msg_id` is provided.
Sends a previously created draft email.
Send an email. If the user attached files, their file IDs appear as attachment values in the conversation (type=url). Pass those IDs as attachment_ids to include the files in the email.
Adds or removes a label/category from the specified message. Used to organize or tag messages
Updates email settings like tone, language, signature, and other preferences.
Parameter 'label_name' (toggle_label_email) and 'prompt_prefix' (update_email_settings) lack type constraints and format guidance. 'label_name' should specify valid label values or link to a discovery tool. 'prompt_prefix' lacks length/content guidelines. This forces LLMs to guess valid values.
No error handling guidance visible in docstrings. Tools like delete_email, send_email, and draft_email modify state but provide no actionable error messages or recovery guidance. Pattern requires categorizing errors as retryable, user-fixable, or fatal, and guiding the LLM to next steps.
Destructive operations (delete_email) lack confirmation or dry-run support. Agents can irreversibly delete emails without a confirmation step. Pattern recommends a confirm_before_execute pattern for destructive ops.
Parameter 'attachment_ids' in send_email, draft_email, reply_to_email, described as 'file IDs', but unclear what IDs these are or how agents discover them. send_email description references 'attachment values in the conversation (type=url)' which is domain-specific jargon. Needs dependency hint: 'If you only have file names, use download_attachment first.'
Parameter 'provider' (read_emails, search_emails) is marked nullable and optional with default behavior, but no indication of what the default is or how an agent chooses between 'google' and 'outlook'. Undocumented dependency on server-side settings.
No documentation of tool composition or recommended call sequences. E.g., agents may not know whether to call read_emails then search_emails, or which is more efficient for a given use case. Pattern recommends discovery tool guidance: 'Call list_* first to see available options before querying.'