Elaan

io.elaanPublished by elaan.iov0.1.3Updated Oct 24, 2026

Create Elaan notification types, templates and brands, trigger sends, and debug delivery.

Overview

AI-generated overview

Lets an assistant create and manage Elaan notification types, templates, brands and contacts, trigger real sends, and debug delivery.

What you can do
This server exposes Elaan's notification API as tools. It covers notification types (list, get, create, update, delete, restore), templates across email, inbox and push (including email preview and impact reports), per-tenant brands, and contacts with preferences. It can trigger a notification to 1-100 recipients and inspect event status, delivery logs and aggregate stats for debugging.
When to use it
Use it when you are building or maintaining an Elaan notification integration and want to define types, write templates, set up brands, or investigate why a message did not arrive, without working by hand in the console.
Requirements
Runs locally over stdio, fetched with npx on first run, so Node.js is needed. Requires an Elaan service key (sk_...) supplied through the ELAAN_API_KEY environment variable. Self-hosted installs can set ELAAN_API_BASE. Network access to the Elaan API is required.
Before you install
The service key in ELAAN_API_KEY grants access to your Elaan account and is read from the environment. trigger_notification sends real messages to real recipients. delete_template is a hard delete with no restore, while notification type deletion is reversible. Transport credentials such as SMTP passwords and push service accounts are deliberately not exposed. Contact data is read and written.

Installation

In SourceWeft

  1. Open Elaan in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

@elaanio/mcp

A Model Context Protocol server for Elaan, so the tedious half of a notification integration happens in your editor instead of by hand in a console: creating notification types, writing templates for three channels, setting up per-tenant brands, and working out why a message did not arrive.

Documentation: elaan.io/docs.html

Setup

Create a service key (sk_…) in the console, then add the server to your assistant's MCP config. Nothing to install — npx fetches it on first run.

Claude Code — .mcp.json in your project, or ~/.claude.json for every project:

json
{  "mcpServers": {    "elaan": {      "command": "npx",      "args": ["-y", "@elaanio/mcp"],      "env": { "ELAAN_API_KEY": "sk_..." }    }  }}

Cursor — the same block in .cursor/mcp.json. Most other MCP clients take the same shape.

Self-hosting Elaan? Point it at your own install:

json
"env": {  "ELAAN_API_KEY": "sk_...",  "ELAAN_API_BASE": "https://elaan.internal.example.com/v1"}

What it can do

AreaTools
Notification typeslist, get, create, update (channel defaults, variables, opt-out policy), delete, restore
Templateslist, get, create, update, delete across email / inbox / push; preview an email render; report templates affected by a type's variables
Brandslist, create, update (values and sender), delete
Contactslist, get, create, read and set preferences
Sendingtrigger a notification to 1–100 recipients
Debuggingevent status with per-channel outcomes, the delivery log with filters, aggregate stats

Ask for what you want and let it do the fan-out:

Create an order_shipped type that goes to email and the inbox, with an order_id variable, then write both templates using our acme brand.

A customer says they never got their shipping email. Event id is 01J… — what happened?

What it deliberately cannot do

Transport credentials. /v1/email-transport and /v1/push-transport are not exposed at all. They hold SMTP passwords and FCM service accounts, and an agent has no business reading or rotating them. Configure those in the console.

See your API key. It is read from the environment, never accepted as a tool argument, because arguments are model-visible and end up in transcripts.

Note that delete_template is a hard delete with no restore, while delete_notification_type is soft and reversible with restore_notification_type. trigger_notification sends real messages.

Development

bash
pnpm installpnpm --filter @elaanio/mcp buildpnpm --filter @elaanio/mcp test    # spawns the server, speaks JSON-RPC to a stub API

The test drives the real binary over stdio rather than importing the source, which is how it caught a zod v4 behaviour that made every create_notification_type call fail before it left the process.

Licence

MIT

Source: mcp/README.md at commit 0bd10ec

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

1
  1. v0.1.3LatestSep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts