Upsilon — AI Operator Measurement Engine
NPM · SIGRANK · SCANNED SEP 20
Upsilon measurement engine with 25 local tools and SigRank proof access via the sigrank package.
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
- 32 of 114 dependencies flagged as unhealthy (1 deprecated). View diagnostics → Partial
Provenance & Transparency48
- 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
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 10 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 5798 tokens (~193/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 Management62
- Stability check failed: the tool surface changed between 0.17.2 and 1.0.12: 5 tool removals, 0 breaking changes, 10 additions. See how to fix → Fail
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 supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the Upsilon — AI Operator Measurement Engine MCP server?
Upsilon — AI Operator Measurement Engine 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
claude mcp add sunrisesillneversee-sigrank-mcp -- npx -y sigrank
{
"mcpServers": {
"sunrisesillneversee-sigrank-mcp": {
"command": "npx",
"args": [
"-y",
"sigrank"
]
}
}
} {
"servers": {
"sunrisesillneversee-sigrank-mcp": {
"command": "npx",
"args": [
"-y",
"sigrank"
]
}
}
} codex mcp add sunrisesillneversee-sigrank-mcp -- npx -y sigrank
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"sunrisesillneversee-sigrank-mcp": {
"type": "local",
"command": [
"npx",
"-y",
"sigrank"
],
"enabled": true
}
}
} openclaw mcp add sunrisesillneversee-sigrank-mcp --command npx --arg -y --arg sigrank
mcp_servers:
sunrisesillneversee-sigrank-mcp:
command: "npx"
args: ["-y", "sigrank"] {
"McpServers": {
"sunrisesillneversee-sigrank-mcp": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"sigrank"
]
}
}
} assistant mcp add sunrisesillneversee-sigrank-mcp -t stdio -c npx -a -y sigrank
{
"mcpServers": {
"sunrisesillneversee-sigrank-mcp": {
"command": "npx",
"args": [
"-y",
"sigrank"
]
}
}
} 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.
- 19 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 55 to 58.
- 18 Sept 26 −3
No change was recorded against any check on this day. Stability & Change Management went from 75 to 55.
- 17 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 72 to 75.
- 14 Sept 26 +2
- Security disclosure: unverified → pass ▲ functional
- 13 Sept 26 −1
- Security disclosure: pass → unverified ▼ functional
- 12 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 55 to 58.
- 11 Sept 26 −3
No change was recorded against any check on this day. Stability & Change Management went from 75 to 55.
- 10 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 72 to 75.
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/sigrank@1.0.12
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 114 packages
| Packages resolved | 114 |
|---|---|
| Deprecated | 1 |
| Stale | 31 |
| No linked repository | 1 |
| 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 →
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).
| Name | Type | Req | Description |
|---|---|---|---|
| text | string | yes | Token pillars — ccusage JSON or "input output cacheCreate cacheRead" (same format as rank_paste). |
| Name | Type | Req | Description |
|---|---|---|---|
| cascade | object | – | – |
| diagnosis | array | – | Ranked list of efficiency leaks found, worst first |
| pillars | object | – | The 4 raw token pillars |
| summary | string | – | 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.
| Name | Type | Req | Description |
|---|---|---|---|
| n | integer | – | Number of operators to return per category (default: 5, max: 20). |
| platform | string | – | Filter peers by platform (default: your operator's primary platform). Use 'all' to search across all platforms. |
| Name | Type | Req | Description |
|---|---|---|---|
| complementary | array | – | Operators whose strength maps to your weakness |
| cta | string | – | – |
| mentors | array | – | Operators 1-2 class tiers above you with similar cascade shapes, including pillar deltas |
| peers | array | – | Operators in your class tier, ranked by yield proximity |
| summary | string | – | One-line summary of findings |
| your_profile | object | – | Your operator's current profile on the board |
No examples provided.
enroll ~181
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.
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | the key / connect code (SIGR-XXXXX-XXXXX-XXXXX) from Settings → New key (or Generate connect code) |
| device_label | string | – | optional label for this device (default: hostname · agent version) |
| Name | Type | Req | Description |
|---|---|---|---|
| codename | string | – | Operator codename if enrolled |
| device_id | string | – | Local device ID |
| operator_id | string | – | Operator ID if enrolled |
| reason | string | – | Error reason if status is error |
| status | string | – | Enrollment result |
| trust_status | string | – | 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.
| Name | Type | Req | Description |
|---|---|---|---|
| operators | array | – | 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.
| Name | Type | Req | Description |
|---|---|---|---|
| codename | string | yes | The 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… |
| Name | Type | Req | Description |
|---|---|---|---|
| batched | object | – | Submission-based rolled-forward totals (never decrease when platforms delete old logs). Present when the operator has submission history. |
| class | string | – | – |
| codename | string | – | Operator display name |
| leverage | number | – | Cr/I ratio |
| rank | integer | – | 1-based rank position |
| velocity | number | – | O/I ratio |
| windows | array | – | Per-window breakdowns (7d, 30d, 90d, all-time) |
| yield_ | number | – | Υ Yield metric |
No examples provided.
get_sigrank_standard_record ~203
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 @sigrank/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.
| Name | Type | Req | Description |
|---|---|---|---|
| cache_read | integer|null | – | Cache-read tokens, or null when unavailable. |
| cache_write | integer|null | – | Cache-write / cache-creation tokens, or null when unavailable. |
| input | integer | yes | Fresh input tokens. |
| model | string | – | Optional model identifier. |
| output | integer | yes | Output tokens. |
| provider | string | – | Optional provider identifier. |
| timestamp | string | – | Optional ISO-8601 timestamp. Defaults to the current time. |
| tool | string | – | Optional tool/client identifier. |
| Name | Type | Req | Description |
|---|---|---|---|
| metrics | object | yes | – |
| source | object | yes | – |
| spec | – | yes | SigRank specification version. |
| telemetry | object | yes | – |
| timestamp | string | yes | ISO-8601 record timestamp. |
| warnings | array | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| text | string | yes | Token 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… |
| Name | Type | Req | Description |
|---|---|---|---|
| card | string | – | Deterministic prose summary of the cascade result |
| class | string | yes | Operator class tier (dev10x taxonomy) |
| dev10x | number | – | 10xDEV score (log10 of the cascade product) |
| leverage | number | – | Cr/I — cache reads divided by input |
| mode | object | – | Detected working mode (BUILD/EDIT/DEBUG/MAINTAIN/IDLE) + confidence |
| pillars | object | – | The four raw token pillars the cascade was computed from |
| snr | number | – | Signal-to-noise ratio |
| velocity | number | – | O/I — output divided by input |
| warnings | array | – | Parse or data warnings if any |
| yield | number | yes | Υ 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.
| Name | Type | Req | Description |
|---|---|---|---|
| 30d | string | – | ccusage/tokscale paste or JSON for the 30-day window (optional) |
| 7d | string | – | ccusage/tokscale paste or JSON for the 7-day window (optional) |
| 90d | string | – | ccusage/tokscale paste or JSON for the 90-day window (optional) |
| all | string | – | ccusage/tokscale paste or JSON for the all-time window (optional) |
| source_tool | string | – | which token reader produced the paste (for cross-tool variance tracking) |
| Name | Type | Req | Description |
|---|---|---|---|
| windows | array | – | 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).
| Name | Type | Req | Description |
|---|---|---|---|
| scope | string | – | 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… |
| text | string | – | Optional: token pillars — ccusage JSON or "input output cacheCreate cacheRead". If omitted, runs tokenpull to get current pillars from local logs. |
| window | string | – | Which time window to pull when running tokenpull (default: 30d). Ignored if `text` is provided. |
| Name | Type | Req | Description |
|---|---|---|---|
| advice | string | – | Advice for next session (daily scope) |
| assessment | string | – | One-line assessment for daily scope |
| best_simulation | object | – | Simulated result of the top suggestion |
| current_cascade | object | – | – |
| cycle_summary | string | – | One-line summary of the full cycle |
| diagnosis | array | – | Efficiency leaks found (from diagnose_cascade) |
| mode | object | – | Detected mode { mode, confidence } — present when scope is daily/weekly/trend |
| pillars | object | – | The 4 raw token pillars used |
| quality_score | number | – | Yield relative to mode expectation (daily scope) |
| report | object | – | Weekly report artifact (weekly scope) |
| suggestions | array | – | Ranked improvements (from suggest_improvements) |
| trend | object | – | 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}).
| Name | Type | Req | Description |
|---|---|---|---|
| changes | object | yes | Proposed 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… |
| text | string | yes | Current token pillars — ccusage JSON or "input output cacheCreate cacheRead" (same format as rank_paste). |
| Name | Type | Req | Description |
|---|---|---|---|
| class_change | string | – | Class tier change description |
| current | object | – | – |
| metric_diffs | object | – | Per-metric before/after diffs |
| simulated | object | – | – |
| yield_delta | number | – | Υ 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.
| Name | Type | Req | Description |
|---|---|---|---|
| codename | string | – | Operator codename for the ranking card display (e.g. "Ghost Falcon"). Optional — used only for the local preview card, not for board submission. |
| text | string | yes | Token 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… |
| Name | Type | Req | Description |
|---|---|---|---|
| preview | object | – | – |
| reason | string | – | Error or skip reason if status is not ok |
| server_response | object | – | Server-side response including new rank if accepted |
| status | string | – | Submission status |
No examples provided.
submit_verified ~216
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. Pass dry_run:true to inspect the exact signed payload without publishing.
| Name | Type | Req | Description |
|---|---|---|---|
| dry_run | boolean | – | build + sign but do NOT publish — returns the exact payload that would be POSTed (token counts only), so you can inspect before submitting |
| platform | string | – | source platform (default: claude). 'multi' = combined cascade summed across all locally-detected platforms (needs 2+ active); empty windows are skipped. |
| window | string | – | submit only this window (default: all 4) |
| Name | Type | Req | Description |
|---|---|---|---|
| preview | object | – | – |
| reason | string | – | Error or skip reason if status is not ok |
| server_response | object | – | Server-side response including new rank if accepted |
| status | string | – | 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.
| Name | Type | Req | Description |
|---|---|---|---|
| text | string | yes | Token pillars — ccusage JSON or "input output cacheCreate cacheRead" (same format as rank_paste). |
| Name | Type | Req | Description |
|---|---|---|---|
| best_single_change | string | – | The single highest-impact change |
| current_class | string | – | Current class tier |
| current_yield | number | – | Current Υ before any changes |
| suggestions | array | – | Ranked recommendations, highest Υ impact first |
No examples provided.
tokenpull ~258
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.
| Name | Type | Req | Description |
|---|---|---|---|
| platform | string | – | source platform (default: claude). Supported: amp, kimi, qwen, pi, openclaw, droid, codebuff, gemini, copilot, opencode, goose, kilo, hermes, devin, other, omp, proxy, claude, codex, grok, multi. 'mu… |
| Name | Type | Req | Description |
|---|---|---|---|
| auth_submit | object|null | – | Present only when submit:true. One of: {status:'received'|'cooldown'|'not_enrolled'|'error', ...}. Null when submit is false (preview only). |
| card | string | – | Deterministic prose summary |
| cascade | object | – | – |
| generatedAt | string | – | ISO timestamp of the pull |
| messages | integer | – | Number of messages in the watched window |
| note | string | – | Reminder that one snapshot is returned per call — re-call to detect changes. |
| pillars | object | – | The four raw token pillars for the watched window |
| platform | string | – | Source platform name |
| poll_interval_s | number | – | Advisory poll cadence echoed back (does not make the call block) |
| window | string | – | 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.
| Name | Type | Req | Description |
|---|---|---|---|
| platform | string | – | platform to compare (default: claude). token-dash and App only available for claude. |
| Name | Type | Req | Description |
|---|---|---|---|
| platform | string | – | – |
| sources | array | – | Side-by-side comparison of each token source |
No examples provided.
tokenpull_submit ~380
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.
| Name | Type | Req | Description |
|---|---|---|---|
| codename | string | – | Operator codename for the ranking card display (e.g. "Iron Lotus"). Optional — used only for the local preview card, not for board submission. |
| platform | string | – | 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, claude, codex, gro… |
| window | string | – | Preview only this time window (default: all 4 windows). Use "7d" for recent activity or "all" for all-time ranking. |
| Name | Type | Req | Description |
|---|---|---|---|
| preview | object | – | – |
| reason | string | – | Error or skip reason if status is not ok |
| server_response | object | – | Server-side response including new rank if accepted |
| status | string | – | 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 }] }.
| Name | Type | Req | Description |
|---|---|---|---|
| threshold | number | – | Models below this fraction of their platform's total tokens are lumped into 'other'. Default 0.01 (1%). Set 0 to see every model. |
| Name | Type | Req | Description |
|---|---|---|---|
| platforms | object | – | 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.
| Name | Type | Req | Description |
|---|---|---|---|
| target | string | yes | The 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… |
| Name | Type | Req | Description |
|---|---|---|---|
| competitors | array | – | All other detected tools with comparison metrics |
| error | string | – | Present if tokscale is unavailable or target is empty |
| found | boolean | – | Whether the target was found in local data |
| market_totals | object | – | Aggregate market context: { tokens, cost, messages, tool_count } |
| rank_by_tokens | integer | – | Target's rank among all detected tools by token volume |
| target | string | – | The resolved target slug(s) |
| target_profile | object | – | 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.
| Name | Type | Req | Description |
|---|---|---|---|
| client_rollup | array | – | Per-client cost summary with share_cost and cost_per_million_tokens |
| entries | array | – | Per-client×per-model cost rows sorted by cost desc |
| error | string | – | Present if tokscale is unavailable |
| totals | object | – | 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.
| Name | Type | Req | Description |
|---|---|---|---|
| error | string | – | Present if tokscale is unavailable |
| summary | object | – | Aggregate summary: { tool_count, total_cost, total_tokens, total_messages, avg_cost_per_tool, dominant_tool } |
| tools | array | – | Per-tool profile with model mix, token pillars, session counts, workspaces |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| active_tool_count | integer | – | Tools whose session path exists on disk |
| activity | object | – | Daily activity + day-of-week token distribution |
| date_range | object | – | { start, end } of the activity data |
| error | string | – | Present if tokscale is unavailable |
| installed_tool_count | integer | – | – |
| installed_tools | array | – | Detected AI tools with redacted session paths and message counts |
| sessions | object | – | Session metrics: count, total/longest active time, max concurrent |
| summary | object | – | 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.
| Name | Type | Req | Description |
|---|---|---|---|
| error | string | – | Present if tokscale is unavailable |
| tools | array | – | AI tools ranked by token share, each with { client, label, tokens, cost, messages, model_count, share_tokens, share_cost, share_messages } |
| totals | object | – | 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.
| Name | Type | Req | Description |
|---|---|---|---|
| active_days_in_window | integer | – | – |
| detection_window | object | – | { start, end } date range |
| error | string | – | Present if tokscale is unavailable |
| note | string | – | Explanation of the MCP server data granularity |
| server_count | integer | – | – |
| servers | array | – | 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.
| Name | Type | Req | Description |
|---|---|---|---|
| adoption_curve | array | – | Per-month new-model count: { month, new_models, new_model_count, total_models } |
| date_range | object | – | { start, end } date range of the data |
| error | string | – | Present if tokscale is unavailable |
| models | array | – | Per-model adoption: { model, first_seen, last_seen, active_days, tokens, cost, messages, client_count, clients } |
| months | array | – | 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).
| Name | Type | Req | Description |
|---|---|---|---|
| interval_s | number | – | advisory poll cadence in seconds (default: 60, min: 10) — echoed back as poll_interval_s; does not make the call block or loop |
| platform | string | – | platform to watch (default: claude) |
| submit | boolean | – | auto-submit the watched window to the board as a VERIFIED operator each poll (requires `enroll`; default false = preview only) |
| window | string | – | which window to watch (default: 7d — most sensitive to recent activity) |
| Name | Type | Req | Description |
|---|---|---|---|
| auth_submit | object|null | – | Present only when submit:true. One of: {status:'received'|'cooldown'|'not_enrolled'|'error', ...}. Null when submit is false (preview only). |
| card | string | – | Deterministic prose summary |
| cascade | object | – | – |
| generatedAt | string | – | ISO timestamp of the pull |
| messages | integer | – | Number of messages in the watched window |
| note | string | – | Reminder that one snapshot is returned per call — re-call to detect changes. |
| pillars | object | – | The four raw token pillars for the watched window |
| platform | string | – | Source platform name |
| poll_interval_s | number | – | Advisory poll cadence echoed back (does not make the call block) |
| window | string | – | The watched window (watch_tokenpull watches one window per call) |
No examples provided.
What is the Upsilon — AI Operator Measurement Engine MCP server?
Upsilon — AI Operator Measurement Engine is an MCP server listed in the public MCP registry as io.github.SunrisesIllNeverSee/sigrank-mcp. Upsilon measurement engine with 25 local tools and SigRank proof access via the sigrank package. This page covers its npm package (sigrank).
Is the Upsilon — AI Operator Measurement Engine MCP server safe to use?
Upsilon — AI Operator Measurement Engine scores 80 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 Upsilon — AI Operator Measurement Engine MCP server expose?
Upsilon — AI Operator Measurement Engine 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,538 tokens of context every time the server is loaded.
Is the Upsilon — AI Operator Measurement Engine MCP server still maintained?
Upsilon — AI Operator Measurement Engine 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.
What licence is the Upsilon — AI Operator Measurement Engine MCP server under?
Upsilon — AI Operator Measurement Engine declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.