Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CUE_API_KEYYesThe 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
send_eventA

Report that something happened to a person (e.g. order.shipped) and let Cue's rules decide whether and what to notify. Prefer it to send_message whenever a rule can cover the case. Needs the events:write scope.

Rules run asynchronously, so the result only confirms receipt: id, status (pending until processed) and duplicate (true when this idempotency key was already reported; nothing new happens). Call get_event with the id to see, per rule, whether it matched and which message it produced. An unknown recipient gets an empty profile, so a message may end suppressed with no_reachable_channel. For agent keys, the messages count against the agent's per-person budget, are capped at its importance ceiling and may wait for approval. Fails with 403 for names starting with cue. and 422 for invalid input.

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 messages:write scope.

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. status is queued, suppressed (read status_reason) or pending_approval (held for a person: do not resend). Repeating an idempotency_key returns the original message instead of sending again. Fails with 404 for an unknown template or category, 403 when an agent may not use the category and 422 for a channel the server does not have.

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 message_id from get_event; use list_messages when you have no id. Needs the messages:read scope.

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. frequency_cap: 3 per 1 day, 0:00:00 or agent_budget: …; null otherwise), category, template, channels (planned, in fallback order), channel (the one used), locale, content (rendered title, body, url… under default and each channel with its own override), importance, agent, event_id, rule_id, reviewed_by, reviewed_at, screening, attempts, send_at, expires_at, sent_at, delivered_at, opened_at, clicked_at, converted_at and created_at. Fails with 404 when the id does not exist or, for an agent key, belongs to another sender.

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 messages:read scope; agent keys see only their own messages.

Returns items, each with the same fields as get_message, and next_cursor, which is not null when older messages exist beyond limit. Fails with 404 when recipient is not a known external id.

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 messages:write scope.

Cue reports a cue.approval_requested event per reviewer, which the server's rules turn into a notification with a one-time review link; only people decide, no tool can. Returns the request: id, status (pending), title, body, reviewers, importance, metadata, expires_at and created_at. Then poll get_approval with the id and act only on approved. Agent keys may name only their agent's configured reviewers (403 otherwise) and have a limit of open requests (429, 10 by default).

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 status is pending. Needs the messages:read scope.

Returns id, status (pending, approved, rejected or expired; a request past expires_at reads as expired), title, body, reviewers, importance, agent, requested_by, metadata, comment (the reviewer's note, if any), decided_by, decided_at, expires_at and created_at. Treat anything but approved as no. Fails with 404 when the id does not exist or, for an agent key, belongs to another agent.

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 message_id with get_message for delivery, and use explain for a dry run instead. Needs the messages:read scope.

Returns id, name, source, idempotency_key, data, status (pending until the worker runs the rules, then processed, or failed with the reason in error), occurred_at, received_at and outcome: null while pending, else one entry per rule with rule, matched, reason, status, message_id and digest_id. matched: false comes with condition_false, outside_rollout or condition_error. A composed message has status and message_id, and reason is its status_reason when suppressed (e.g. agent_budget: …, unsubscribed); digested means it joined digest_id; agent_not_allowed means the agent may not use the rule's category. An empty list means no rule listens for the name. Fails with 404 when the id does not exist or, for an agent key, was reported by another sender.

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 rules, one entry per rule listening for the name, with rule, matched, status (what the message would get, e.g. queued or suppressed), reason and digest_id, read like get_event's outcome. Fails with 404 when recipient does not exist yet.

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 data a template needs before send_message; list_templates gives the keys. Needs an admin key, so agent keys get 403.

Returns locale (the one used) and variants: the rendered title, body, url and other content under default and under each channel with its own override. Fails with 404 for an unknown template and 422 when it cannot be rendered.

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 templates, up to 200, each with key, description and locales.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.6/5.0

Scored across 10 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues