Skip to main content
Glama

FinBridge

Portfolio Backtest (FinBridge DB)

backtest_portfolio
Read-only

Backtest a fixed-weight KR or US portfolio on daily data from the local finbridge.db (stocks are corporate-action adjusted; US stocks are total-return where SEC-reported dividends exist). ⚠ETFs are PRICE-RETURN ONLY in every market (no distributions), AND US ETF bars are NOT split-adjusted yet — a series with a split is refused, not mispriced. US history starts 2023-03-28, so earlier start dates are clipped. Pure historical simulation — no forecasts.

Args:

  • assets: 1-15 of {symbol, weight}. symbol = KR 6-digit code ('005930'), US ticker ('AAPL', 'SPY'), or a company/ETF name. Weights are normalized to sum 1.

  • from (required, YYYY-MM-DD), to (default: today). Start is clipped to the latest asset inception date (noted).

  • rebalance: 'none'|'monthly'|'quarterly'|'yearly' (default 'yearly') — rebalanced at the close of the first trading day of each new period.

  • currency: 'USD' (default) | 'KRW' — reporting currency; assets in the other currency are converted daily (USDKRW, FRED DEXKOUS).

  • initial: starting value in the report currency (default 10000).

Returns: {period, currency, rebalance, assets[](weight_pct, first_date, dividend_adjusted, converted), metrics{total_return_pct, cagr_pct, vol_annual_pct, sharpe, mdd_pct, mdd_peak_date, mdd_trough_date, best_year, worst_year}, annual_returns[], equity_curve[](sampled, JSON only), notes[]}.

Examples:

  • Samsung + KODEX 200 70/30: {assets:[{symbol:'005930',weight:0.7},{symbol:'069500',weight:0.3}], from:'2021-01-01', currency:'KRW'}

Use when: "what if I invested in X portfolio since YYYY" questions, comparing allocations, drawdown/volatility analysis. Don't use for: single-stock history (get_stock_prices), stock screening (screeners), strategy backtests with entry/exit rules (not yet available). Errors: unknown/ambiguous symbol -> candidates list; US asset -> not-supported error (licensing); KR data before 2020 -> source-limit hint; <60 overlapping trading days -> range too short. Notes: Simulation on historical data — not investment advice. Commission, one-way slippage and sell-side tax ARE deducted on the initial purchase and every rebalance (set costs=false for a gross view); dividends on KR stocks and all ETFs are not. KR stocks are price-return only (no distributions). US stocks are total-return where SEC-reported dividends exist (see dividend_adjusted per asset; ex-dates are approximated by fiscal-quarter end), otherwise price-return. ⚠ETFs are price-return only in every market right now — distributions are not in the data, so bond, REIT and high-dividend ETFs are understated. ⚠US ETF bars are also NOT split-adjusted — splits-us reads a SEC XBRL ratio that 1940-Act funds never file (2026-09-04 scan: 200 integer-ratio split events across 186 of 5,868 US ETFs, e.g. XLK/XLU 2:1 on 2025-12-05). This backtest refuses such a series rather than mispricing it, but tools that read the bars directly (get_stock_prices, get_technicals, screeners) still see the raw jump.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoEnd date YYYY-MM-DD (default: today)
fromYesStart date YYYY-MM-DD
costsNoDeduct commission, slippage and sell-side tax on every rebalance (default true). Set false for a gross-return view.
labelNoName this run so you can find it again with get_backtest_runs (the run is saved either way).
assetsYesPortfolio assets with weights
initialNoStarting value in the report currency (default 10000)
currencyNoReporting currency (default USD)USD
benchmarkNoBenchmark symbol from the benchmarks table (KOSPI, KOSPI200, SPY, VTI, EW_KR, EW_US, EW_TW), 'auto' for the dominant market's default, or 'none'.auto
rebalanceNoRebalancing frequency (default yearly)yearly
slippage_bpsNoOne-way slippage in basis points (default 5). An assumption — we hold no quote data.
response_formatNo'markdown' for tables, 'json' for compact machine-readable outputmarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNo
assetsYes
periodYes
initialNo
metricsYes
currencyNo
benchmarkNo
rebalanceNo
final_valueNo
equity_curveNo
annual_returnsYes

Schema Changelog

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

  1. First observed

TDQS

A4.1/5.0
Behavior1/5

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

The text is rich in caveats (ETF price-return only, not split-adjusted, US history clipping, cost deductions). However, the label parameter description states the run is saved and can be found with get_backtest_runs, while annotations declare readOnlyHint=true; this persistent side effect directly contradicts the read-only annotation, so per rubric this dimension scores 1 despite the other disclosures.

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 front-loaded purpose, Args, Returns, Examples, Use/Don't-use, Errors, and Notes, and the example is useful. It is long and repeats the ETF price-return/split-adjustment and total-return caveats in both the opening warning and Notes, so it loses one point for conciseness.

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 an 11-parameter tool with an output schema, the definition covers input semantics, return shape, examples, error behavior, and data caveats. An agent has enough context to invoke it correctly and to interpret results, and the output schema covers return details.

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?

Schema coverage is 100%, but the description goes well beyond it: symbol resolution rules, weight normalization, start-date clipping to asset inception, rebalance timing, daily currency conversion via USDKRW/FRED DEXKOUS, initial-value default, and gross-vs-net cost behavior. This materially helps an agent construct correct arguments.

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?

Opening sentence states a specific verb, resource, and scope: 'Backtest a fixed-weight KR or US portfolio on daily data from the local finbridge.db.' The 'Don't use for' section explicitly separates it from get_stock_prices, screeners, and strategy-backtest tools, so an agent can distinguish it from siblings.

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

Usage Guidelines5/5

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

'Use when' gives concrete scenarios (what-if since YYYY, comparing allocations, drawdown/volatility analysis). 'Don't use for' names sibling alternatives and the not-yet-available strategy-backtest class, leaving no ambiguity about when to call this tool.

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