MCP server for SpamTitan email security — manage quarantine, allowlists, blocklists, and view email stats
SpamTitan MCP demonstrates solid tool definition quality with complete schemas, clear descriptions, and proper risk annotations. All 9 tools are explicitly registered with input schemas and descriptions. Naming follows verb-noun conventions (navigate, status, get, release, delete, manage). Descriptions are comprehensive (100-300 chars) and include context about prerequisites and side effects. Tool annotations (readOnlyHint, destructiveHint) are present and correctly applied. However, there are notable gaps: (1) output schemas are not documented for any tool, LLMs cannot reason about return structure; (2) pagination is implemented (page/per_page in get_queue) but total count is not documented in the output; (3) some parameter descriptions could be more specific about format and constraints; (4) error recovery guidance is minimal, tools do not return actionable error messages with suggestions. The server demonstrates production patterns like stateless request handling and proper secret injection (AUTH_MODE=gateway), but lacks documentation of response shapes and error categories.
⚠ DESTRUCTIVE — IRREVERSIBLE. Permanently delete a quarantined message by ID. This action cannot be undone and will remove the message from quarantine storage. Confirm with the user before invoking.
Get a single quarantined message by ID. Returns sender, recipient, subject, quarantine reason, spam score, and status. Renders as an interactive card in MCP Apps hosts.
List the email quarantine queue. Returns quarantined messages with sender, recipient, subject, and reason for quarantine.
Get email flow statistics from SpamTitan including messages received, blocked, quarantined, and delivered. Supports filtering by time period.
Add or remove sender allowlist entries in SpamTitan. Allowlisted senders always bypass spam filtering.
No output schemas documented for any tool. LLMs cannot plan downstream operations or extract required fields. For example, spamtitan_get_queue returns paginated results but the response structure (fields per message, total count, next_cursor) is not defined.
Pagination documented in parameters (page, per_page) but no total_count or has_more field documented in output. LLMs cannot determine whether to fetch more pages without this metadata.
Error handling and recovery guidance is minimal. Tools like spamtitan_delete_message and spamtitan_manage_blocklist do not document what errors might occur or what the LLM should do next (retry, ask user, escalate). The destructive_delete_message description says 'Confirm with the user before invoking' but the tool itself has no confirmation/dry-run parameter.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 73 | 2026-07-28+ | v2 |
⚠ HIGH-IMPACT. Add or remove sender blocklist entries in SpamTitan. Modifies email delivery policy and affects deliverability for users. Blocklisted senders are always rejected or quarantined. Reversible by removing entries. Confirm with the user before invoking.
Discover available SpamTitan tools by domain. Returns tool names and descriptions for the selected domain. All tools are callable at any time — this is a help/discovery aid, not a prerequisite.
Release a quarantined message by ID, delivering it to the intended recipient.
Show credentials status and available domains
Tool naming for list management could be clearer. 'spamtitan_manage_allowlist' and 'spamtitan_manage_blocklist' use an action enum (add/remove/list) to determine behavior. This combines three separate responsibilities in one tool. Consider splitting into spamtitan_add_allowlist, spamtitan_remove_allowlist, spamtitan_list_allowlist.
Parameter 'sender' in manage_allowlist/blocklist lacks detailed format description. Should specify: 'Sender email address (user@example.com) or domain (@example.com). Valid email format required.'
The spamtitan_navigate tool is a discovery aid but introduces an extra step. Tools are 'callable at any time' yet the description suggests users should call navigate first. This is slightly contradictory, either discovery is optional or required. Clarify in the description.