Loading ToolBench
An MCP server for managing email operations including local draft creation, sending, querying QQ mailbox, and time-based email retrieval
This MCP server has significant gaps across naming clarity, parameter descriptions, and output schema documentation. While tool names follow action-verb conventions (create_, delete_, get_, list_, send_, update_, query_), descriptions are written in Chinese and many are under 20 characters when translated. Parameter descriptions exist but are minimal. No output schemas are documented, critical for agent reasoning about downstream tool chains. The server exposes database operations directly without proper composition guidance. Averaging 10 tools with highly variable quality; most fall into the D-F range.
创建邮件草稿,并且存储到mysql5的数据库中
根据 ID 删除本地草稿邮件
获取当前时间
根据ID获取本地草稿邮件的详细内容
查询本地草稿邮件记录列表（支持状态筛选和模糊搜索）
根据标题模糊查询QQ邮箱中的邮件
根据时间范围查询 QQ 邮箱中的邮件记录，可以查询近期的邮件信息
Descriptions are in Chinese and many translate to under 20 characters when converted to English, violating the 10 - 1024 character guideline. Examples: 'get_local_draft_email_detail' → '根据ID获取本地草稿邮件的详细内容' (~40 chars in Chinese but lacks WHAT, WHEN, and prerequisite context).
No output schemas documented for any tool. create_email, send_email, update_email, and delete_email return TextContent with plain strings (e.g., 'yes 邮件发送成功'), but the agent cannot infer what fields are available for downstream chaining. This blocks tool composition.
Parameter descriptions are minimal and do not include constraints, formats, or examples. E.g., 'attachments' is described as '附件列表' (attachment list) with no guidance on file path format, size limits, or supported types. 'status' in list_email lacks enum values. 'keyword' and 'uid' have no length/format constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
根据 UID 查询 QQ 邮箱邮件内容
将本地草稿中编辑好(存在的邮件)到指定的邮箱
根据指定的id来更新邮件草稿内容
Tool naming ambiguity: get_local_draft_email_detail vs get_local_draft_email_details (inconsistent singular/plural). Also, 'query_qq_email_*' and 'list_email' both search emails but use different verbs (query vs list), forcing LLMs to reason about which to use. Canonicalize to list_qq_emails or query_emails.
Error handling is minimal and returns unstructured text (e.g., '未找到草稿或状态不正确'). No recovery guidance, no actionable messages for LLMs. When send_email fails, the LLM receives 'Email send failed: [error]' with no guidance on whether to retry, ask the user, or call a different tool.
No permission gates or security audit trails. Tools directly modify a MySQL database (create, update, delete emails) without user authorization checks or logging. An agent could delete all emails without resistance.
Destructive operations (delete_email, update_email, send_email) lack confirmation or dry-run support. No pattern guidance like 'Call confirm_delete_email() first' or 'This operation is irreversible.' Agents can silently delete data.
SMTP credentials (EMAIL_USER, EMAIL_PASSWORD) are loaded from environment variables via get_config(), which is correct. However, no parameter masking or secret filtering is visible in the logging or response paths. If an error occurs in send_email, the password might leak into error messages.
Tool composition is broken. create_email returns a plain text message with no email_id. Subsequent calls to send_email, update_email, or delete_email require an 'id' parameter, but create_email does not return one. Agents cannot chain these tools without an extra lookup via list_email.
Pagination is not implemented for list_email or any query tools. If a user has hundreds of emails, the tools return all results, risking context window exhaustion. No limit, offset, or cursor parameters.