Loading ToolBench
An MCP server that provides email sending capabilities via SMTP
Single tool 'send_email' with critical deficiencies. Tool name is appropriate (verb-first: send_email), but descriptions lack depth, input schema lacks critical detail and validation, no output schema is documented, and security issues are severe. Parameters have types but descriptions are minimal (6-19 chars each, well below the 72-char baseline). No error handling, no recovery guidance, and credentials are hardcoded in the implementation rather than properly injected. This is a near-minimal implementation that would not pass code review for production use.
Sends an email via SMTP with the specified recipient, subject, and body content
Tool description is too brief (60 chars) and lacks context. Does not explain what happens on failure, when to use this tool vs alternatives, or prerequisites (SMTP config must be valid).
Parameter descriptions are critically sparse. 'to' (17 chars), 'subject' (19 chars), 'body' (13 chars), all far below 72-char baseline and well below the 20-char minimum that triggers a hard cap. LLM cannot infer format constraints (e.g. valid email format, subject length limits, body character limits). Param annotations must explain expected format and constraints.
No output schema documented. Tool returns a bare string 'Email sent successfully.', LLMs cannot determine response structure or extract chaining IDs. Per pattern, tools must document return types and structured output. Without a schema, LLM cannot plan downstream actions or validate success.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 37 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 24 | - | v1 |
SMTP credentials (MAIL_ACCOUNT, MAIL_PASSWORD) are loaded from environment variables in the implementation, but the tool parameters expose no way to specify alternative SMTP servers or accounts. The hardcoded 'smtp.gmail.com' and port 587 break multi-tenant scenarios. Credentials are not parameters (good), but the implementation is inflexible.
No error handling or recovery guidance. If SMTP auth fails, network times out, or recipient email is invalid, the exception propagates as a raw traceback. Per pattern, errors must guide the LLM: e.g. 'SMTP auth failed, verify MAIL_PASSWORD is correct' or 'Invalid email address, expected format [email protected]'. Actionable errors enable self-correction.
No input validation. Tool does not check if 'to' is a valid email address, if 'subject' is non-empty, or if 'body' has reasonable length. LLMs frequently pass invalid values; validation early with clear error messages prevents wasted SMTP calls.
No idempotency declaration or handling. Retrying send_email(to='[email protected]', subject='test', body='hello') will send the email twice. Per pattern, irreversible operations must support dry-run or idempotency key. Tool should accept an optional 'idempotency_key' parameter and track sent emails to prevent duplicates.
No permission gate or audit trail. Tool does not log who called it, with what parameters (sanitized), when, or what the outcome was. An agent with send_email access can spam any email address. Per pattern, sensitive operations must be traceable and permission-gated.
Tool has no timeout. If SMTP server hangs, smtplib.SMTP() blocks indefinitely, freezing the entire MCP server. Per best practice, external service calls must have explicit timeouts (e.g. timeout=5 seconds) and return a timeout error with retry guidance.