Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

SigRank SignalAF — AI Operator Cascade & Leaderboard

NPM · SIGRANK

SigRank SignalAF on-device scanner — four-token cascade, leaderboard, 25 local tools.

Available components

−4 this week 92 Trust /100

Last scanned (16 hours ago)

Scores higher than 95% of npm servers

Trust breakdown (7 categories)

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 Security99
  • 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
  • 5 of 29 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency100
  • Source repository is publicly reachable at the declared URL. View diagnostics → Pass
  • Cryptographically verified build provenance (signed, bound to SunrisesIllNeverSee/sigrank-mcp). View diagnostics → Pass
  • Clear OSI-approved license (MIT).Pass
  • Actively maintained (last published 14 days ago).Pass
  • Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability80
  • 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 5873 tokens (~195/item across 30 items; 25 tools + 5 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 Management73
  • Stability observed for 22 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
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
  • An AI judge read all 26 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a current MCP spec version (2026-07-28).Pass
What we tested

Checks we ran (16)

  • Malware scan
  • Known CVEs
  • Install scripts
  • Dependency health
  • Source repository
  • Provenance
  • License
  • Maintenance
  • Security disclosure
  • Schema quality
  • Stability
  • Tool coverage
  • Injection markers
  • Destructive annotations
  • Judged manipulation
  • MCP protocol

Does not apply to this package (2)

  • Endpoint SecurityScored on hosted endpoints only. A package has no live endpoint of its own for us to probe.
  • Transport & ReachabilityScored on hosted endpoints only. A package has no live endpoint of its own for us to probe.

The score does not measure everything. What the score does not measure →

Changelog

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.

  • 4 Nov 26 −4
    • Stability: pass → 0.70 functional
  • 29 Oct 26 0
    • Stability: 0.97 → pass security
  • 28 Oct 26 0
    • Stability: pass → 0.97 functional
  • 22 Oct 26 0
    • Stability: 0.97 → pass security
  • 21 Oct 26 0
    • Stability: pass → 0.97 functional
  • 17 Oct 26 +13
    • Known CVEs: unverified → pass ▲ security
    • Stability: 0.80 → pass security
    • Dependency health: unverified → 0.94 ▲ functional
  • 16 Oct 26 −13
    • Known CVEs: pass → unverified ▼ security
    • Dependency health: 0.94 → unverified ▼ functional
    • Stability: pass → 0.80 functional
    • Package version: 1.0.46 → 1.0.47 functional
  • 15 Oct 26 +46
    • Injection markers: unverified → pass ▲ security
    • Stability: unverified → pass ▲ security
    • Tool coverage: unverified → 100 ▲ functional
    • Schema quality: unverified → 100 ▲ functional
    • MCP protocol: unverified → pass ▲ functional
Diagnostics

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 5 Nov 2026 · Analysed npm/sigrank@1.0.47

Provenance Verified

A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.

Result Verified
Ecosystem npm
Reason Verified
Discovered via Registry attestation endpoint
Source repo SunrisesIllNeverSee/sigrank-mcp
Certificate issuer https://token.actions.githubusercontent.com
Certificate SAN https://github.com/SunrisesIllNeverSee/sigrank-mcp/.github/workflows/publish.yml@refs/heads/main
Rekor log index 3275394198
Predicate type SLSA build provenance https://slsa.dev/provenance/v1
Subject digest sha512:ea00a3a5c8db6165e57a9b39fd39586cbfe58017d36297ddfb7599ff52781a0272cacb1f48a3a6f238477fbbb17162100405184efff0aaba0286d0ce4

Background: How many MCP packages publish verified provenance →

Dependencies 29 packages
Packages resolved 29
Stale 4
No linked repository 1
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 25 exposed · ~5,613 tokens

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 →

Tool Tokens
diagnose_cascade ~206

Analyzes your token cascade and diagnoses where you're leaking efficiency. Takes your 4 pillars (input/output/cacheCreate/cacheRead) and produces a ranked list of efficiency leaks with severity (critical/warning/info), findings, and recommendations. Checks: cache leverage (are you rereading what you wrote?), velocity (are you generating enough output per input?), SNR (is your signal drowning in noise?), cache creation ratio (are you over-committing?), input bloat (is fresh input too high?), and 10xDEV (is the full cascade compounding?). Each finding includes an estimated Υ impact. Pure local math — no network, no submission. Use this BEFORE simulate_change to understand what's wrong, then use simulate_change to test fixes. Accepts the same input formats as rank_paste (JSON or 4 whitespace numbers).

NameTypeReqDescription
textstringyesToken pillars — ccusage JSON or "input output cacheCreate cacheRead" (same format as rank_paste).
NameTypeReqDescription
cascadeobject––
diagnosisarray–Ranked list of efficiency leaks found, worst first
pillarsobject–The 4 raw token pillars
summarystring–One-line summary of the operator's cascade health

No examples provided.

discover_peers ~213

Discovers mentors, peers, and complementary operators for YOUR operator on the SigRank leaderboard. Uses your enrolled device identity — no codename needed. Finds operators you should learn from: (1) Mentors — 1-2 class tiers above you with similar cascade shapes, including the specific pillar delta that explains the yield gap (e.g. '12× your cache reads'). (2) Peers — same class tier, ranked by yield proximity. (3) Complementary — operators whose strength is your weakness. Use this after submit_verified to find who to learn from, then chain into self_improve with the mentor's pillar deltas as context. Requires enrollment (npx sigrank-mcp enroll). Intent: DISCOVER_PEERS.

NameTypeReqDescription
ninteger–Number of operators to return per category (default: 5, max: 20).
platformstring–Filter peers by platform (default: your operator's primary platform). Use 'all' to search across all platforms.
NameTypeReqDescription
complementaryarray–Operators whose strength maps to your weakness
ctastring––
mentorsarray–Operators 1-2 class tiers above you with similar cascade shapes, including pillar deltas
peersarray–Operators in your class tier, ranked by yield proximity
summarystring–One-line summary of findings
your_profileobject–Your operator's current profile on the board

No examples provided.

enroll ~198

Bind THIS device to your SigRank operator so your signed token runs cascade to the live board. Paste the key from signalaf.com → Settings → "New key" (or "Generate connect code"). On first run it generates + stores a local ed25519 keypair (~/.sigrank-mcp/identity.json); only the PUBLIC key is ever sent. By enrolling you agree to the SignalAF Terms of Service (signalaf.com/terms) and Privacy Policy (signalaf.com/privacy). Need a new key? Click "New key" at signalaf.com → Settings, then paste it here.

NameTypeReqDescription
codestringyesthe key / connect code (SIGR-XXXXX-XXXXX-XXXXX) from Settings → New key (or Generate connect code)
device_labelstring–optional label for this device (default: sigrank <version> · <platform>; hostnames are never sent unless you pass a label yourself)
NameTypeReqDescription
codenamestring–Operator codename if enrolled
device_idstring–Local device ID
operator_idstring–Operator ID if enrolled
reasonstring–Error reason if status is error
statusstring–Enrollment result
trust_statusstring–Trust level of the device

No examples provided.

get_leaderboard ~228

Fetches the live public SigRank leaderboard from signalaf.com. Reads all ranked operators sorted by yield (Υ = Cache Reads × Output / Input²) and returns an array of operator summaries. Each entry contains: codename (public display name), yield (Υ, the headline efficiency metric), leverage ratio (Cr/I = cache reads divided by input), velocity (O/I = output divided by input), class tier (one of 24 experience stages: 8 tiers × 3 sub-stages, e.g. ARCH+ I, REFINER II, IGNITER III), and rank position (integer, 1-based). Returns an empty array if no operators have submitted yet. Use this to see where operators stand overall, to find specific codenames for get_operator lookups, or to display the current rankings. Do NOT use this to check your own rank if you already know your codename — use get_operator instead for a single-operator profile with per-window breakdowns. After calling this, follow up with get_operator to get detailed metrics for any operator of interest.

Input schema present but exposes no named parameters.

NameTypeReqDescription
operatorsarray–Array of ranked operators sorted by yield

No examples provided.

get_operator ~293

Fetches one operator's live profile from the SigRank board by their codename. Reads the operator's current submission data from signalaf.com and returns their detailed metrics: yield (Υ), leverage ratio (Cr/I), velocity (O/I), class tier (one of 24 experience stages: 8 tiers × 3 sub-stages, e.g. ARCH+ I, REFINER II, IGNITER III), rank position (integer, 1-based), and per-window breakdowns for each time range (7d, 30d, 90d, all-time) with the four canonical pillars (input, output, cacheCreate, cacheRead) per window. Returns an error if the codename is not found on the board. Use this to look up any operator who has submitted to the board — codenames are public and visible on the leaderboard. Do NOT use this to browse all operators — use get_leaderboard for that. After calling this, you can use simulate_change to model what would happen if the operator adjusted their token mix.

NameTypeReqDescription
codenamestringyesThe operator's public codename as shown on the SigRank leaderboard. Case-insensitive — "Ghost Falcon" and "ghost falcon" are equivalent. Must match a codename that exists on the board; returns an err…
NameTypeReqDescription
batchedobject–Submission-based rolled-forward totals (never decrease when platforms delete old logs). Present when the operator has submission history.
classstring––
codenamestring–Operator display name
leveragenumber–Cr/I ratio
rankinteger–1-based rank position
velocitynumber–O/I ratio
windowsarray–Per-window breakdowns (7d, 30d, 90d, all-time)
yield_number–Υ Yield metric

No examples provided.

get_sigrank_standard_record ~200

Build Upsilon's portable sigrank/0.1-draft compatibility record from available token telemetry. Input and output are required; unavailable cache telemetry remains null. Computes the canonical cascade locally through token-cascade and returns Yield, Leverage, Velocity, SNR, and 10xDEV. Upsilon is the measurement product; SigRank is the public leaderboard. No data is submitted or persisted.

NameTypeReqDescription
cache_readinteger|null–Cache-read tokens, or null when unavailable.
cache_writeinteger|null–Cache-write / cache-creation tokens, or null when unavailable.
inputintegeryesFresh input tokens.
modelstring–Optional model identifier.
outputintegeryesOutput tokens.
providerstring–Optional provider identifier.
timestampstring–Optional ISO-8601 timestamp. Defaults to the current time.
toolstring–Optional tool/client identifier.
NameTypeReqDescription
metricsobjectyes–
protocolobjectyes–
sourceobjectyes–
spec–yesLegacy wire identifier. Resolves to TTEOP tteop/0.1-draft.
spec_status–yesIndicates this spec identifier is a legacy alias, not a current protocol.
telemetryobjectyes–
timestampstringyesISO-8601 record timestamp.
warningsarrayyes–

No examples provided.

rank_paste ~425

Computes the SigRank yield cascade from a paste of token counts. Parses the input, runs the full cascade math locally (no network calls), and returns: yield (Υ, the headline efficiency metric, Υ = Cache Reads × Output / Input²), snr (signal-to-noise ratio), leverage (Cr/I = cache reads divided by input), velocity (O/I = output divided by input), dev10x (10xDEV score), class (operator experience stage — 24 stages = 8 tiers × 3 sub-stages I/II/III, e.g. ARCH+ I, REFINER II, IGNITER III, or UNCLASSED for empty input), mode (detected working mode), and a deterministic prose "card" summarizing the result in plain English. Accepts two input formats: (1) JSON object {"input":N,"output":N,"cacheCreate":N,"cacheRead":N} or (2) four whitespace-separated numbers in order: input output cacheCreate cacheRead. Returns an error if the input is malformed or has negative values. Use this for a quick one-off ranking without submitting to the board. Do NOT use this to submit your score — use submit_paste instead, which both ranks and publishes. Do NOT use this if you want to rank all four time windows at once — use rank_windows for that. After calling this, use submit_paste to publish the result if you want to appear on the leaderboard.

NameTypeReqDescription
textstringyesToken counts to rank. Two formats accepted: (1) JSON object {"input":N,"output":N,"cacheCreate":N,"cacheRead":N} where all values are non-negative integers, or (2) four whitespace-separated numbers i…
NameTypeReqDescription
cardstring–Deterministic prose summary of the cascade result
classstringyesOperator class tier (dev10x taxonomy)
dev10xnumber–10xDEV score (log10 of the cascade product)
leveragenumber–Cr/I — cache reads divided by input
modeobject–Detected working mode (BUILD/EDIT/DEBUG/MAINTAIN/IDLE) + confidence
pillarsobject–The four raw token pillars the cascade was computed from
snrnumber–Signal-to-noise ratio
velocitynumber–O/I — output divided by input
warningsarray–Parse or data warnings if any
yieldnumberyesΥ Yield — the headline efficiency metric (Cache Reads × Output / Input²)

No examples provided.

rank_windows ~285

Rank all four time windows (7d/30d/90d/all-time) in one call from a dashboard paste — paste the full table from ccusage, tokscale, or the Claude Max usage dashboard and get the cascade (Υ, SNR, Leverage, Velocity, 10xDEV, class, card) for each window. Each window is parsed and scored independently. Named keys required (input/output/cacheCreate/cacheRead); positional order is NOT safe here (dashboards list cache_read before cache_create — see WINDOWED_PROFILES gotcha). Omit windows you don't have — partial input is allowed (1–4 windows). Does NOT submit to the board; use tokenpull_submit for a local zero-paste preview, or submit_verified to publish via the enrolled-device path.

NameTypeReqDescription
30dstring–ccusage/tokscale paste or JSON for the 30-day window (optional)
7dstring–ccusage/tokscale paste or JSON for the 7-day window (optional)
90dstring–ccusage/tokscale paste or JSON for the 90-day window (optional)
allstring–ccusage/tokscale paste or JSON for the all-time window (optional)
source_toolstring–which token reader produced the paste (for cross-tool variance tracking)
NameTypeReqDescription
windowsarray–Cascade results per window

No examples provided.

self_improve ~367

Runs the full self-improvement cycle in one call: (1) gets your current token pillars — either from the provided text or by running tokenpull on your local logs, (2) diagnoses where you're leaking efficiency (diagnose_cascade), (3) generates ranked improvement suggestions (suggest_improvements), (4) simulates the top suggestion (simulate_change), and (5) returns the complete cycle: diagnosis + suggestions + the simulated impact of the best change. This is the 'one-click optimize' tool — call it at the end of a session to see what to improve next time. If you provide pillars in `text`, it skips the tokenpull step. If you omit `text`, it runs tokenpull first (requires local ccusage logs). Pure local math — no network, no submission. The `scope` parameter adds mode detection (BUILD/EDIT/DEBUG/MAINTAIN/IDLE) and scoped analysis: 'daily' (default — current behavior + mode), 'weekly' (compound into weekly snapshots + report artifact), 'trend' (30d/90d trajectory analysis).

NameTypeReqDescription
scopestring–Analysis scope: "daily" (default — current behavior + mode detection), "weekly" (compound daily rows into weekly snapshots + report artifact with badges), "trend" (30d/90d trajectory + phase patterns…
textstring–Optional: token pillars — ccusage JSON or "input output cacheCreate cacheRead". If omitted, runs tokenpull to get current pillars from local logs.
windowstring–Which time window to pull when running tokenpull (default: 30d). Ignored if `text` is provided.
NameTypeReqDescription
advicestring–Advice for next session (daily scope)
assessmentstring–One-line assessment for daily scope
best_simulationobject–Simulated result of the top suggestion
current_cascadeobject––
cycle_summarystring–One-line summary of the full cycle
diagnosisarray–Efficiency leaks found (from diagnose_cascade)
modeobject–Detected mode { mode, confidence } — present when scope is daily/weekly/trend
pillarsobject–The 4 raw token pillars used
quality_scorenumber–Yield relative to mode expectation (daily scope)
reportobject–Weekly report artifact (weekly scope)
suggestionsarray–Ranked improvements (from suggest_improvements)
trendobject–Trend analysis (trend scope)

No examples provided.

simulate_change ~272

The first PRESCRIPTIVE SigRank tool — 'what if I changed my token mix?' Takes your current 4 pillars (input/output/cacheCreate/cacheRead) and one or more proposed changes, runs the canonical cascade on BOTH the current and simulated values, and returns the exact Υ Yield delta, class change, and per-metric diffs. This is the 'show me the payoff before I do the work' primitive: no network, no submission, pure local math. Use it to answer 'would increasing my cache-read by 50k tokens actually move my class?' before you change your workflow. Accepts the current pillars as JSON or 4 numbers (same as rank_paste) plus a `changes` object with any of the 4 pillar names mapped to new absolute values OR relative deltas (e.g. {cacheRead: '+50000'} or {input: 800000}).

NameTypeReqDescription
changesobjectyesProposed changes to apply. Keys: input, output, cacheCreate, cacheRead. Values are either absolute numbers (replace) or strings starting with +/- for relative deltas (add/subtract). Omitted pillars a…
textstringyesCurrent token pillars — ccusage JSON or "input output cacheCreate cacheRead" (same format as rank_paste).
NameTypeReqDescription
class_changestring–Class tier change description
currentobject––
metric_diffsobject–Per-metric before/after diffs
simulatedobject––
yield_deltanumber–Υ Yield change (simulated - current)

No examples provided.

submit_paste ~305

Ranks a paste of token counts locally and shows the cascade result (yield, leverage, velocity, class, card). This is a PREVIEW-ONLY tool — it does not publish to the board. The board's /api/v1/ingest-paste endpoint now requires an authenticated Supabase session, which MCP tools do not carry. To publish to the leaderboard, use submit_verified (which signs and posts to /api/v1/snapshots via the enrolled-device path) or submit directly through the signalaf.com web UI. Use this when you have token counts from ccusage or a dashboard and want to see your score instantly. Do NOT use this if you want to pull your local usage automatically — use tokenpull_submit for the zero-paste flow. Do NOT use this for multi-window dashboard pastes — use rank_windows to rank them first.

NameTypeReqDescription
codenamestring–Operator codename for the ranking card display (e.g. "Ghost Falcon"). Optional — used only for the local preview card, not for board submission.
textstringyesToken counts to rank. Two formats: (1) JSON {"input":N,"output":N,"cacheCreate":N,"cacheRead":N} from ccusage (preferred), or (2) four whitespace-separated numbers: input output cacheCreate cacheRead…
NameTypeReqDescription
previewobject––
reasonstring–Error or skip reason if status is not ok
server_responseobject–Server-side response including new rank if accepted
statusstring–Submission status

No examples provided.

submit_verified ~263

Publish your LOCAL token runs to the SigRank board as a VERIFIED operator — the enrolled, signed path. Reads your pillars (tokenpull), builds the canonical Schema 1.0 snapshot per window, ed25519-signs it with your device key, and POSTs to /api/v1/snapshots. Requires `npx sigrank-mcp enroll` first (a bound device). Only signed submissions from a trusted device rank on the board. Token-only; the private key never leaves your machine. Publishing requires `confirm: true` (ask the user first); pass dry_run:true to inspect the exact signed payload without publishing and without confirm.

NameTypeReqDescription
confirmboolean–REQUIRED to publish: must be true, set only after the user has explicitly approved submitting. Not needed with dry_run:true.
dry_runboolean–build + sign but do NOT publish — returns the exact payload that would be POSTed (token counts only), so you can inspect before submitting
platformstring–source platform (default: claude). 'multi' = combined cascade summed across all locally-detected platforms (needs 2+ active); empty windows are skipped.
windowstring–submit only this window (default: all 4)
NameTypeReqDescription
previewobject––
reasonstring–Error or skip reason if status is not ok
server_responseobject–Server-side response including new rank if accepted
statusstring–Submission status

No examples provided.

suggest_improvements ~187

Generates ranked, simulated improvement suggestions for your token cascade. Takes your 4 pillars, tests multiple improvement strategies (increase cache reads, reduce fresh input, increase output, optimize cache creation), simulates each with the canonical cascade engine, and returns them ranked by Υ yield impact. Each suggestion includes: the action, which pillar to change, how much to change it, the projected Υ after the change, the yield delta, the projected class tier, and a rationale. Also returns the single highest-impact change (best_single_change). Pure local math — no network, no submission. Use this after diagnose_cascade to get actionable next steps, then use simulate_change to fine-tune before committing. Accepts the same input formats as rank_paste.

NameTypeReqDescription
textstringyesToken pillars — ccusage JSON or "input output cacheCreate cacheRead" (same format as rank_paste).
NameTypeReqDescription
best_single_changestring–The single highest-impact change
current_classstring–Current class tier
current_yieldnumber–Current Υ before any changes
suggestionsarray–Ranked recommendations, highest Υ impact first

No examples provided.

tokenpull ~265

Pull your LOCAL token usage from the platform's session logs and rank it across the four windows (7d/30d/90d/all-time) with the cascade — zero paste. Token-only: reads usage counts not message content. The numbers stay on your machine unless you submit them. Some platforms may have partial data (estimated=true when cacheCreate isn't available) or a dataGap note when the log format doesn't expose raw token counts.

NameTypeReqDescription
platformstring–source platform (default: claude). Supported: amp, kimi, qwen, pi, openclaw, droid, codebuff, gemini, copilot, opencode, goose, kilo, hermes, devin, other, omp, proxy, antigravity, grok, zcode, claud…
NameTypeReqDescription
auth_submitobject|null–Present only when submit:true. One of: {status:'received'|'cooldown'|'not_enrolled'|'error', ...}. Null when submit is false (preview only).
cardstring–Deterministic prose summary
cascadeobject––
generatedAtstring–ISO timestamp of the pull
messagesinteger–Number of messages in the watched window
notestring–Reminder that one snapshot is returned per call — re-call to detect changes.
pillarsobject–The four raw token pillars for the watched window
platformstring–Source platform name
poll_interval_snumber–Advisory poll cadence echoed back (does not make the call block)
windowstring–The watched window (watch_tokenpull watches one window per call)

No examples provided.

tokenpull_compare ~150

Pull token usage from ALL four local sources in parallel — tokenpull (JSONL canon), ccusage CLI, token-dashboard SQLite, and tokscale report — and return them side-by-side with delta % vs tokenpull as the baseline. Also computes the cascade (Υ, SNR, Leverage, class) for each source so you can see how each verifier scores. Useful for validating your numbers before submitting, or understanding discrepancies between tools. Claude only for token-dash; codex and others use tokenpull + ccusage + tokscale. Token-only, on-device.

NameTypeReqDescription
platformstring–platform to compare (default: claude). token-dash and App only available for claude.
NameTypeReqDescription
platformstring––
sourcesarray–Side-by-side comparison of each token source

No examples provided.

tokenpull_submit ~387

Pull your LOCAL token usage from session logs and compute the cascade per window — the zero-paste preview flow. Reads the four canonical pillars (input, output, cacheCreate, cacheRead) per window from your local logs and computes yield, leverage, velocity, class, and card. This is a PREVIEW-ONLY tool — it does not publish to the board. The board's /api/v1/ingest-paste endpoint now requires an authenticated Supabase session, which MCP tools do not carry. To publish to the leaderboard, use submit_verified (which signs and posts to /api/v1/snapshots via the enrolled-device path) or submit directly through the signalaf.com web UI. Token-only — no prompt content is read or transmitted.

NameTypeReqDescription
codenamestring–Operator codename for the ranking card display (e.g. "Iron Lotus"). Optional — used only for the local preview card, not for board submission.
platformstring–Source platform to pull from (default: claude). Supported: amp, kimi, qwen, pi, openclaw, droid, codebuff, gemini, copilot, opencode, goose, kilo, hermes, devin, other, omp, proxy, antigravity, grok,…
windowstring–Preview only this time window (default: all 4 windows). Use "7d" for recent activity or "all" for all-time ranking.
NameTypeReqDescription
previewobject––
reasonstring–Error or skip reason if status is not ok
server_responseobject–Server-side response including new rank if accepted
statusstring–Submission status

No examples provided.

tokscale_breakdown ~151

Show a per-model breakdown of your token usage across all platforms detected by tokscale. Models under the threshold (default 1%) are lumped into 'other' to keep the display clean. Useful for seeing which models you actually use per platform (e.g. claude-opus-4-8 76%, claude-sonnet-4-6 11%, other 0.3%). Returns { platform: [{ model, input, output, cacheRead, cacheCreate, pct }] }.

NameTypeReqDescription
thresholdnumber–Models below this fraction of their platform's total tokens are lumped into 'other'. Default 0.01 (1%). Set 0 to see every model.
NameTypeReqDescription
platformsobject–Map of platform name → array of { model, input, output, cacheRead, cacheCreate, pct }

No examples provided.

tokscale_competitive_intel ~249

Competitive intelligence for any AI tool company. Pass a target tool (by tokscale client slug like 'claude', 'codex', 'devin-cli' or canonical platform name like 'devin', 'other') and get: the target's rank by tokens among all detected tools, its full profile (tokens, cost, model mix, cache_read_pct, cost_per_million_tokens, market share), and a head-to-head comparison against every competitor (each competitor's tokens, cost, model_count, share, cost_per_million_tokens). Returns market_totals for context. If the target is not found, lists all detected clients. Use this to benchmark one AI tool against its competitors on this machine. All data is local — this is your own usage, not aggregate market data.

NameTypeReqDescription
targetstringyesThe AI tool to analyze. Accepts a tokscale client slug (e.g. 'claude', 'codex', 'devin-cli', 'copilot') or a canonical platform name (e.g. 'devin', 'claude', 'other'). Case-insensitive. To discover v…
NameTypeReqDescription
competitorsarray–All other detected tools with comparison metrics
errorstring–Present if tokscale is unavailable or target is empty
foundboolean–Whether the target was found in local data
market_totalsobject–Aggregate market context: { tokens, cost, messages, tool_count }
rank_by_tokensinteger–Target's rank among all detected tools by token volume
targetstring–The resolved target slug(s)
target_profileobject–Target's full usage profile with model mix and market share

No examples provided.

tokscale_cost_analysis ~122

Cost analysis per developer per model from your local tokscale data. Returns a per-client × per-model cost breakdown with cost_per_million_tokens, cost_per_message, and share_cost. Includes a per-client cost rollup and totals: total_cost, total_tokens, avg_cost_per_million_tokens, most_expensive_model, cheapest_per_token. Use this to see exactly where your AI spend goes — which tools and models cost the most and which give the best value per token. Do NOT use this for market share — use tokscale_market_share for that.

Input schema present but exposes no named parameters.

NameTypeReqDescription
client_rolluparray–Per-client cost summary with share_cost and cost_per_million_tokens
entriesarray–Per-client×per-model cost rows sorted by cost desc
errorstring–Present if tokscale is unavailable
totalsobject–Aggregate cost totals and extremes

No examples provided.

tokscale_developer_profile ~153

Per-developer usage profile across all 20+ AI tools detected by tokscale on this machine. For each tool: model mix (per-model tokens/cost/messages/performance), token pillars (input/output/cache_read/cache_write/reasoning), cache_read_pct, session count, scan path (redacted to ~), workspace breakdown, and headless support flag. Returns a summary with tool_count, total_cost, dominant_tool. All filesystem paths are redacted (home dir → ~). Use this to understand your full AI tool footprint — which tools you use, which models per tool, and how your usage is distributed. Do NOT use this for cost-only analysis — use tokscale_cost_analysis for that.

Input schema present but exposes no named parameters.

NameTypeReqDescription
errorstring–Present if tokscale is unavailable
summaryobject–Aggregate summary: { tool_count, total_cost, total_tokens, total_messages, avg_cost_per_tool, dominant_tool }
toolsarray–Per-tool profile with model mix, token pillars, session counts, workspace count

No examples provided.

tokscale_device_profile ~121

Device fingerprinting: profiles this machine's AI tool footprint — which AI tools are installed, where their session logs live (paths redacted to ~), how many sessions and messages each has, when the machine was active (daily activity + day-of-week distribution), session concurrency, and longest continuous session. Combines tokscale clients + graph data. All filesystem paths are redacted so no local username leaks. Use this to audit your own machine's AI tool installation and activity pattern. This is local-only — it profiles the current machine, not remote devices.

Input schema present but exposes no named parameters.

NameTypeReqDescription
active_tool_countinteger–Tools whose session path exists on disk
activityobject–Daily activity + day-of-week token distribution
date_rangeobject–{ start, end } of the activity data
errorstring–Present if tokscale is unavailable
installed_tool_countinteger––
installed_toolsarray–Detected AI tools with redacted session paths and message counts
sessionsobject–Session metrics: count, total/longest active time, max concurrent
summaryobject–Cost summary from graph: total_tokens, total_cost, avg_per_day, max_single_day

No examples provided.

tokscale_market_share ~133

Complete AI tool market share analysis from your local tokscale data. Aggregates per-model usage by client (AI tool) and computes each tool's share of total tokens, cost, and messages. Returns each tool ranked by token share, with share_tokens / share_cost / share_messages percentages and a totals rollup. All data is read locally from tokscale's scan of your session logs — no network calls, no PII. Use this to see which AI coding tools dominate your workflow by volume, spend, or activity. Do NOT use this for per-model detail — use tokscale_developer_profile for that.

Input schema present but exposes no named parameters.

NameTypeReqDescription
errorstring–Present if tokscale is unavailable
toolsarray–AI tools ranked by token share, each with { client, label, tokens, cost, messages, model_count, share_tokens, share_cost, share_messages }
totalsobject–Aggregate totals: { tokens, cost, messages, tool_count }

No examples provided.

tokscale_mcp_usage ~106

MCP server usage patterns from your local tokscale data. Reports which MCP servers tokscale detected on this machine, the detection window, and active days in that window. tokscale currently exposes detected MCP servers as a set (not per-session attribution), so the report notes the detection window. Use this to see which MCP servers are active on your machine. If no servers are detected, the response explains that MCP server tracking requires a tokscale version that records per-session MCP attribution.

Input schema present but exposes no named parameters.

NameTypeReqDescription
active_days_in_windowinteger––
detection_windowobject–{ start, end } date range
errorstring–Present if tokscale is unavailable
notestring–Explanation of the MCP server data granularity
server_countinteger––
serversarray–Detected MCP servers: [{ name, detected: true }]

No examples provided.

tokscale_model_trends ~119

Model adoption trends over time from your local tokscale data. Combines monthly aggregates with per-day contribution data to build a model-level adoption timeline: each model's first_seen / last_seen / active_days / tokens / clients, plus a month-by-month adoption curve showing how many new models appeared each month. Returns months[], models[], and adoption_curve[]. Use this to track which AI models you adopted when, and how your model mix evolved over time. Do NOT use this for cost trends — use tokscale_cost_analysis for current cost breakdown.

Input schema present but exposes no named parameters.

NameTypeReqDescription
adoption_curvearray–Per-month new-model count: { month, new_models, new_model_count, total_models }
date_rangeobject–{ start, end } date range of the data
errorstring–Present if tokscale is unavailable
modelsarray–Per-model adoption: { model, first_seen, last_seen, active_days, tokens, cost, messages, client_count, clients }
monthsarray–Per-month aggregates: { month, models, model_count, input, output, cache_read, messages, cost }

No examples provided.

watch_tokenpull ~215

One poll per call: pulls your local token logs and returns the current cascade for the watched window — the tool never blocks or loops. Re-call at your desired cadence to watch for changes (interval_s is advisory only and echoed back as poll_interval_s). With submit:true (and an enrolled device) each call may also sign + publish the watched window to the board, rate-limited to once per 5 min per platform+window; default is preview-only (no submit).

NameTypeReqDescription
interval_snumber–advisory poll cadence in seconds (default: 60, min: 10) — echoed back as poll_interval_s; does not make the call block or loop
platformstring–platform to watch (default: claude)
submitboolean–auto-submit the watched window to the board as a VERIFIED operator each poll (requires `enroll`; default false = preview only)
windowstring–which window to watch (default: 7d — most sensitive to recent activity)
NameTypeReqDescription
auth_submitobject|null–Present only when submit:true. One of: {status:'received'|'cooldown'|'not_enrolled'|'error', ...}. Null when submit is false (preview only).
cardstring–Deterministic prose summary
cascadeobject––
generatedAtstring–ISO timestamp of the pull
messagesinteger–Number of messages in the watched window
notestring–Reminder that one snapshot is returned per call — re-call to detect changes.
pillarsobject–The four raw token pillars for the watched window
platformstring–Source platform name
poll_interval_snumber–Advisory poll cadence echoed back (does not make the call block)
windowstring–The watched window (watch_tokenpull watches one window per call)

No examples provided.

Install

How do I install the SigRank SignalAF — AI Operator Cascade & Leaderboard MCP server?

SigRank SignalAF — AI Operator Cascade & Leaderboard runs locally as an npm package, launched with npx -y sigrank. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

npm · sigrank

# add to Claude Code
claude mcp add sunrisesillneversee-sigrank-mcp -- npx -y sigrank
Common questions

What is the SigRank SignalAF — AI Operator Cascade & Leaderboard MCP server?

SigRank SignalAF — AI Operator Cascade & Leaderboard is an MCP server listed in the public MCP registry as io.github.SunrisesIllNeverSee/sigrank-mcp. SigRank SignalAF on-device scanner, four-token cascade, leaderboard, 25 local tools. This page covers its npm package (sigrank).

Is the SigRank SignalAF — AI Operator Cascade & Leaderboard MCP server safe to use?

SigRank SignalAF — AI Operator Cascade & Leaderboard scores 92 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. 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 SigRank SignalAF — AI Operator Cascade & Leaderboard MCP server expose?

SigRank SignalAF — AI Operator Cascade & Leaderboard exposes 25 tools: rank_paste, get_sigrank_standard_record, get_leaderboard, get_operator, submit_paste, and 20 more. Their descriptions and schemas cost roughly 5,613 tokens of context every time the server is loaded.

Is the SigRank SignalAF — AI Operator Cascade & Leaderboard MCP server still maintained?

SigRank SignalAF — AI Operator Cascade & Leaderboard is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

What licence is the SigRank SignalAF — AI Operator Cascade & Leaderboard MCP server under?

SigRank SignalAF — AI Operator Cascade & Leaderboard declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

What did VerifyMCP test on the SigRank SignalAF — AI Operator Cascade & Leaderboard MCP server?

VerifyMCP ran 16 checks on SigRank SignalAF — AI Operator Cascade & Leaderboard, covering Malware scan, Known CVEs, Install scripts, Dependency health and 12 more. Endpoint Security and Transport & Reachability do not apply to an npm package, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.