Skip to main content
Glama

FinBridge

Saved Backtests & Factor Studies (FinBridge)

get_backtest_runs
Read-only

List, open, re-check or delete the backtest and factor runs saved for your account. Every backtest_portfolio and analyze_factors call is stored automatically with the exact inputs it ran on, the headline numbers, and the data vintage (the market's latest price session at the time).

Why re-check matters: in this dataset the same inputs can give a different answer later. Split adjustments get applied (225 US ETFs on 2026-09-04), financials get restated, delistings get flagged — all of which rewrite history retroactively. action='recheck' re-runs the stored inputs against today's data and reports what moved, which is the only way to notice that kind of drift.

Args:

  • action: 'list' (default) | 'get' | 'recheck' | 'delete'

  • run_id: required for get / recheck / delete

  • kind: 'portfolio' | 'factors' — filter for list

  • limit: 1-50 for list (default 20)

  • trades: include the trade log in 'get' (default false). A portfolio run stores its initial purchase, every rebalance delta and any delisting liquidation; factor studies have no trades.

Returns:

  • list: {runs: [{run_id, kind, label, market, range, data_as_of, created_at, headline}]}

  • get: {run: {...}, params, summary, trades?}

  • recheck: {run, stored, current, changed: [{key, before, after, delta}], data_as_of: {stored, now}, verdict}

  • delete: {deleted: true}

Use when: comparing runs you made earlier, auditing which trades a portfolio backtest actually made, or checking whether a saved result still holds after nightly ingests. Errors: no account on this key -> {error} rather than a failure; an unknown run_id -> {error}. Notes: Runs are per account and the newest 200 are kept. Only inputs and headline numbers are stored, never the full response — the inputs are what make a run reproducible.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoFilter the list by run type
limitNoHow many runs to list (default 20)
actionNoWhat to do (default 'list')list
run_idNoRun id — required for get / recheck / delete
tradesNoInclude the trade log in 'get' (default false)
response_formatNo'markdown' for tables, 'json' for compact machine-readable outputmarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
runNo
runsNo
countNo
errorNo
rangeNo
actionNo
paramsNo
run_idNo
storedNo
tradesNo
changedNo
currentNo
deletedNo
summaryNo
verdictNo
data_as_ofNo
trade_countNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A3.6/5.0
Behavior1/5

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

The annotations declare readOnlyHint: true, yet the description explicitly supports action='delete' and says the tool can 'delete' saved runs — a direct contradiction. Even though the description offers useful behavioral detail about rechecks, stored inputs, per-account retention and error behavior, the contradiction makes the safety profile untrustworthy and forces score 1.

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?

Well-structured with clear sections: overview, rationale, Args, Returns, Use when, Errors, Notes. Though long, the content is information-dense and front-loaded with purpose; the main redundancy is the Args block partially duplicating the input schema.

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?

The description covers the four actions, run_id requirements, response shapes, error behavior, per-account storage limits, and the recheck/drift use case. It also leverages the high-coverage input schema and output schema, making this a complete definition for an agent to call the tool correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3 and the schema already documents all six parameters. The description restates the essentials for action, run_id and kind, but adds no new meaning beyond the schema and omits exposure of limit, trades and response_format in its Args section.

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 description opens with a specific multi-verb statement — 'List, open, re-check or delete the backtest and factor runs saved for your account.' It names both the operations and the resource, and explicitly ties the stored runs to backtest_portfolio and analyze_factors, which clearly separates this tool from those execution-oriented siblings.

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?

An explicit 'Use when:' block lists three concrete scenarios: comparing prior runs, auditing trades from a backtest, and checking whether saved results still hold after nightly ingests. It stops short of naming alternatives or explaining when not to use the tool, so it lacks the full when/when-not contrast.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

Most tools have clearly distinct resource+action targets, and the overlapping screen_* tools are thoroughly cross-referenced with 'use screen_X instead' guidance. Minor ambiguity exists between get_disclosure_feed, get_dart_filings, and get_dart_major_events, which all surface KR filings from different angles but remain distinguishable.

Naming Consistency5/5

Every tool follows a consistent verb_noun snake_case pattern: get_* for retrievers, screen_* for screeners, search_* for lookups, plus action verbs like analyze_, backtest_, compare_, import_, and query_. Subfamilies (dart_*, edgar_*, fred_*, crypto_*) are consistently prefixed, making tool selection predictable.

Tool Count3/5

37 tools is heavy, and the four momentum screeners (canslim/kell/minervini/schwartz) plus three KR disclosure tools could arguably be collapsed into parameterized variants. However, the server's unusually broad scope—KR/US/TW/JP/EU equities, crypto, macro, portfolio, backtesting—means most tools earn their place, so the count is high but not chaotic.

Completeness4/5

The surface covers the core workflow well: search, prices, fundamentals, filings, insider trades, valuation, screeners, backtesting, and portfolio tracking for KR/US, plus crypto and macro. Notable gaps are the lack of single-company financial-statement tools for TW/JP/EU (only available through screen_companies) and no real-time stock quotes, but these are workable for the stated local-database research purpose.

Resources