Skip to main content
Glama
tedorigawa001

TradingView-MCP

summarize_backtest_ledger

Summarize a backtest ledger by artifact ID, filtering by symbol, direction, and date range to compute net profit factor, break-even cost, and cost headroom for selected trades vs baseline.

Instructions

Summarize a locally registered immutable backtest ledger by SHA-256 artifact ID. Filter exact symbols, direction, and exit timestamps (UTC, from inclusive/to exclusive); group by symbol/year/month. Requires explicit flat round-trip cost in bps. Recomputes PF from trade-level net wins/losses, never averages PFs. Reports sample break-even flat round-trip cost and signed cost headroom for each population; not an execution guarantee or confidence bound. Returns the entire-ledger baseline, selected subset and excluded complement at the same cost, with complete-case common-opportunity deltas. All filters including dates define selection, not the baseline. Missing outcomes remain missing. No chart access, orders, imports, or arbitrary file paths. Register normalized direction-adjusted gross-bps evidence with the local import CLI first. Optional research_id explicitly enables a local append-only slice exploration journal write before returning metrics; it also records automatic period usage for the entire ledger trade envelope, not underlying price lookbacks. Optional usage_access_id with research_id makes period-record retries idempotent; slice call counts still increment. omitting it is explicitly untracked. Recording failure returns an error without metrics. Counts cover recorded calls for this research ID and artifact only, not all searches or independent trials.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNo
fromNo
group_byNonone
directionNo
artifact_idYes
research_idNo
exclude_symbolsNo
include_symbolsNo
usage_access_idNo
round_trip_cost_bpsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.10

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full disclosure burden and succeeds. It explains PF recomputation, baseline/subset/complement outputs, filter selection semantics, missing outcomes, research_id journal side effects, usage_access_id idempotency, recording failure behavior, and the exact scope of call counts.

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

Conciseness4/5

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

The description is long but front-loaded and dense: core action and filters appear first, then requirements, outputs, and side-effect caveats. A few phrases are minimally redundant, but no sentence is filler for a tool this complex.

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 10-parameter tool with no output schema and no annotations, this is remarkably complete. It covers prerequisites, return populations, cost semantics, limitations, and side effects, so an agent can invoke it correctly and interpret results without additional context.

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

Parameters5/5

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

Every schema parameter is effectively explained in prose: artifact_id, round_trip_cost_bps, symbol filters, direction, from/to inclusivity, group_by values, research_id, and usage_access_id. This is especially valuable because the schema description coverage is 0%.

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?

Description opens with a specific verb+resource: 'Summarize a locally registered immutable backtest ledger by SHA-256 artifact ID.' This clearly distinguishes the tool from siblings like get_strategy_trade_ledger and compare_research_evidence, and the filtering/grouping details further pin down its exact function.

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?

Provides solid invocation context: requires the evidence to be locally registered via the import CLI first, requires an explicit round-trip cost, and states what the tool does not do or guarantee. It doesn't explicitly name alternative tools for other use cases, so it stops short of a 5.

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

Install Server

Other Tools