Cue

What Cue MCP server does

Cue MCP server connects AI agents to a self-hosted notification policy and delivery service. It lets agents notify people while applying the same controls used by backend events: recipient preferences, muted channels, frequency limits, cooldowns, quiet hours, digests, and approval requirements. Each message receives a status and reason, so an agent or operator can determine whether it was delivered, delayed, suppressed, failed, or held for review.

The service is designed for situations where several agents may contact the same person. Each agent can use its own key and receive its own per-person budget, importance ceiling, and optional approval condition. Category limits can also count messages across senders. Messages that exceed a budget are retained as suppressed rather than silently discarded.

How it works

Run the MCP entry point with uvx cue-notify mcp, then configure an MCP client to launch it. The agent communicates with Cue through the MCP interface, while Cue evaluates the request against the recipient’s policy and the sending agent’s permissions. Quiet hours use the person’s time zone. Critical messages can bypass quiet hours only where the recipient’s category settings allow it and the agent is permitted to claim that importance.

Approval requests pause risky messages until a reviewer decides through a one-time link sent through their own notification channel. Agent keys cannot approve requests or change people’s profiles. Cue records the rules that matched and the reason for the resulting message status, providing an audit trail for automated notification decisions.

Setup and configuration

Cue is self-hosted. Install the Python package or start the provided Docker Compose deployment, then create an API key with cuectl keys create admin. The command prints the key once; keep it as CUE_API_KEY. A local SQLite setup can use Python 3.12 or later, while the Docker example runs an API, worker, and PostgreSQL.

For a minimal local run, enable the embedded worker and use the console provider for push and SMS. Apply database migrations before starting the service. The MCP command can then be launched with uvx, provided it can access the Cue instance and credentials configured for the deployment. Notification routes can use bundled connectors such as FCM, APNs, Twilio, SMTP, Amazon SES, Resend, Slack, Telegram, webhook, or console, subject to the deployment’s configuration.

Tools and capabilities

The Cue MCP server provides agent-facing tools to:

• Notify people through Cue’s policy and delivery pipeline.
• Request human approval before a risky action or message proceeds.
• Inspect notification delivery and resulting statuses.
• Use the same budgets, quiet hours, preferences, digests, and audit records as other Cue clients.

Cue can also support coding-agent notifications through cue-hook, and its approval workflow includes bridges for LangGraph, Pydantic AI, CrewAI Flows, and Dapr Agents. Optional message screening is experimental, disabled by default, and requires a TypeSafe API key.

Limitations and notes

Cue is self-hosted only and does not provide a hosted service. It has no built-in in-app inbox, notification feed, or admin UI; configuration uses the HTTP API, CLI, and cue.toml. Delivery depends on a bundled connector or a connector you provide through a signed webhook. Screening is not established for production use, and messages from the backend’s own system are not screened.