Loading ToolBench
Local .eml email conversion to Markdown over stdio MCP
The server has four well-named tools with comprehensive input schemas and detailed descriptions. Naming follows verb_noun conventions (convert_eml, convert_eml_to_bundle, convert_directory, get_diagnostics). All tools have descriptions between 100-300 chars, meeting the 10-1024 baseline. Every input parameter has a type and description. However, output schemas are not documented, the code returns structured results (JSON with bundle_path, markdown_path, attachment_paths, diagnostics) but the tool definitions do not declare output schema. Error handling is present in the code (_raise_on_failure) but not explicitly documented in tool descriptions. Tool descriptions mention return types in prose but lack formal output documentation.
Batch convert all .eml files in a directory to Markdown. Recursively finds all .eml files and converts them. Returns a JSON summary with total, successes, failures, output_paths, and errors. Use convert_eml to retrieve individual converted file content.
Convert a .eml email file to Markdown with YAML front matter. Returns the full Markdown content (front matter + body). When output_path is provided, also writes the file to disk. Presets bundle common flag combinations: - default: strips signatures, tracking pixels, signature images - clean: default + strips disclaimers and quoted headers - verbose: includes all headers and raw HTML - raw: no stripping, preserves everything Individual flags override the preset when provided.
Convert a .eml file to a self-contained bundle with markdown and attachments. Creates a directory containing the converted markdown, extracted attachments, and optionally the original .eml source. source_handling only accepts 'copy' over MCP: the original .eml is copied into the bundle and left untouched. The 'move' and 'delete' modes are rejected here — use the CLI or the Python API for those. Returns JSON with bundle_path, markdown_path, attachment_paths, and optional diagnostics.
Inspect email quality and structure without writing permanent files. Use this to assess conversion quality before committing, or to troubleshoot problematic .eml files. Returns a JSON structure describing the email's state: threading, MIME structure, HTML repairs, stripped content, and quality grade.
Output schemas not formally documented. Tool definitions describe return types in prose ('Returns JSON with...', 'Returns a JSON structure...') but MCP tool definitions should include explicit output schema declarations. LLMs cannot reliably parse prose output formats.
Error handling not exposed to LLM. The code includes _raise_on_failure() and ToolError raising, but tool descriptions do not explain what errors can occur, when they are retryable, or what the LLM should do next. Descriptions say 'when output_path is provided' but do not document failure modes or recovery steps.
Preset parameter lacks detailed description of what each preset does. The description says 'Preset bundle of conversion options' but does not explain the semantic difference between 'default' (strips signatures, tracking pixels, images), 'clean' (adds disclaimers and quoted headers), 'verbose' (includes all headers and raw HTML), and 'raw' (no stripping). This forces the LLM to infer behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
convert_eml_to_bundle includes source_handling enum with three options (copy, move, delete) but the description restricts MCP to 'copy' only. The description explicitly says 'MCP only supports 'copy'', which means two of the three enum values are invalid for MCP clients. This is confusing, either remove invalid enum values or explain when each applies.
Thread mode and thread order parameters lack clear descriptions of their effects. 'Thread mode for handling email conversations' is vague, does it control how replies are grouped? How text is formatted? The enum values ('latest', 'structured') are not self-documenting. Similarly, thread_order ('oldest-first' vs 'latest-first') is unexplained.
convert_directory does not document the file limit or warning about batch operations. The code defines MCP_MAX_DIRECTORY_FILES = 50, but the tool description does not state this limit. Agents calling this tool on large directories may be surprised by silently truncated results.