Loading ToolBench
Email delivery client skill for Nitrosend agent - provides email planning and delivery capabilities
This server has a single tool with a valid schema and basic description, but exhibits multiple critical quality gaps. The tool name 'plan_delivery' is vague and does not follow verb_noun clarity patterns, 'send_email' or 'schedule_email_delivery' would be clearer. The tool description (48 chars) is underdeveloped and lacks key information: it does not explain that this tool SENDS email (state-modifying), when to use it, what the LLM should expect in return, or dependencies. Parameter descriptions are minimal (7-12 chars each) and fail to clarify expected formats, constraints, or examples. The implementation itself is problematic: it does not actually send email, it only constructs a payload dictionary with no real delivery mechanism, making the tool non-functional for agents expecting actual email transmission. Error handling is absent; there is no validation of email addresses, subject length, or body format, and no actionable error messages if delivery fails. The server provides no pagination, filtering, or result documentation. The tool also lacks idempotency guarantees, repeated calls with identical inputs will generate different message_ids due to timestamp inclusion, violating agent retry safety. There is no security declaration (permissions, scope), no audit trail, and no indication of where credentials (SMTP, API keys) are injected. Based on the rubric, this is a category D (poor) implementation.
Plan email delivery with subject, body markdown, and recipient
Tool name 'plan_delivery' is vague and does not follow verb_noun pattern. Does not clarify that email is SENT (state-modifying) or distinguish from related actions like draft_email, schedule_email, or cancel_email. LLM cannot infer intent from name alone.
Tool description (48 chars) is far below rubric minimum of 10-1024 chars effective range and lacks critical context. Does not state: (1) what the tool actually does (sends email or just plans it?), (2) when to call it vs similar tools, (3) what fields are returned, (4) whether this has side effects (state-modifying). LLM cannot determine if this tool is safe to retry.
Parameter descriptions are trivial (7-12 chars each) and provide no constraint, format, or validation guidance. 'Email recipient address' says WHAT but not FORMAT (RFC 5322 compliance?). 'Email body in markdown format' does not state max length, character restrictions, or what happens if not markdown. LLM will pass invalid input without guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 26 | 2026-07-28+ | v2 |
No input validation in implementation. The tool accepts any string for recipient, subject, and body without validating email format, subject length, or body encoding. LLM can pass malformed email addresses or absurd subject lines (e.g. 10MB of text) with no early error feedback.
Tool is non-idempotent. Each call generates a new message_id using int(time.time()), so identical input parameters produce different outputs. Agents retry on failure, this tool will generate duplicate messages with different IDs if retried, violating idempotent-operation pattern.
Implementation does not actually send email. Returns {'delivered_payload': {...}} without any SMTP, HTTP API call, or queue submission. The tool name and description imply delivery, but only constructs a dict. Either the tool name is misleading (should be 'create_email_draft' or 'format_email_payload'), or the implementation is incomplete. Agents will fail when expecting actual email transmission.
No error handling or recovery guidance. If recipient is invalid, body is empty, or subject is missing, the tool silently constructs a payload anyway. No error code, no actionable message like 'Invalid email: recipient must match RFC 5322 format'. LLM cannot self-correct.
Output schema is not documented. The tool returns {'delivered_payload': {...}} but the tool definition does not state this structure in the schema. LLM does not know what fields are in the response or how to chain this output to downstream tools.
No security declarations or credential injection. No indication of where SMTP credentials, API keys, or auth tokens come from. The implementation appears to use no credentials at all, suggesting incomplete integration with an actual email service. Credentials must never appear as tool parameters, use environment variables or vault.
No audit trail or logging. Tool provides no indication of who invoked it, when, with which parameters, or what the result was. Required for compliance, debugging, and incident response per pattern:audit-trail.