Loading ToolBench
MCP server for Commune – email infrastructure for agents. Set up an inbox and send your first email in 30 seconds. Programmatic inboxes, consistent threads, custom domains, attachments, and structured data.
The server defines 8 tools with consistent verb-noun naming and comprehensive descriptions. All tools have documented input schemas with types and descriptions. However, output schemas are not explicitly documented in the code, and error handling lacks recovery guidance. Tool descriptions are well-written (120-280 chars on average) and include context about prerequisites and dependencies. The schema quality is strong with proper type definitions and parameter constraints. This is a solid B-grade implementation with good foundational quality but missing output documentation and error recovery patterns.
Create a new custom email domain. After creating a domain, you need to: 1. Call get_domain_records to see the required DNS records 2. Add those records at your domain registrar 3. Call verify_domain to check verification status
Create a new inbox for receiving emails. The inbox email address will be {local_part}@{domain}. If no domain_id is provided, Commune auto-assigns your inbox to an available domain — no DNS setup required.
Delete an inbox.
Get the DNS records required to verify a domain. Returns MX, TXT, and CNAME records that must be added at your domain registrar before calling verify_domain.
List all email domains in your Commune account. Returns each domain's ID, name, and verification status. Use the domain ID with other tools like list_inboxes or create_inbox.
Output schemas not documented in code. Tools return formatted JSON via _fmt() but the structure of returned objects is not explicitly specified for LLMs to plan downstream calls.
delete_inbox has minimal description (12 chars: 'Delete an inbox.'). Does not explain consequences, whether it is recoverable, or what happens to associated threads/messages. Violates the principle that destructive operations must state side effects.
No error handling patterns visible in code. HTTP errors are raised via resp.raise_for_status() with no recovery guidance. Errors should guide the LLM toward resolution (e.g., 'Domain not found. Call list_domains() to see available domains.').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 85 | 2026-07-28+ | v2 |
List inboxes. Without domain_id, lists all inboxes across all domains. With domain_id, lists inboxes for that specific domain. Each inbox has a local_part (the part before @) that forms the email address: {local_part}@{domain_name}
Set structured extraction schema for an inbox.
Trigger DNS verification for a domain. Call this after adding the required DNS records at your registrar. Use get_domain_records first to see which records are needed.
No pagination parameters visible for list_domains and list_inboxes. If these return large result sets, they could exhaust context windows. Should support limit and offset/cursor parameters.
create_domain accepts optional 'region' parameter but description does not explain consequences of region selection or what happens if omitted. Should document default region behavior.
set_extraction_schema accepts 'schema' as a JSON string rather than a structured object. This requires the LLM to construct valid JSON Schema text, error-prone for complex schemas. Consider accepting structured input.
No confirmation or dry-run mechanism for delete_inbox. Destructive operations should support a confirmation step to prevent accidental data loss by agents.