# three.ws Notifications (npm · @three-ws/notifications-mcp)

Read the inbox, mark items read, manage delivery preferences, and register Web Push devices.

- Trust score: 64/100 (medium)
- Change this week: +21
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- npm · `@three-ws/notifications-mcp`: 64/100 (this document), [markdown](https://verifymcp.io/servers/nirholas-notifications-mcp/three-ws-notifications-mcp.md), [page](https://verifymcp.io/servers/nirholas-notifications-mcp/three-ws-notifications-mcp)

## Channel facts

- Registry: `npm`
- Package: `@three-ws/notifications-mcp`
- Version: `0.1.2`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Supply Chain Security**: 87/100
  - No malware found by supply-chain analysis.
  - Only part of the dependency tree could be resolved (95 of 99), so this covers what we could see, not the whole tree.
  - No install/post-install scripts declared.
  - Only part of the dependency tree could be resolved (95 of 99), so this covers what we could see, not the whole tree.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (Apache-2.0).
  - Actively maintained (last published 22 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 68/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 1492 tokens (~213/item across 7 items; 7 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### Claude

```bash
claude mcp add nirholas-notifications-mcp -- npx -y @three-ws/notifications-mcp
```

### Codex

```bash
codex mcp add nirholas-notifications-mcp -- npx -y @three-ws/notifications-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "nirholas-notifications-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@three-ws/notifications-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add nirholas-notifications-mcp --command npx --arg -y --arg @three-ws/notifications-mcp
```

### Hermes

```yaml
mcp_servers:
  nirholas-notifications-mcp:
    command: "npx"
    args: ["-y", "@three-ws/notifications-mcp"]
```

### Other

```json
{
  "mcpServers": {
    "nirholas-notifications-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@three-ws/notifications-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-02 (score 64, +59)

- [security regression] Provenance: unverified → fail
- [security improvement] Known CVEs: unverified → partial
- [security improvement] Install scripts: unverified → pass
- [security improvement] Malware scan: unverified → pass
- [security] Stability: Stability not yet verified: not enough scan history yet (needs a 30-day window).
- [functional improvement] Schema quality: unverified → excellent
- [functional improvement] License: unverified → pass
- [functional improvement] Dependency health: unverified → partial
- [functional improvement] Maintenance: unverified → pass
- [functional improvement] MCP protocol: unverified → pass
- [functional improvement] Tool coverage: unverified → 100
- [functional] Licence: Apache-2.0

### 2026-08-01 (score 5, −13)

- [functional regression] Tool coverage: 100 → unverified
- [functional] First check of Schema quality: unverified

### 2026-07-31 (score 18, −25)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-27 (score 43)

First indexed and scored.

## MCP tools (7)

### `list_notifications` (~257 tokens)

List notifications

Read the authenticated agent's notification inbox — the inbound-event feed the platform delivers to the account: market/pump alerts, sales & earnings, purchase receipts, social mentions, IRL interactions, and account/security notices. Returns the most recent notifications (newest first), each with its `id`, `type`, the event `payload`, a `read` boolean and `read_at` timestamp (null ⇒ unread), and `created_at`; plus `unread_count`, the total number of unread items in the inbox. Pass `type` to return only one notification type (e.g. "pump_alert", "skill_purchased", "security_alert"), and `limit` (1–50, default 20) to cap how many rows come back. Read-only — use it to surface alerts without polling, then mark_read / delete_notification to manage them.

Input parameters:

- `limit` (integer): How many notifications to return, newest first. 1–50, default 20.
- `type` (string): Optional filter: return only this notification type (e.g. "pump_alert", "skill_purchased", "referral_earned", "security_alert"). Lower_snake_case, ≤40 chars. Omit for all types.

### `mark_read` (~180 tokens)

Mark notifications read

Mark notifications as read in the inbox. Pass `id` to mark a single notification read, or `all: true` to mark every unread notification read at once (exactly one of the two is required). Marking read only updates the read timestamp — it does not delete anything, and re-running with the same arguments has no further effect (idempotent). When `id` is given, returns the notification id and its `read_at`; when `all` is given, returns `marked_read`, the number of notifications newly marked read. To remove a notification entirely use delete_notification instead.

Input parameters:

- `all` (boolean): When true, mark every unread notification in the inbox read. Mutually exclusive with `id`.
- `id` (string): UUID of a single notification to mark read (from list_notifications). Mutually exclusive with `all`.

### `delete_notification` (~135 tokens)

Delete notification

Permanently delete a single notification from the inbox by its `id` (from list_notifications). Unlike mark_read, which only marks it read, this REMOVES the notification for good — the action is irreversible. Only a notification the caller owns can be deleted. Returns `{ ok: true, id, deleted: true }` on success, or a not_found error if the id does not exist for this account (e.g. it was already deleted). Prefer mark_read for normal triage; use this only to discard a notification entirely.

Input parameters:

- `id` (string, required): UUID of the notification to permanently delete (from list_notifications).

### `get_preferences` (~150 tokens)

Get notification preferences

Read the account's notification delivery preferences — the resolved channel matrix the platform uses to decide how each kind of event reaches the owner. Returns `categories` (the catalog of user-facing groups: sales, purchases, social, irl, alerts, account — each with a label and description), `channels` (the deliverable channels: in_app, push, email, telegram), `prefs` (the effective per-category → per-channel on/off matrix with sparse user overrides already merged onto defaults, plus the linked `telegram_chat_id` if any), and `push` (how many web-push devices are registered). Read this before calling set_preferences so you patch from the real current state. Read-only.

### `set_preferences` (~282 tokens)

Set notification preferences

Update the account's notification delivery preferences with a sparse patch. `categories` maps a category key (sales, purchases, social, irl, alerts, account) to a channel map turning each channel on/off (in_app, push, email, telegram) — e.g. { "alerts": { "push": false }, "social": { "email": true } }. Only the category/channel pairs you pass change; unknown keys are dropped server-side and untouched pairs keep their current value (which falls back to the platform default). Pass `telegram_chat_id` (a numeric Telegram chat id, or "" to unlink) to control where the telegram channel delivers. Provide at least one of `categories` or `telegram_chat_id`. WRITE but idempotent — re-applying the same values is a no-op. Returns the full resolved preference matrix after the update. Read it first with get_preferences.

Input parameters:

- `categories` (object): Per-category channel toggles. Outer keys: sales, purchases, social, irl, alerts, account. Inner keys: in_app, push, email, telegram → boolean. Unrecognised keys are ignored. Example: { "alerts": { "p…
- `telegram_chat_id` (string): Numeric Telegram chat id to deliver the telegram channel to, or "" to unlink it.

### `register_push_device` (~147 tokens)

Register push device

Register a Web Push device so the account receives push notifications on it. Pass the browser `subscription` object exactly as `pushManager.subscribe().toJSON()` produces it — { endpoint, keys: { p256dh, auth } }. Push endpoints are globally unique: re-registering the same device upserts (the latest owner wins) and is a no-op, so this is idempotent. Whether a given notification category actually delivers over push is still governed by set_preferences. Returns `{ ok: true }` on success. Use unregister_push_device to remove a device.

Input parameters:

- `subscription` (object, required): A Web Push subscription, exactly as pushManager.subscribe().toJSON() returns it.

### `unregister_push_device` (~151 tokens)

Unregister push device

Remove a Web Push device so the account stops receiving push notifications on it. Identify the device by its push `endpoint` URL (preferred) or by passing the full `subscription` object — at least one is required. Destructive: it tears down the device registration (reverse it by calling register_push_device again). Idempotent: removing an endpoint that is not registered still returns `{ ok: true }`. This affects only push delivery to that device; in_app, email, and telegram preferences are unchanged.

Input parameters:

- `endpoint` (string): The push endpoint URL of the device to remove. Provide this or `subscription`.
- `subscription` (object): Alternatively, the full subscription object; its endpoint is used.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/nirholas-notifications-mcp/three-ws-notifications-mcp#diagnostics

## Score history

- 2026-08-03: 64
- 2026-08-02: 64
- 2026-08-01: 5
- 2026-07-31: 18
- 2026-07-30: 43
- 2026-07-28: 43
- 2026-07-27: 43

## Links

- npm package: https://www.npmjs.com/package/@three-ws/notifications-mcp
- Socket report: https://socket.dev/npm/package/@three-ws/notifications-mcp
- Repository: https://github.com/nirholas/three.ws
- Website: https://three.ws/
- Changelog RSS feed: https://verifymcp.io/servers/nirholas-notifications-mcp/three-ws-notifications-mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/nirholas-notifications-mcp/three-ws-notifications-mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/nirholas-notifications-mcp/three-ws-notifications-mcp