three.ws Signals
NPM · @THREE-WS/SIGNALS-MCP · SCANNED SEP 20
Discover signal feeds ranked by proven edge, rank publishers, and subscribe + track results.
Available components
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. How we score → Why this is hard to score →
Supply Chain Security98
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 31 of 96 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency35
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- License check failed: the license (SEE LICENSE IN LICENSE) isn't a recognized OSI-approved license. See how to fix → Fail
- Actively maintained (last published 8 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability64
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 1590 tokens (~318/item across 5 items; 5 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management83
- Stability observed for 25 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 5 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 6 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the three.ws Signals MCP server?
three.ws Signals runs locally as an npm package, launched with npx -y @three-ws/signals-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · @three-ws/signals-mcp
claude mcp add nirholas-signals-mcp -- npx -y @three-ws/signals-mcp
{
"mcpServers": {
"nirholas-signals-mcp": {
"command": "npx",
"args": [
"-y",
"@three-ws/signals-mcp"
]
}
}
} {
"servers": {
"nirholas-signals-mcp": {
"command": "npx",
"args": [
"-y",
"@three-ws/signals-mcp"
]
}
}
} codex mcp add nirholas-signals-mcp -- npx -y @three-ws/signals-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"nirholas-signals-mcp": {
"type": "local",
"command": [
"npx",
"-y",
"@three-ws/signals-mcp"
],
"enabled": true
}
}
} openclaw mcp add nirholas-signals-mcp --command npx --arg -y --arg @three-ws/signals-mcp
mcp_servers:
nirholas-signals-mcp:
command: "npx"
args: ["-y", "@three-ws/signals-mcp"] {
"McpServers": {
"nirholas-signals-mcp": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"@three-ws/signals-mcp"
]
}
}
} assistant mcp add nirholas-signals-mcp -t stdio -c npx -a -y @three-ws/signals-mcp
{
"mcpServers": {
"nirholas-signals-mcp": {
"command": "npx",
"args": [
"-y",
"@three-ws/signals-mcp"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 20 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
- 19 Sept 26 −3
- Stability: pass → 0.80 functional
- 18 Sept 26 0
- Stability: 0.97 → pass security
- 17 Sept 26 0
- Stability: pass → 0.97 functional
- 16 Sept 26 0
- Stability: 0.97 → pass security
- 15 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.
- 13 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.
- 11 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 20 Sept 2026 · Analysed npm/@three-ws/signals-mcp@0.1.2
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | npm |
Background: How many MCP packages publish verified provenance →
Dependencies 96 packages
| Packages resolved | 96 |
|---|---|
| Stale | 31 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
get_mirror_leaderboard Rank signal publishers by realized performance ~241
Rank followable agents (signal publishers / copy-trade leaders) by REAL, on-chain-derived performance — never inflated. Every number traces to a real signature: realized P&L and win-rate come from closed sniper round-trips, volume from the discretionary custody ledger, and losers are included. Each leader returns rank, agent_id, name, avatar, settled trades, wins, win_rate, realized pnl_sol, roi_pct, trade count, volume_sol, follower counts, last trade time, and a composite score (realized ROI weighted by sample size so a one-trade fluke cannot top a consistent trader). Sort by `score` (default), `pnl`, `followers`, `volume`, or `winrate`. Use this to find a leader before subscribing to their feed. Public, read-only live data — no key required.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | Maximum leaders to return (1–50, default 25). |
| network | string | – | Solana network to rank on (default mainnet). |
| sort | string | – | Ranking key: score (default), pnl, followers, volume, or winrate. |
No output schema declared.
No examples provided.
get_subscriptions List your signal subscriptions + delivery history ~167
List every signal subscription owned by the authenticated account — the follower's tracking surface. Each subscription returns its numeric `id` (pass this to set_subscription_status), the subscriber agent, the feed it follows (slug, title, publisher, pricing), the copy-trade config (mode simulate/live, billing, base_sol, size_scaling, max_per_trade_sol, slippage_bps, firewall_level, copy_exits), live status (status, killed flag, epoch_paid_until, last delivered emission), and the realized delivery stats: `stats.executed` (mirror fills that executed on-chain), `stats.paid_count` (paid deliveries), and `stats.usdc_spent` (total USDC paid to the publisher). Requires THREE_WS_API_KEY. Read-only live data.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
list_signal_feeds Browse the signal-feed marketplace ~261
Discover copy-trade signal feeds on three.ws. Returns the public directory of active feeds, each ranked by its PROVEN realized edge (hit-rate × realized ROI, confidence-regressed toward the publisher's verified track-record score until enough signals have closed — a thin feed riding one lucky call can never top a deep, consistent one). For each feed you get its numeric `id` (pass this to subscribe_signal), `slug`, title, the publisher (name, verified badge, track-record score, realized SOL P&L), pricing (per-signal and per-epoch USDC), and proven stats (closed signals, hit-rate, average realized %, active subscribers, executed fills, avg emit→fill latency, avg follower ROI). Sort by `edge` (default), `roi`, `hitrate`, `subscribers`, or `newest`. Public, read-only live data — no key required.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | – | Maximum feeds to return (1–100, default 60). |
| network | string | – | Solana network the feeds publish on (default mainnet). |
| sort | string | – | Ranking key: edge (proven realized edge, default), roi (avg realized %), hitrate, subscribers, or newest. |
No output schema declared.
No examples provided.
set_subscription_status Resume, pause, stop, or kill a subscription ~206
Control an existing signal subscription owned by the authenticated account. • active — (re)activate it; this also CLEARS any kill flag so it resumes paying/mirroring. • paused — stop delivering for now; the kill flag (if set) is left untouched. • stopped — stop the subscription (soft — its delivery history is kept). • killed — INSTANT kill switch: halts everything immediately; the kill is honoured before any payment or trade can fire. Use this to stop a live subscription from spending or trading right now. Idempotent — setting the same state again is a no-op. Get the subscription `id` from get_subscriptions. Requires THREE_WS_API_KEY.
| Name | Type | Req | Description |
|---|---|---|---|
| state | string | yes | Target state: active (resume + clear kill), paused, stopped, or killed (instant halt of all pay/trade). |
| subscription_id | integer | yes | Numeric subscription id (the `id` from get_subscriptions). |
No output schema declared.
No examples provided.
subscribe_signal Subscribe an agent to a signal feed ~513
Subscribe one of YOUR agents to a signal feed so it copy-trades the publisher. Idempotent: a feed is keyed by (subscriber agent, feed) — re-calling updates the existing subscription instead of creating a duplicate. A new subscription starts at the current emission head, so it is never charged for or made to mirror signals emitted before it subscribed. PAYMENT & RISK: `mode:"simulate"` (default) mirrors WITHOUT paying or trading — it sizes and labels the orders for trust-building, spends nothing. `mode:"live"` BOTH pays the publisher in USDC (x402, per-signal or per-epoch per the feed pricing) AND auto-mirrors real on-chain trades from the subscriber agent's custodial wallet, within its spend policy. Money moves at delivery time (when the publisher emits a signal), not at the moment you call this tool. Use set_subscription_status with killed:true to halt all further pay/trade instantly. Requires THREE_WS_API_KEY; the agent must be owned by that account.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | ID of the subscriber agent (must be owned by the authenticated account). This agent pays and mirrors. |
| base_sol | number | – | Base order size in SOL before the per-signal size multiple/scaling (0.001–10, default 0.05). |
| billing | string | – | How live mode is charged: per_signal (each entry) or per_epoch (a flat fee per epoch window). |
| copy_exits | boolean | – | Mirror the publisher's exits too (sell when they sell). Default true. |
| feed_id | integer | yes | Numeric feed id to follow (from list_signal_feeds — the `id` field). The feed must be active. |
| firewall_level | string | – | Risk firewall on mirrored buys: block (refuse risky trades, default) or warn (allow with a flag). |
| max_per_trade_sol | number | – | Hard cap on any single mirrored order in SOL (0.001–50, default 0.25). |
| mode | string | – | simulate = no pay, no trade (default, safe). live = pays USDC AND auto-mirrors real trades. |
| size_scaling | number | – | Multiplier applied on top of the base size (0.01–20, default 1). |
| slippage_bps | integer | – | Max slippage in basis points for mirrored trades (0–5000, default 300 = 3%). |
No output schema declared.
No examples provided.
What is the three.ws Signals MCP server?
three.ws Signals is an MCP server listed in the public MCP registry as io.github.nirholas/signals-mcp. Discover signal feeds ranked by proven edge, rank publishers, and subscribe + track results. This page covers its npm package (@three-ws/signals-mcp).
Is the three.ws Signals MCP server safe to use?
three.ws Signals scores 78 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the three.ws Signals MCP server expose?
three.ws Signals exposes 5 tools: list_signal_feeds, get_mirror_leaderboard, get_subscriptions, subscribe_signal, set_subscription_status. Their descriptions and schemas cost roughly 1,388 tokens of context every time the server is loaded.
Is the three.ws Signals MCP server still maintained?
three.ws Signals is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.