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.
Commune MCP demonstrates solid tool definitions with consistent naming patterns (verb-first), comprehensive descriptions, and well-structured JSON schemas. All 8 tools follow the verb_noun pattern (list_, create_, verify_, get_, delete_, set_). Descriptions are substantive (averaging ~150-250 chars) and include prerequisites and workflow context. Input schemas are properly typed with descriptions for all parameters. However, output schemas are not documented, tools return formatted JSON via _fmt() but the agent has no schema definition for what fields to expect. Error handling is minimal; no guidance provided for recovery scenarios. Some parameter descriptions could be more prescriptive about constraints. Tool descriptions reference IDs from other tools but don't always clarify dependency chains. Overall, this is a well-intentioned, production-adjacent server that would benefit from explicit output schema documentation and richer error messaging.
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 Args: name: Domain name, e.g. "example.com" region: AWS region (optional), e.g. "us-east-1" or "eu-west-1"
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. Args: local_part: Part before @ (e.g. "support", "billing", "hello") domain_id: Domain to create under (optional, auto-resolved if omitted) name: Agent name for the inbox (optional, also used as display_name fallback) display_name: Sender display name shown in email clients (e.g. "Support Agent", "Acme Sales"). If set, outbound emails show as '"Display Name" <email>' in Gmail/Outlook. webhook_endpoint: URL to receive notifications on new emails (optional)
Delete an inbox. Args: domain_id: The domain ID inbox_id: The inbox ID to delete
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. Args: domain_id: The domain ID (from list_domains)
Output schemas not documented. Tools return formatted JSON but agents cannot see structure. No way to know if response includes domain_id, status, verification_date, or other fields. Agents must infer structure from responses, risking parsing errors and poor downstream tool chaining.
Error handling is minimal and provides no recovery guidance. When API calls fail (e.g., invalid domain_id, DNS verification timeout, quota exceeded), agents receive raw HTTP errors with no actionable next steps. No distinction between retryable errors (temporary service issues) vs. user-fixable errors (invalid input) vs. fatal errors (permission denied).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 74 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
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.
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} Args: domain_id: Filter by domain (optional, lists all if omitted)
Set structured extraction schema for an inbox. Args: domain_id: Domain ID for the inbox. inbox_id: Inbox ID. name: Schema name. schema: JSON string of a valid JSON Schema object. description: Optional schema description. enabled: Enable extraction immediately (default: true).
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. Args: domain_id: The domain ID (from list_domains)
delete_inbox description is terse (27 chars: 'Delete an inbox.') and lacks context. Does it remove all associated threads? Can it be undone? Is there a soft-delete option? The tool performs an irreversible action but provides no warning or confirmation step. Destructive operations should document consequences and offer a dry-run pattern.
create_inbox parameter descriptions lack prescriptive constraints. 'webhook_endpoint' is described as 'URL to receive notifications' but no format validation or security guidance (e.g., must be HTTPS, no auth in URL). Agents could pass invalid URLs. Parameter descriptions should state format, validation rules, and constraints explicitly.
Tool composition dependency not documented. create_domain → get_domain_records → verify_domain is a required workflow. Descriptions reference this (e.g., 'Call get_domain_records to see the required DNS records') but workflow is implicit. Agents may call verify_domain before get_domain_records, wasting a call. Should include explicit 'Prerequisites:' or 'Workflow:' sections in descriptions.
set_extraction_schema parameter 'schema' is a JSON string ('JSON string of a valid JSON Schema object'), which forces agents to construct and validate JSON Schema objects as strings. This is error-prone and lacks validation feedback. Consider accepting a structured object or providing a schema builder tool instead.
Pagination not mentioned. list_domains and list_inboxes may return hundreds of results. No limit, offset, or cursor parameters visible. If results exceed context window, agents have no way to paginate. Tools should document page size limits and provide pagination controls.