Loading ToolBench
This MCP server exhibits significant definition quality gaps typical of early-stage integrations. While core email functionality is present, the implementation suffers from inconsistent naming conventions, duplicate tool definitions across frameworks, minimal descriptions, and missing schema documentation. The presence of 7 tools across three different framework integrations (LangChain, LlamaIndex, CrewAI) with overlapping functionality creates redundancy rather than clear composition. Most tool descriptions are generic and under 100 characters, failing to guide LLM selection or document when/why to use each tool. Input schemas are present but lack proper type annotations for some fields and miss critical constraint documentation (enums, patterns, ranges). Error handling guidance is absent. The 'ping' tool is a removed pattern from the deprecated MCP spec.
Check if an email address is suppressed (bounced, unsubscribed, or blocked). Use before sending to verify deliverability. Arguments: - email: Email address to check (required)
Send an email via ADSMedia API. Useful for sending notifications, confirmations, alerts, and other transactional emails. Arguments: - to: Recipient email address (required) - subject: Email subject line (required) - html: HTML content of the email (required) - to_name: Recipient name (optional) - from_name: Sender display name (optional)
Check if an email address is suppressed (bounced, unsubscribed, or blocked). Use this before sending to verify the email is deliverable.
Send an email via ADSMedia API. Use this to send transactional emails like notifications, confirmations, alerts. Input should include: to (email), subject, html content. Optional: to_name, from_name.
Check if an email address is suppressed before sending. Use to verify deliverability.
Test ADSMedia API connection.
Tool naming inconsistency and framework-specific prefixes break verb-noun convention. Tools #3 and #4 use 'adsmedia_' prefix (namespace pollution); tools #1, #2, #5, #6 use clean names. This forces LLMs to reason about naming patterns rather than inferring intent.
Duplicate tool definitions across three framework integrations (CrewAI #1/#2, LangChain #3/#4, LlamaIndex #5/#6). Same functionality exposed 6 times with inconsistent naming. Creates confusion and increases maintenance burden. Should consolidate to single MCP tool and let frameworks wrap it.
'ping' tool is a REMOVED pattern from MCP spec (spec revision 2026-07-28). Should not exist in new implementations. Adds no value, connection testing should be implicit or handled via capabilities negotiation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Send an email via ADSMedia API. Use for transactional emails like notifications, confirmations, alerts.
All descriptions are under 100 characters and lack LLM-optimized guidance. Missing: WHEN to call (vs similar tools), WHAT happens on error, WHAT structure is returned. Example: 'Send Email' description is 90 chars, says WHAT but not WHY or error cases. Rubric baseline: 194 chars average for A+ tools.
Input schemas lack critical constraints. No enum for suppression states (bounced|unsubscribed|blocked|complaining). No email format pattern validation. No minLength/maxLength for HTML content. No 'required' vs 'optional' explicitly marked in schema properties (only in description text). Email parameter needs regex or format:'email' constraint.
No output schema documentation for any tool. Agents don't know what fields to expect. Does 'check_suppression' return boolean? String state? Object with details? Does 'send_email' return message_id, timestamp, or status? This forces LLMs to guess and breaks downstream tool chaining.
No error handling guidance. What happens if email is suppressed? If HTML is invalid? If API rate limit is hit? Tools must return actionable recovery messages, not bare error codes. Example: 'Email suppressed: address bounced. Try removing from mailing list or request reinstatement.'
No idempotency or destructive operation documentation. 'send_email' is a WRITE tool with side effects, description must explicitly state it will create a sent email record. Agents need to know they cannot safely retry without risk of duplicate sends. Missing idempotentHint annotation.
Parameter descriptions are minimal and lack actionable constraints. 'to' is described as 'Recipient email address' but doesn't specify: must be valid RFC 5322 format, single email only (no comma-separated list), no length limits stated. 'html' parameter lacks note on max size, character encoding, or whether styles/scripts are stripped.
No clear indication of optional vs required parameters in schema definitions. Descriptions say '(required)' or '(optional)' in text, but JSON Schema should use 'required' array explicitly. Makes it harder for tools to validate and for agents to understand what's mandatoryat a glance.