Self-hosted newsletter ops in one Go binary. Humans use the web UI. Agents use the same system through REST, CLI, or MCP, from Cursor, Claude Code, OpenClaw, or any harness that can call an API.
Most newsletter tools are dashboards with an API bolted on. Dispatch is the other way around: an operable service that happens to have a UI.
Subscribers, editions, and delivery live on your server, behind your SMTP, SES, or Mailgun account. No vendor list lock-in.
Lists, imports, templates, test sends, scheduled blasts, bounce handling, and stats are available through REST, CLI, and MCP. The web UI uses the same operations.
Validate templates, send a test, then confirm before a list send. That matters when an agent is holding the API key.
Pick the door that matches your harness. Every operation is available through every interface.
30 tools and 4 resources over the Model Context Protocol. Stdio mode plugs into MCP-capable environments without a custom integration layer.
Point any agent or script at your base URL with an API key. Cursor, Claude Code, OpenClaw, CI, or a one-off curl: same contract.
Cobra commands for lists, subscribers, editions, send, import/export, and stats. JSON output when you need to pipe results into something else.
Embedded htmx UI for day-to-day list and edition work, previews, and send monitoring. No separate frontend stack to deploy.
Dispatch does not require a particular IDE or runtime. If the harness can speak MCP or HTTP, it can run a newsletter.
Run dispatch mcp as an MCP server, or operate a remote instance over REST. Copy docs/cursor-rules/ into .cursor/rules/ for project conventions.
Same options: MCP stdio locally, or API key + base URL against a deployed Dispatch. The agent reads ops docs and drives the full lifecycle.
Optional skill under docs/skills/dispatch-newsletter/ for install-and-operate workflows. Peer to the other harnesses, not a special tier.
Codex, custom agents, automation bots, shell loops. If it can POST JSON with a header, it can subscribe, compose, test, and send.
A typical send is validate, test, confirm, then blast. The harness is yours; the discipline is built into how Dispatch is meant to be used.
Give the agent the base URL and API key (or MCP). It discovers lists and tags, builds an edition from a template, and refuses to skip the test send when you follow the ops guide.
# Any harness with MCP or HTTP user: Send a newsletter to our VIP subscribers agent: Checking Dispatch... ✓ Service at localhost:8025 ✓ List "updates": 847 active ✓ 23 tagged "vip" Creating edition from template... ✓ Edition "march-vip-update" created ✓ Template validated Sending test to you@example.com... ✓ Test delivered agent: Test looks good. Send to all 23 VIPs? user: Yes agent: ✓ Sent 23/23 Open rate: 74% (after 24h)
The newsletter primitives operators need, without a SaaS bill or a container farm.
Go templates with personalization. Validated before send so bad syntax never hits the list.
Queue a time; recipients are rebuilt at dispatch. Cancel with one API call.
Free-form tags on subscribers. Filter sends without splitting into endless lists.
Pending until confirm. Built-in confirmation mail. Sensible default for GDPR-minded ops.
SMTP 5xx, IMAP DSN monitor, SES/SNS and generic webhooks. Bounced addresses drop out automatically.
Raw single sends for auth codes and notices via POST /api/v1/send/raw, same deliverability stack.
Also: open tracking, image hosting, CSV import/export, rate-limited delivery, List-Unsubscribe / DKIM / multipart. Full list in the README.
No containers required. No managed newsletter SaaS. One binary on any Linux server.
Clone the repo, build the binary, point your harness at MCP or REST. First test send in minutes.