Cue MCP server

Cue

Self-hosted notification decision engine: quiet hours, time zones, digests, frequency caps and preferences in front of the sender you already have.

Documentation · Getting started · Architecture

Your backend reports what happened (order.shipped, payment.failed). Cue decides whether that is worth a notification, renders it in the person's language, picks the time and the route, and hands a finished message to the delivery you connect: your own sending service through a signed webhook, or a bundled connector.

message, whether triggered by a rule, sent directly or broadcast, passes the same checks: unsubscribes, muted channels, frequency caps, cooldowns and quiet hours in the recipient's own time zone, checked again right before sending.

• Rules and policy in one place. JSON Logic rules map events to templates; every

per day at a local time, and fatigue backs off from people who stopped engaging.

• Fewer messages. Digests turn a burst of events into one message per window or one

one-click unsubscribe, and a consent ledger of every change.

• People in control. A hosted preference page (or a JSON API for your own), RFC 8058

status and the reason it was suppressed or failed.

• Answers. Every event records which rules matched and why; every message records its

importance ceilings and human approval before anything goes out.

• Limits for automated senders. Agents and other services get per-person budgets,

curl -X POST https://cue.example.com/v1/events \
  -H "Authorization: Bearer $CUE_API_KEY" -H "Content-Type: application/json" \
  -d '{"name": "order.shipped", "recipient": "customer-42",
       "data": {"order_id": "1001"}, "idempotency_key": "order-1001-shipped"}'

Your delivery endpoint then receives a signed, fully rendered message:

{
  "id": "01a1…",
  "channel": "push",
  "address": "<device token>",
  "locale": "en",
  "importance": "normal",
  "expires_at": null,
  "content": {"title": "Your order is on its way", "body": "Order 1001 ships today.",
              "url": "https://shop.example/orders/1001"},
  "metadata": {"cue_message_id": "01a1…", "cue_tracking_token": "…"},
  "links": {"preferences": "https://cue.example.com/preferences/…"}
}

Who it's for

For teams that already send push, e-mail, SMS or chat messages from their own code and want the decisions (whether, when, how often, over which route, in which language) made in one place, stored, and explainable, on their own infrastructure.

Not for you (yet) if you need:

Resend, Slack, Telegram, a signed webhook and console, plus any you write;

• an in-app inbox or notification feed: planned, not built;
• an admin UI: today you configure Cue through the HTTP API, the CLI and cue.toml;
• a connector Cue does not have yet. Today's are FCM, APNs, Twilio, SMTP, Amazon SES,

• a hosted service: Cue is self-hosted only;
• a visual journey builder for marketing campaigns: not planned.

See the roadmap.

Quick start

With Docker Compose (PostgreSQL, an API and a worker; messages go to the worker's log):

git clone https://github.com/murtazox04/Cue && cd Cue
docker compose up --build -d
docker compose exec api cuectl keys create admin
docker compose logs -f worker

Or with Python 3.12+ and SQLite, in a virtual environment:

Shortened. The full README is on GitHub.