Cue
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CUE_API_KEY | Yes | The Cue API key, printed once by `cuectl keys create admin` (or `uvx cue-notify keys create admin`). The MCP server uses it to authenticate against the Cue API so its tools work under the same policy and audit trail. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| send_eventA | Report that something happened to a person (e.g. Rules run asynchronously, so the result only confirms receipt: |
| send_messageA | Send one template directly to one person over the channels you list, without rules. Use it for an explicit one-off message (a code, a reply, an alert) when you know the template key; otherwise prefer send_event. Needs the The message still passes its category's policy (preferences, frequency caps, quiet hours, unsubscribes) and, for agent keys, the agent's per-person budget, importance ceiling and approval policy. Returns the message, with the same fields as get_message. |
| get_messageA | Fetch one message by id to learn whether and how a person was notified: delivery status and its reason, the channel used, the rendered content and engagement. Use it after send_message, or with a Returns id, status (queued, sending, pending_approval, sent, delivered, failed, suppressed or cancelled), status_reason (why it was suppressed, failed, held or cancelled, e.g. |
| list_messagesA | List recent messages, newest first, optionally for one person or status: what someone was already sent, what was suppressed, what waits for approval. Use get_message when you have an id. Needs the Returns |
| request_approvalA | Ask people to approve or reject an action you are about to take outside Cue (deleting data, spending money, contacting many people), before you take it. Not for informing anyone: use send_event or send_message. Needs the Cue reports a |
| get_approvalA | Fetch an approval request by id to learn whether a person approved the action you asked about with request_approval. Call it again, with a pause, while Returns |
| get_eventA | Fetch a reported event by id and, for each rule listening for its name, whether the rule fired and what came of it. Use it after send_event to learn what was sent and why or why not; follow a Returns |
| explainA | Dry-run an event for a person: which rules would fire, what each would do and why the others would not. Use it before send_event to check that a rule will reach the person; nothing is stored or sent. Needs an admin key, so agent keys get 403 and should read get_event for a real event instead. Returns |
| preview_templateA | Render a template with sample data to see the exact text a person would get, without sending anything. Use it to check which Returns |
| list_templatesA | List the templates send_message can use, to find a template key. Use preview_template to see one's content. Needs an admin key, so agent keys get 403. Returns |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool targets a distinct resource and action, and descriptions explicitly cross-reference to prevent confusion (e.g. send_event vs send_message, get_event vs get_message, explain vs preview_template). The send/get pairs operate on different entities (events vs messages), so an agent can reliably select the right tool.
Names follow a predictable snake_case verb_noun pattern (list_templates, send_message, get_approval, etc.) with consistent list/get/send/request/preview prefixes. The only deviation is 'explain', a bare verb that breaks the pattern, though it remains clear.
10 tools is well within the ideal 3-15 range for an agent-facing notification platform, and each tool covers a distinct operation (send, inspect, dry-run, approvals). No tool feels redundant or missing from a count perspective.
The surface covers core agent workflows: templates (list, preview), sending (event, message), inspection (event, message, list), approvals (request, get), and dry-run (explain). Minor gaps exist—no list_events, list_approvals, or message cancellation—but agents can work around these for most tasks.