Skip to main content
Glama
pineforge-4pass

PineForge-Codegen

Check TradingView parity

check_tradingview_parity
Read-onlyIdempotent

Measure how closely PineForge reproduces TradingView backtests by grading Pine v6 trades against a Strategy Tester export. Returns parity tier, matched counts, and mismatches.

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

Input Schema

TableJSON 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.5/5.0
Behavior5/5

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

Annotations only declare the safety profile (readOnly, idempotent, non-destructive, openWorld); the description adds substantial behavior on top: bar-fetch limits (100,000 bars), no quota/history window, the magnifier rule counting 1-minute bars in that limit, an error when an explicit input disagrees with an XLSX Properties value, warning semantics for a missing lot size, lot/tick-size resolution order, and that the run uses the pineforge-release Docker image with no network. This is far beyond what the annotations convey.

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?

Purpose and required inputs are front-loaded, which is good, but the body devolves into a single dense paragraph of semicolon-joined clauses covering lot size, tick size, table fallbacks, and magnifier edge cases. Much of this is edge-case detail that is hard to parse and dilutes the call-critical guidance.

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

Completeness5/5

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

For a 16-parameter tool with no output schema, the description still enumerates the return payload (tier, each check with value/thresholds, matched/unmatched counts, first mismatches with hints, timezone check, applied_instrument, warnings), so an agent knows what comes back. Nothing essential for a correct invocation is missing.

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%, so the baseline is 3, but the description adds cross-parameter semantics the schema does not: syminfo overrides everything ('syminfo gives your own values and goes over all of it'), magnifier bars are counted in the same limit, and a magnifier-declaring script run without magnifier bars warns. It also clarifies the XLSX-vs-explicit-input conflict.

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

Purpose5/5

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

The first sentence gives a specific verb+resource+scope: 'Check how closely PineForge reproduces a TradingView backtest, trade by trade.' This is clearly distinct from backtest_pine (which runs a backtest) and transpile_pine (which converts code), so the agent can route without opening a schema.

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?

It states the required shape of the request (a Pine v6 script plus a TradingView 'List of trades' CSV or base64 XLSX) and routes the bar-source choice ('pass ohlcv_csv or ohlcv_csv_path for any market; without them, BINANCE:<SYMBOL> ...'). However it never explicitly contrasts itself with aligned siblings like backtest_pine or states when not to use it, so it stops short of full when/when-not guidance.

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