# Ray notifications Muse connector

From musedirectory.ai, the independent directory of Meta Muse connectors. Not affiliated with Meta.

## Ray notifications

Send email, SMS, push, Slack, Discord and Telegram notifications with template management

- Record: https://musedirectory.ai/connector/ray-notifications
- Category: Productivity
- Developer: gege-mn (https://ray.gege.mn/docs)
- Muse status: Extra setup. Not in Muse's Connectors list yet. Muse can still use it: its page gives you a request to paste into Muse.
- Health: Working, 1125ms, checked 2026-09-28T08:30:55Z
- Endpoint: https://ray-api.gege.mn/mcp
- Auth: Needs an access key; Pricing: unknown
- Screening: Screened, no issues found (2026-09-25T07:36:30Z)
- Source: Found in the official MCP Registry (io.github.gege-mn/ray-mcp) https://registry.modelcontextprotocol.io/v0/servers?search=io.github.gege-mn%2Fray-mcp

Ray is a notification service that lets you send messages across email, SMS, push notifications, Slack, Discord, Telegram and webhooks. Create and manage reusable templates, track delivery status, monitor link clicks, and set up outbound webhooks for delivery events.

Example request: "Send a notification to my team on Slack and email them a receipt at the same time using a template"

How to connect: Not in Muse's Connectors list yet, but Muse can still use it. Paste this into Muse: "Use Ray notifications to help me. It is a free service with an MCP server at https://ray-api.gege.mn/mcp. It needs an API key from gege-mn; ask me to enter it through your secure credential prompt. Ask me before you share anything with it." Muse asks before it shares anything with the app's site. Meta does not review apps used this way, so only use ones you trust. We tested this in the Muse app on September 24, 2026: Muse used an app's link directly this way and returned a live answer.

Tools:
- whoami: Identify the API key this connection uses (GET /me): `tenantId` (the workspace), `apiKeyId` and `scopes`. Write tools need the `write` scope; call this to check before attempting them.
- get_usage: The workspace's plan, subscription status and this calendar month's usage against the monthly quota (GET /billing/subscription). `used`/`remaining` are null on unmetered plans. On a hard-capped plan, sends beyond the quota fail with HTTP 402 quota_exceeded.
- list_channels: List the delivery channels configured in this workspace (GET /channels). Call this FIRST before sending: each entry's `id` is the `channelConfigId` for send_notification and test_send_template, `kind` is the channel type (ses_email, smtp_email, fcm_push, slack_webhook, discord_we
- send_notification: Send a notification (POST /send; needs a `write`-scoped key). Returns `{ sendId }` with HTTP 202: delivery is asynchronous, so check the outcome with get_send_status. Use exactly one mode: 1. Single: `channelConfigId` + `recipient`. 2. Fan-out: `channelConfigId` + `targets` (1-10
- get_send_status: Delivery status of a send (GET /sends/{id}): `aggregate` counts per status over the whole send (pending, claimed, delivered, failed_retryable, failed_terminal, suppressed) plus one page of per-recipient delivery rows including provider errors. Right after sending, rows are usuall
- list_templates: List message templates (GET /templates): id, name, folder, channelKind, and `publishedVersionId` (null = never published, so it cannot be sent by templateId yet). Archived templates are hidden unless `includeArchived` is true. Use get_template for content and required params.
- get_template: Get one template with its published version and its current draft (GET /templates/{id}): content, logTitle/logDescription, `requiredParams` a send must supply, and paramOverrides. Read this before update_template_draft, which needs the full body.
- create_template: Create a template (POST /templates; write scope). `channelKind` is permanent and must match the channels you'll send through (list_channels `templateKind`). It is saved as an unpublished draft unless `publish: true`; sending by templateId needs a published version (publish_templa
- update_template_draft: Replace a template's draft (PATCH /templates/{id}; write scope). This is a full replacement, not a partial patch: pass content, logTitle, logDescription and paramOverrides as they should end up (get_template first). `name`, `folder` and `channelKind` are required for validation b
- publish_template: Publish a template's current draft as its new live version (POST /templates/{id}/publish; write scope). Sends by templateId use it immediately. Fails if there is no draft or the template is archived.
- archive_template: Archive a template (POST /templates/{id}/archive; write scope). Sends that reference it fail until it is restored with unarchive_template; its name stays reserved meanwhile. Confirm with the user first if it may be in production use.
- unarchive_template: Restore an archived template (POST /templates/{id}/unarchive; write scope). This is how to reclaim a name held by an archived template instead of creating a new one.
- test_send_template: Send a real test of a template's PUBLISHED version to one recipient (POST /templates/{id}/test-send; write scope). It goes through the provider for real, so use a recipient the user controls. Test sends don't count toward the monthly quota (a small daily allowance applies instead
- list_feed_notifications: Read one end user's in-app notification feed (GET /notifications): the entries created by sends with `feed` or `showInFeed`. This is what an in-app inbox would show, not delivery status (use get_send_status for that). Paginate by passing `nextCursor` back as `cursor`.
- get_click_stats: Email link click counts grouped by destination URL (GET /clicks) for a `sendId`, a `campaignId`, or both (at least one is required). Only links from email sends made with `trackClicks: true` are counted.
- list_webhooks: List the workspace's outbound event webhooks (GET /tenant-webhooks): url, subscribed events, enabled flag and delivery health (consecutiveFailures, lastError). Signing secrets are never returned.
- get_webhook: Get one outbound webhook (GET /tenant-webhooks/{id}) including its delivery health (consecutiveFailures, lastDeliveryAt, lastFailureAt, lastError).
- create_webhook: Create an outbound webhook that Ray POSTs signed event payloads to (POST /tenant-webhooks; write scope; Pro plan or higher, otherwise 403). The URL must be public HTTPS. The response contains the signing `secret` exactly once: show it to the user to store (e.g. as an env var), si
- update_webhook: Change a webhook (PATCH /tenant-webhooks/{id}; write scope). Only the fields you pass change; pass at least one. `rotateSecret: true` issues a new signing secret, returned once in the response, and the old secret stops verifying immediately, so the receiving service must be updat
- delete_webhook: Delete (archive) a webhook so it receives no more events (DELETE /tenant-webhooks/{id}; write scope). It cannot be restored through the API; confirm with the user first.
- read_docs: Read Ray's documentation as markdown. With no `slug` it returns the index (llms.txt) listing every page; then pass a page slug, i.e. the path after /docs/ without `.md`, such as `sending`, `templates`, `idempotency`, `errors`, `rate-limits`, `webhooks`, `status-and-feeds` or `cha

Screening checks:
- MCP handshake: pass (Answered in 1230ms)
- Domain against threat feeds (Cloudflare security DNS): pass (ray-api.gege.mn, ray.gege.mn not flagged)
- Published packages against the OSV malicious-package database: pass (No malicious-package advisories)
- Hidden instructions or invisible characters in tool text: pass (21 tools read, nothing found)
- Inputs asking for passwords, card numbers or seed phrases: pass (None found)
- Domain and redirects: pass (No redirects off the domain)
- AI review of purpose and tool behavior: pass (No concerns)