Pineforge Codegen MCP vs Sigrank MCP
A side-by-side look at the Pineforge Codegen MCP and Sigrank MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Pineforge Codegen MCP for finance & fintech work as a local process; choose Sigrank MCP for finance & fintech as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Pineforge Codegen MCP when
- You need dedicated capabilities in the Finance & Fintech domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
- You want tools like
transpile_pine, backtest_pine, backtest_pine_grid.
Choose Sigrank MCP when
- You need dedicated capabilities in the Finance & Fintech domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: other.
- You want tools like
rank_paste, get_sigrank_standard_record, get_leaderboard.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Finance & Fintech | Finance & Fintech |
| Quality signal | 67/100 · Great | 63/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | No auth required | other |
| Pricing | Free | Free |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 7 | 0 |
| Directory activity | 4 views 0 installs 0 upvotes | 3 views 0 installs 0 upvotes |
| Tools | 12 | 25 |
| Full listing | View Pineforge Codegen MCP | View Sigrank MCP |
Tools & capabilities
Pineforge Codegen MCP tools 12
transpile_pineTranspile PineScript v6 source to a C++ translation unit locally, using the pineforge-codegen transpiler bundled in the pineforge-release Docker image. No API key, no network — source never leaves the machine. Returns the generated C++ as text. Use backtest_pine if you also want to run the strategy.backtest_pineRun a real, deterministic backtest of a PineScript v6 strategy — prefer this over estimating its trades or P&L by reasoning, which is unreliable for Pine (series semantics, intrabar fills, and strategy.* order logic do not reproduce from approximation). Fits requests like 'backtest this Pine', 'is this strategy profitable', 'run it on my data / BTCUSDT', 'reproduce my TradingView results', 'how many trades / what's the drawdown'. Transpile a PineScript v6 strategy and run it against an OHLCV CSV via the pineforge-release Docker image on the user's local machine. Fully local — transpile + backtest run in-container; nothing leaves the box, no API key. Optional `inputs` overrides input.*() named values from the Pine source (keys = the second arg of input.*(...) calls, e.g. 'Fast Length'). Optional `overrides` overrides strategy(...) header fields (initial_capital, commission_value, default_qty_value, pyramiding, slippage, default_qty_type, commission_type, process_orders_on_close). Returns the parsed JSON report (summary, trades, applied_inputs, applied_overrides, applied_runtime, elapsed_seconds). The instrument matters: pass `symbol` (a Binance symbol) or `syminfo` (your own qty_step, mintick, ...); a CSV from fetch_binance_ohlcv carries its instrument and needs neither. The lot size is TradingView's own reading for the symbol, from a measured table shipped with this server (Binance's LOT_SIZE.stepSize only for a symbol TradingView does not list; TradingView's usual 0.001 for a listing newer than the table); the tick size and currencies come from Binance's public exchangeInfo (or from the sidecar next to a CSV fetched by fetch_binance_ohlcv). `syminfo` goes over all of it. What was applied is in applied_runtime.syminfo; when the lot grid is unknown, or its lot size is not a TradingView reading, the result has a `warnings` entry. If the report is too large to return inline it is written to report_path and a compact summary (with that path) is returned instead. Use backtest_pine_grid for sweeps.backtest_pine_gridUse when the user wants to optimize, sweep, tune, or compare PineScript parameter values (e.g. 'try fast length 8/12/19', 'find the best commission/qty settings') rather than test a single configuration — for one fixed configuration use backtest_pine. Run a parameter sweep: transpile the Pine source ONCE (locally, in-container), then compile (g++) and backtest that C++ against the OHLCV CSV once per combination in the cartesian product of `inputs` × `overrides` grids. Returns a ranked list of {inputs, overrides, summary, elapsed_seconds} entries sorted by `sort_by` descending, plus the top entry under `best`. Cap: max_combinations (default 64). Takes the same `symbol` / `market` / `syminfo` as backtest_pine and applies the instrument to every combination (the result's `instrument` shows it). The lot size is TradingView's own reading for the symbol, from a measured table shipped with this server (Binance's LOT_SIZE.stepSize only for a symbol TradingView does not list; TradingView's usual 0.001 for a listing newer than the table); the tick size and currencies come from Binance's public exchangeInfo (or from the sidecar next to a CSV fetched by fetch_binance_ohlcv). `syminfo` goes over all of it. Set concurrency > 1 to run backtests in parallel — each docker container has its own startup overhead, so 2-4 is usually plenty.check_tradingview_parityCheck how closely PineForge reproduces a TradingView backtest, trade by trade. Give the Pine v6 script and TradingView's own Strategy Tester export: the "List of trades" CSV, or the XLSX report as base64. PineForge runs the script on the same market and window and grades the two trade lists with the grader behind its recorded parity figures (pineforge-engine v1.2.0 scripts/verify_corpus.py, byte-identical in v1.3.0 and the frozen 1.4.0 candidate). The execution harness run_strategy.py is copied byte-for-byte from frozen engine candidate b3192bfc2f5a24bf4efd6d1d01e01e8fe619dfed; file identity is not a new native corpus parity result. Returns the tier (excellent, strong, moderate, weak, minimal), each check with its value and thresholds, matched and unmatched trade counts, the first mismatches side by side with hints, and a timezone check. Bars: pass ohlcv_csv or ohlcv_csv_path for any market; without them, BINANCE:<SYMBOL> (spot) and BINANCE:<SYMBOL>.P (USDT-M perpetual) bars are fetched from Binance's public API (at most 100,000 bars); any other symbol needs your bars. No quota and no history window beyond that. Scripts declaring use_bar_magnifier=true also fetch 1-minute bars through the last chart bar's close, counted in that limit, on charts the harness magnifies (coarser than 1 minute, at most 1 day) unless runtime.bar_magnifier is false. With your own bars, optionally pass magnifier_ohlcv_csv or magnifier_ohlcv_csv_path; a script that declares the magnifier but runs without one gets a warning that fills inside bars may differ from TradingView's. Settings the XLSX Properties sheet states are used; an explicit input that disagrees with one is an error. The run applies the instrument's lot size and tick size as backtest_pine does, for BINANCE:<SYMBOL> and BINANCE:<SYMBOL>.P. The lot size is TradingView's own reading for the symbol, from a measured table shipped with this server (Binance's LOT_SIZE.stepSize only for a symbol TradingView does not list; TradingView's usual 0.001 for a listing newer than the table); the tick size and currencies come from Binance's public exchangeInfo (or from the sidecar next to a CSV fetched by fetch_binance_ohlcv). `syminfo` gives your own values and goes over all of it. The result's `applied_instrument` shows what was applied, and `warnings` says when no lot size could be found or its lot size is not a TradingView reading. The run and the grading use the pineforge-release Docker image (no network inside the container).fetch_binance_ohlcvFetch OHLCV candles from Binance public API and write a backtest-ready CSV (header: timestamp,open,high,low,close,volume; timestamp = open time in UNIX ms UTC). Supports `spot` and `usdt_perp` (USDT-margined perpetual futures). Requests larger than 1000 bars are paginated automatically. Also records the symbol's instrument in <output_path>.instrument.json (lot size: TradingView's own reading from a measured table shipped with this server, Binance's LOT_SIZE.stepSize for a symbol TradingView does not list, TradingView's usual 0.001 for a listing newer than the table; tick size and currencies from Binance's public exchangeInfo), which backtest_pine and backtest_pine_grid pick up; the result's `instrument` shows what was recorded. The output path must live inside the MCP cwd unless PINEFORGE_ALLOW_ANYWHERE=1.binance_symbolsList/validate symbols available on the Binance public API for OHLCV fetching. Filters: `query` (substring of the symbol), `quote_asset` (e.g. 'USDT'), `base_asset` (e.g. 'BTC'), `status` (e.g. 'TRADING'), `contract_type` (futures only, e.g. 'PERPETUAL'). Results are cached 5 min in process. Free.list_engine_paramsReturns the full catalog of engine knobs accepted by backtest_pine / backtest_pine_grid in two groups: strategy_overrides (the 9 strategy(...) header fields the runtime reads via PINEFORGE_OVERRIDES — initial_capital, pyramiding, slippage, commission_value, commission_type, default_qty_value, default_qty_type, process_orders_on_close, close_entries_rule) and runtime_args (input_tf, script_tf, bar_magnifier, magnifier_samples, magnifier_dist — args to run_backtest_full, NOT part of the strategy() header). Each entry is {key, type, enum?, description}. Does not run the engine. Use this to discover what knobs the engine exposes before issuing a backtest.list_coverage_topicsSTART HERE before writing, porting, or backtesting a Pine v6 strategy on PineForge. PineForge implements a SUBSET of Pine v6, so checking coverage first avoids a strategy that compiles but silently misbehaves vs TradingView. Lists every coverage topic with a one-line status (supported / partial / unsupported / via_transpiler) and summary, plus the legend (note: via_transpiler still works end-to-end; unsupported means refused, not compiling, stopping the run where its value is read, or accepted with no effect) and the coverage version. Statuses describe what a backtest on THIS server can do. Cheap, free, local — no engine run, no I/O. Then drill in with get_coverage_topic for one area's per-feature lists, or check_pine_feature to look up a single identifier.get_coverage_topicReturns the full detail plus the exact supported[], partial[], via_transpiler[] and unsupported[] feature lists for ONE coverage topic id (ids from list_coverage_topics, e.g. 'ta', 'strategy_orders', 'request_security', 'drawing_plotting_alerts'). Use when you are about to work in a feature area and need to know precisely which functions there are implemented vs skipped — e.g. before using request.security, the ta.* library, or strategy risk knobs. Unknown ids return an error marker listing the valid ids. Local, free, no engine run.check_pine_featureAnswer "does PineForge support X?" for a specific Pine v6 identifier or namespace (e.g. 'ta.supertrend', 'alert', 'array.new', 'request.financial'). Use it (a) BEFORE relying on any function you are unsure about while writing a strategy, and (b) to DIAGNOSE a backtest that compiled but behaved wrong or empty — plots, tables and alerts (plot, bgcolor, table, alert) are accepted and produce NO effect, while line, box and label objects are data the strategy can read back. Resolves by exact feature match, then longest namespace prefix, then alias, returning {query, status, topic, note} where status is supported / partial / unsupported / via_transpiler / not_found (via_transpiler = works end-to-end; unsupported = refused, not compiling, stopping the run, or no effect) and the note quotes the catalog entry, which says what THIS server can and cannot do (e.g. request.security on another symbol). Local, free, no engine run.pull_engine_imageRun `docker pull` for the pineforge-release runtime image on the user's machine. Useful before the first backtest_pine call.check_engine_imageCheck whether the local pineforge-release Docker image is up to date with the registry. Compares per-platform manifest digests via `docker manifest inspect --verbose` (no image layers downloaded). Returns up_to_date + recommend_pull. With auto_pull=true, runs `docker pull` in the same call when the local image is stale or missing. Note: this is independent of the MCP server's own version (`@pineforge/backtest-mcp`); the MCP version and the engine image version evolve separately.
Sigrank MCP tools 25
rank_pasteComputes 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.get_sigrank_standard_recordBuild 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.get_leaderboardFetches 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.get_operatorFetches 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.submit_pasteRanks 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.tokenpullPull 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.tokenpull_submitPull 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.rank_windowsRank 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.watch_tokenpullOne 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).tokenpull_comparePull 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.enrollBind 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.submit_verifiedPublish 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.- +13 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Pineforge Codegen MCP
{
"mcpServers": {
"pineforge-4pass-pineforge-codegen-mcp": {
"command": "npx",
"args": [
"-y",
"@pineforge/backtest-mcp"
]
}
}
}
Sigrank MCP
{
"mcpServers": {
"sunrisesillneversee-sigrank-mcp": {
"command": "npx",
"args": [
"-y",
"sigrank"
]
}
}
}
Frequently asked questions
Pineforge Codegen MCP is categorized under Finance & Fintech and uses a local stdio subprocess. Sigrank MCP belongs to Finance & Fintech and uses a local stdio subprocess. Pick Pineforge Codegen MCP for finance & fintech work and Sigrank MCP for finance & fintech.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Pineforge Codegen MCP is listed as free. Auth: no auth required. Sigrank MCP is listed as free. Auth: other. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add pineforge-4pass-pineforge-codegen-mcp and sunrisesillneversee-sigrank-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Pineforge Codegen MCP has a quality signal of 67/100 (Great) with 4 views, 0 installs and 7 GitHub stars. Sigrank MCP has 63/100 (Good) with 3 views, 0 installs and 0 GitHub stars.