About three.ws Alerts
three.ws Alerts is an MCP server for account holders who want an agent to manage pump.fun monitoring rules. A server-side cron checks events and delivers alerts in-app, through signed webhooks, or to Telegram.
Key features
- 01Create, update, and delete alert rules
- 02Monitor graduations, prices, and whale buys
- 03Send alerts in-app, by webhook, or Telegram
- 04Inspect fired alerts and channel health
- 05Manage account-scoped rules and history
Use cases
- 01Track a token's market-cap threshold
- 02Watch for new launches or large buys
- 03Review alert history and delivery outcomes
MCP support
The MCP server provides tools to read, create, update, and delete alert rules, and to query fired-alert history. Calls require a three.ws session and access only that account's data.
Configuration
Local server config is the same for every client. Copy it into your client’s MCP config file.
npx -y @three-ws/alerts-mcpTHREE_WS_BASEBase URL of the three.ws API that serves the alert-rules and notifications endpoints. Override only when self-hosting or targeting a preview deployment.THREE_WS_TIMEOUT_MSPer-request timeout in milliseconds for the live three.ws API reads and writes.THREE_WS_SESSIONSecretYour three.ws session token (the value of the `__Host-sid` cookie from a signed-in browser). Required by every tool — all rules and alerts are scoped to YOUR account. Writes also use it to fetch a one-time CSRF token. Treat like a password.Local servers need a runtime on your machine (e.g. Node.js 18+). Config file locations differ by client; see your client’s docs.
Tools
5Saved tool list · updated 2w ago
This tool takes no parameters.
Details
From the project README@three-ws/alerts-mcp
Run your own pump.fun monitoring from any AI agent — define alert rules, deliver them in-app / by signed webhook / to Telegram, and read the fired-alert history.
A Model Context Protocol server that turns the three.ws pump.fun alerts surface into an agent-drivable control plane over stdio. Define rules on pump.fun events — graduations, market-cap crossings, whale buys, new launches — and let the three.ws cron evaluate them against the live event stream and deliver across in-app, webhook, and Telegram. Read back what actually fired, with per-channel delivery health.
Rules are account-scoped: every call carries your three.ws session, so the server reads and writes only your rules and your alert history. The pumpfun-monitor cron does the watching server-side, so your rules fire across devices with no dashboard open.
Install
npm install @three-ws/alerts-mcp
Or run with npx (no install):
npx @three-ws/alerts-mcp
Quick start
Claude Code, one line:
claude mcp add alerts -e THREE_WS_SESSION=your-__Host-sid-cookie -- npx -y @three-ws/alerts-mcp
Claude Desktop / Cursor (claude_desktop_config.json or mcp.json):
{
"mcpServers": {
"alerts": {
"command": "npx",
"args": ["-y", "@three-ws/alerts-mcp"],
"env": {
"THREE_WS_SESSION": "your-__Host-sid-cookie"
}
}
}
}
Inspect the surface with the MCP Inspector:
THREE_WS_SESSION=… npx -y @modelcontextprotocol/inspector npx @three-ws/alerts-mcp
Authentication
Every tool is account-scoped. Set THREE_WS_SESSION to the value of your __Host-sid cookie from a signed-in three.ws browser session (DevTools → Application → Cookies → __Host-sid). The server sends it the same way your browser does; for writes it first fetches a one-time CSRF token from /api/csrf-token and echoes it, exactly like the site. Treat the session value like a password. No Solana key or signer is involved.
Tools
| Tool | Type | What it does |
|---|---|---|
list_alert_rules | read-only | List your alert rules with live delivery health — last_fired_at, recent failures, recent per-channel outcomes. |
create_alert_rule | write (appends) | Define a new rule on a pump.fun event. Not idempotent — each call adds a rule (max 50). |
update_alert_rule | write (idempotent) | Retune a threshold, pause/resume (enabled), swap delivery channels, or change kind. Only passed fields change. |
delete_alert_rule | write (destructive) | Permanently remove a rule and its fire/delivery history. Prefer update_alert_rule with enabled:false to pause. |
get_alert_history | read-only | Read the alerts that actually fired, newest first — each with a summary, originating rule_id, and full payload. |
Rule kinds & targeting
kind | Target | threshold |
|---|---|---|
graduation | global, or target_mint / target_agent | — |
price_above | target_mint (required) | USD market cap |
price_below | target_mint (required) | USD market cap |
whale_buy | target_mint (required) | minimum buy size in SOL |
new_mint | target_agent (required) | — |
market_anomaly | none (whole market); optional filters: processors (price, tvl, stablecoin_supply, stablecoin_peg, funding, open_interest), min_severity (medium, high default, critical), subject | , |
At least one delivery channel must be on: deliver_in_app (default true), webhook_url (HTTPS — a per-rule webhook_secret is generated for verifying the webhook-signature header), and/or telegram_chat (numeric chat id or @username). cooldown_seconds (5–86400, default 300) throttles repeat fires.
Any coin referenced in a rule is runtime input you supply. three.ws promotes only $THREE (
FeMbDoX7R1Psc4GEcvJdsbNbZA3bfztcyDCatJVJpump).
Example
// create_alert_rule — alert when a tracked agent's coin graduates, via webhook + Telegram
> {
"kind": "graduation",
"target_agent": "8a1c…-uuid",
"webhook_url": "https://hooks.example.com/pump",
"telegram_chat": "123456789",
"cooldown_seconds": 600
}
{
"ok": true,
"rule": {
"id": "…", "kind": "graduation", "label_display": "Graduations · tracked agent",
"target_agent": "8a1c…-uuid", "deliver_in_app": true,
"webhook_url": "https://hooks.example.com/pump",
"webhook_secret": "whsec_…", "telegram_chat": "123456789",
"cooldown_seconds": 600, "enabled": true,
"last_fired_at": null, "recent_failures": 0, "recent_deliveries": []
}
}
// get_alert_history — what fired, newest first
> { "limit": 2 }
{
"ok": true, "count": 2, "unread_count": 1,
"alerts": [
{ "id": 1841, "fired_at": "2026-06-24T…Z", "read": false,
"summary": "Whale bought 12.50 SOL ($2,310) of $THREE",
"rule_id": "…", "kind": "whale_buy", "mint": "FeMb…pump", "symbol": "THREE",
"event": { "amount_sol": 12.5, "amount_usd": 2310, "buyer": "…", "tx": "…" } }
]
}
Requirements
- Node.js >= 20.
- A signed-in three.ws session (
THREE_WS_SESSION). - Network access to
https://three.ws(or your ownTHREE_WS_BASE).
Environment variables
| Variable | Required | Default | Notes |
|---|---|---|---|
THREE_WS_SESSION | yes | — | Your __Host-sid cookie value. Account credential — secret. |
THREE_WS_BASE | no | https://three.ws | Override only for self-hosting / preview deployments. |
THREE_WS_TIMEOUT_MS | no | 20000 | Per-request timeout (ms). |
Programmatic use
The package entry point exports TOOLS (every tool definition: name, title,
description, inputSchema, annotations, handler) and buildServer(), which returns a
fully-registered McpServer with no transport attached. Importing is side-effect free and needs
no session, so you can mount the alert tools inside a host of your own or inspect the surface
offline; the session is only required when a handler actually runs.
// run with: THREE_WS_SESSION=<your __Host-sid value> node this-file.mjs
import { TOOLS, buildServer } from '@three-ws/alerts-mcp';
for (const tool of TOOLS) {
const kind = tool.annotations.readOnlyHint ? 'read ' : 'write';
console.log(`${kind} ${tool.name}`);
}
// A tool handler is a plain async function against the live API.
const list = TOOLS.find((t) => t.name === 'list_alert_rules');
console.log(await list.handler({}));
// Or hand the whole registered server to your own MCP transport.
buildServer();
Links
- Homepage: https://three.ws
- Changelog: https://three.ws/changelog
- Issues: https://github.com/nirholas/three.ws/issues
- License: Apache-2.0, see LICENSE
Part of the three.ws SDK suite — 3D AI agents, on-chain identity, and agent payments.
Website · Changelog · GitHub
Comments
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.