Loading ToolBench
MCP server for the Resend email service API, enabling email sending, domain management, contact handling, templates, broadcasts, automations, and more.
Resend MCP demonstrates solid tool design with clear naming conventions (verb_noun pattern), comprehensive parameter schemas with enums and descriptions, and explicit risk classifications. All 8 tools have descriptions and input schemas. However, output schemas are not documented in the source, parameter descriptions vary in depth, and error handling guidance is minimal. Tool names are action-oriented (create-, list-, get-, update-, remove-) and follow MCP conventions. The server includes helpful user-facing guidance in descriptions (e.g., 'You MUST display DNS records', 'double-check with the user'), which aids agent decision-making. Pagination support is present in list tools. Main gaps: no visible output schema documentation, limited error recovery guidance, and some parameter descriptions lack format/constraint details.
Create a new API key in Resend. The token is only shown once upon creation, so you MUST display it to the user.
Create a new domain in Resend. Returns DNS records that must be configured with your DNS provider for verification. You MUST display the DNS records to the user so they can set them up.
Get a domain by ID from Resend. Returns full domain details including DNS records needed for verification.
List all API keys from Resend. Returns API key names, IDs, and creation dates. Don't bother telling the user the IDs or creation dates unless they ask for them.
List all domains from Resend. Returns domain names, statuses, regions, and capabilities. Don't bother telling the user the IDs unless they ask for them.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Returns domain names, statuses, regions, and capabilities') but formal output schema definitions are not visible in source code. LLMs cannot reliably extract fields or plan downstream tool calls without documented return types.
Error handling lacks recovery guidance. Tool descriptions do not explain what errors are possible, how to classify them (retryable vs. user-fixable), or what the LLM should do next. E.g., create-domain does not document what happens if the domain already exists or DNS validation fails.
Parameter descriptions lack format/constraint details. E.g., 'customReturnPath' and 'trackingSubdomain' lack examples or format specs (e.g., 'must be lowercase alphanumeric, 1-63 chars'). 'region' enum is documented but no guidance on which to choose or what 'default' means operationally.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Remove an API key by ID from Resend. Before using this tool, you MUST double-check with the user that they want to remove this API key. Reference the NAME of the API key when double-checking, and warn the user that removing an API key is irreversible and any services using it will lose access. You may only use this tool if the user explicitly confirms they want to remove the API key after you double-check.
Rename an existing API key in Resend.
Update an existing domain in Resend. Allows changing tracking settings, TLS mode, and capabilities.
Confirmation pattern for destructive operations is documented in description text only. remove-api-key description states 'You MUST double-check with the user' but this is a guideline, not enforced by the tool. No formal confirmation mechanism (e.g., dry-run, confirmation_token) is visible.
Pagination cursors not documented. list-domains and list-api-keys accept 'after' and 'before' parameters but descriptions do not explain cursor semantics (opaque vs. ID-based, whether cursors expire, or how to handle missing cursors).