Skip to main content
Glama
pineforge-4pass

PineForge-Codegen

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PINEFORGE_IMAGENoEngine image used for transpile + backtestghcr.io/pineforge-4pass/pineforge-engine:latest
PINEFORGE_ALLOW_ANYWHERENoAllow OHLCV paths outside cwd0
PINEFORGE_DOCKER_TIMEOUT_MSNoHard kill for docker pull / docker run120000

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
transpile_pineA

Transpile 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_pineA

Run 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_gridA

Use 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_parityA

Check 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 published parity figures (pineforge-engine v1.2.0 scripts/verify_corpus.py, the same file in v1.3.0). 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: (spot) and BINANCE:.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: and BINANCE:.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_ohlcvA

Fetch 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 .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_symbolsA

List/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_paramsA

Returns 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_topicsA

START 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_topicA

Returns 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_featureA

Answer "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_imageA

Run docker pull for the pineforge-release runtime image on the user's machine. Useful before the first backtest_pine call.

check_engine_imageA

Check 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.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 12 tools

Disambiguation4/5

Most tools have clearly distinct purposes: transpile vs. backtest vs. sweep vs. parity-check are unambiguous, and backtest_pine is explicitly contrasted with backtest_pine_grid. The coverage trio (list_coverage_topics, get_coverage_topic, check_pine_feature) is separated by granularity but still overlaps in the 'does PineForge support X?' space, and pull_engine_image/check_engine_image overlap slightly since check can auto_pull.

Naming Consistency4/5

All names are snake_case, mostly following a verb_noun pattern (check_tradingview_parity, transpile_pine, backtest_pine, fetch_binance_ohlcv, list_coverage_topics, get_coverage_topic, pull_engine_image). The only real deviation is binance_symbols, which is noun-only with no verb, but grouping is otherwise predictable.

Tool Count5/5

12 tools is well-scoped for a Pine transpile/backtest/parity server, with each tool earning its place across transpilation, execution, sweeps, data fetching, coverage discovery, and engine management. No redundant or filler tools.

Completeness4/5

The surface covers the full workflow: find/validate symbols, fetch data, check coverage, transpile, backtest, sweep, and verify TradingView parity, plus engine image management. Minor gaps exist (no way to cancel/abort a long backtest or directly ingest TradingView exports beyond parity-check inputs), but core lifecycle is complete.

Maintenance

ActivityActive
ResponsivenessNo issues