NotifyHub — Unified N… vs Sendraven MCP Server | AllMCPs
Side-by-Side Model Context Protocol Comparison
NotifyHub — Unified Notification MCP Server vs Sendraven MCP Server
In-depth architectural comparison of the NotifyHub — Unified Notification MCP Server and Sendraven MCP Server MCP servers. Compare execution transports, security boundaries, tool capabilities, quality scores, and ready-to-paste client installation snippets for Claude, Cursor, Windsurf, and VS Code.
At a Glance & Executive Verdict
NotifyHub — Unified Notification MCP Server
Communication · Remote HTTP/SSE
Quality: 49/100 (Fair) | Auth: No auth required
Sendraven MCP Server
Communication · Local stdio
Quality: 57/100 (Good) | Auth: No auth required
Verdict Summary: Choose NotifyHub — Unified Notification MCP Server if you need specialized Communication tools running via a hosted cloud SSE transport. Choose Sendraven MCP Server if your workspace requires Communication integration with local subprocess execution. Both servers can be configured concurrently in your client's mcpServers manifest.
Which MCP Server Should You Choose?
Choose NotifyHub — Unified Notification MCP Server when:
You need dedicated capabilities in the Communication domain.
You prefer remote streaming HTTP/SSE transport architecture.
Your security boundary fits: No auth required (Free / Open Source).
NotifyHub — Unified Notification MCP Server Tools (33)
send_notification
Send via any channel (generic)
send_email
Send email
send_sms
Send SMS via Twilio
send_slack
Send to Slack channel
send_telegram
Send via Telegram Bot
send_discord
Send to Discord channel
send_whatsapp
Send WhatsApp via Twilio
send_teams
Send to Microsoft Teams
send_google_chat
Send to Google Chat
send_push
Send push via Firebase
send_twitter
Post a tweet on Twitter/X
send_linkedin
Publish a post on LinkedIn
+21 more tools listed on main page
Sendraven MCP Server Tools (55)
send_email
Send a transactional email, immediately or scheduled. scheduled_at takes a relative phrase like 'in 3 days' or an ISO timestamp. The From domain must already be verified. Every accepted send answers with the same fields: id, status, thread_id, scheduled_at, skipped, reason and approval_id. skipped:…
list_emails
List messages newest first with their delivery status, including held, scheduled, skipped and failed ones and the mail campaigns and automations sent. Filter by status or recipient. Paged: at most 100 per call; while has_more is true, next_cursor passed back as cursor with the same filters returns…
get_email
Fetch one message with its full event timeline (send, delivery, bounce, complaint, open, click). The timeline shows why an email didn't arrive.
cancel_scheduled_email
Cancel a scheduled email before it sends. Only works while status is 'scheduled': a message that has already started sending, or is in any other state, answers 409 invalid_state naming its status; a retry answers the same, and get_email shows where it stands. An unknown id answers 404 not_found.
list_sending_domains
List sending domains with their verification status and the DNS records each one needs. Each record shows what is currently published, so this diagnoses a stuck verification. mail_from says whether SES has adopted the bounce. subdomain as the Return-Path: pending while SES polls for its MX record,…
Ready-to-Paste Client Configurations
Paste either (or both) of these JSON server blocks into your client config file (e.g. claude_desktop_config.json or ~/.cursor/mcp.json).
NotifyHub — Unified Notification MCP Server Configuration
NotifyHub — Unified Notification MCP Server is categorized under Communication and uses a remote streaming HTTP/SSE transport. In contrast, Sendraven MCP Server belongs to Communication using local stdio subprocess. Select NotifyHub — Unified Notification MCP Server when you need capabilities focused on communication and Sendraven MCP Server when you require tools for communication.
Register a sending domain and get back the DNS records to publish. It takes the domain mail is sent from — mail.<domain> and news.<domain> are provisioned beneath it and the right one is chosen per message, so a marketing complaint spike can never affect password reset delivery. risk_class provisio…
verify_sending_domain
Re-check a domain's DNS records now instead of waiting for the background monitor. Also restarts bounce-path (mail_from) verification when SES gave up before the MX record existed.
list_suppressions
List addresses we refuse to mail and why (hard_bounce, complaint, unsubscribe, manual, list_hygiene), newest first, each with its scope. When someone reports not receiving email, this shows whether the address is suppressed. email returns one address's suppressions directly; scanning pages instead…
add_suppression
Stop sending to an address. Scope 'marketing' leaves transactional mail working; the default is 'all'. Reason 'unsubscribe' is a real opt-out: it also cancels the person's queued scheduled sends and ends their automation enrolments, which is what a person who asked to stop expects and 'manual' does…
remove_suppression
Remove a suppression so the address can be mailed again. A hard bounce means the address was rejected by the receiving server, and re-sending raises the bounce rate that AWS enforces on. The scope must match the stored one: removed: false means nothing was suppressed in that scope (an address suppr…
create_broadcast
Create a campaign as a draft. Nothing is sent: preview_broadcast reports its reach and send_broadcast sends it. identity_id must be a marketing sending domain (see list_sending_domains; risk_class 'marketing'). topic_key must name an existing topic (list_topics); an unknown one is refused with 422…
get_broadcast
One campaign, with a 'progress' object while it is sending, paused or testing: how many addresses are still pending, sent, failed, or skipped because the person opted out after the campaign started. This is what tells a paused campaign that is still making progress from one that is waiting; pause_r…