Skip to main content
Glama
pineforge-4pass

PineForge-Codegen

Check TradingView parity

check_tradingview_parity
Read-onlyIdempotent

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.

Instructions

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 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: (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).

Input Schema

NameRequiredDescriptionDefault
pineYesThe Pine v6 strategy source TradingView ran (at most 262,144 bytes of UTF-8).
inputsNoPine input overrides (TradingView's Inputs tab), as in backtest_pine.
symbolNoTradingView ticker the backtest ran on, e.g. 'BINANCE:ETHUSDT.P'. Required unless the XLSX states it or you pass bars.
runtimeNoEngine runtime args of list_engine_params (input_tf, script_tf, bar_magnifier, magnifier_samples, magnifier_dist).
syminfoNoThe instrument's own values (qty_step, mintick, pointvalue, ...), as in backtest_pine: they win over what the symbol resolves, and are the whole instrument for a market other than Binance. Without a lot size the run floors nothing and the result warns.
ohlcv_csvNoYour bars as CSV text: header timestamp,open,high,low,close,volume (epoch ms), or TradingView's chart export time,open,high,low,close,Volume (epoch seconds or ISO 8601). At most 67,108,864 characters; use ohlcv_csv_path for more.
range_endNoISO 8601 end of TradingView's range. Default: the export's last row (the result says so).
timeframeNoTradingView resolution of the chart: '1', '5', '15', '60', '240', '1D', '1W', ... Required unless the XLSX states it.
range_startNoISO 8601 date or datetime of the first bar TradingView computed (UTC unless it has an offset). Required unless the XLSX states it.
chart_timezoneNoIANA timezone TradingView printed the trade times in (its chart timezone), e.g. 'Asia/Taipei', 'UTC', 'America/New_York'. Required unless the export states it.
max_mismatchesNoHow many mismatching trades to list (default 10, at most 50); the counts are always complete.
ohlcv_csv_pathNoPath to your bars CSV (same formats as ohlcv_csv, no size limit; same path rules as backtest_pine's ohlcv_csv_path, checked after resolving '..' and symlinks).
strategy_overridesNoTradingView's Properties tab: the 9 strategy() knobs of list_engine_params.
tradingview_tradesYesTradingView's Strategy Tester export: the "List of trades" CSV text, or the XLSX report file base64-encoded (it starts with UEsDB). The CSV needs the columns Trade number, Type, Date and time and a Price column, as TradingView exports them. Limits: 33,554,432 characters as passed; the trade list graded at most 32 MiB of UTF-8 and 400,000 rows; XLSX parts at most 64 MiB each and 128 MiB together decompressed, sheets at most 400,000 rows and 256 columns, the sheets read at most 8,000,000 cells together, at most 2,000,000 shared strings.
magnifier_ohlcv_csvNoOptional 1-minute bars for a declared bar magnifier, in the same formats as ohlcv_csv and with the same 67,108,864-character limit. Cover the first chart bar's open through the last chart bar's close.
magnifier_ohlcv_csv_pathNoPath to optional 1-minute magnifier bars (same formats and path rules as ohlcv_csv_path, no size limit). Pass this or magnifier_ohlcv_csv, not both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.36

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), yet the description still adds substantial behavior: the run and grading execute in a Docker image with no network inside the container, lot/tick size resolution rules and the applied_instrument/warnings reporting, and magnifier-bar fetching rules. These are non-obvious operational traits beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is a dense wall of text carrying provenance detail (byte-identical commit hashes, engine version lineages, 'file identity is not a new native corpus parity result') that does not help an agent select or invoke the tool. Much of it earns its place only marginally.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 16-parameter tool with no output schema, the description is largely complete: it explains the returned tier values, per-check thresholds, matched/unmatched counts, mismatch listing, timezone check, plus applied_instrument and warnings. Only minor gaps remain (e.g. no pagination-size or performance expectations beyond the 100k-bar limit).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema is highly detailed, so the baseline is 3. The description nonetheless adds resolution semantics the schema does not: which inputs become optional when the XLSX states them, how symbol resolves to Binance spot/perp bars, and the precedence of syminfo over resolved instrument values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific verb and resource: 'Check how closely PineForge reproduces a TradingView backtest, trade by trade.' This is clearly distinguishable in function from siblings like backtest_pine. However, it never names or contrasts with the nearest sibling (backtest_pine), leaving the differentiation implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly specifies what to supply (the Pine v6 script plus the TradingView 'List of trades' CSV or XLSX), and states fallback conditions well: 'pass ohlcv_csv or ohlcv_csv_path for any market; without them, BINANCE:<SYMBOL>... bars are fetched.' It also notes XLSX Properties-sheet precedence. It stops short of an explicit when-not-to-use or a direct routing statement against backtest_pine.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.