Skip to main content
Glama

FinBridge

Factor Study (FinBridge DB)

analyze_factors
Read-only

Measure whether a ranking signal actually separates future returns, point-in-time, on KR/US/TW daily bars from the local finbridge.db. This is the question that comes BEFORE a screener: not "which names pass today" but "does this axis pay at all".

Three answers per factor:

  • Quantile portfolios: at every rebalance the investable set is sorted on the factor and cut into N buckets; you get each bucket's average forward return. A real signal is monotonic from Q1 to QN. If only the ends move and the middle is noise, that is a tail, not a signal.

  • IC (information coefficient): the cross-sectional Spearman correlation between factor rank and forward-return rank at each date. mean is the strength of the direction; ir = mean/stdev is how consistently it holds. A high mean with a low IR was made by a few regimes.

  • Correlation matrix: average rank correlation between the factors themselves. Two factors that see the same thing do not diversify each other.

Price factors (any market with bars, and the default set): mom_12_1 (12-month return skipping the last month), reversal_1m, trend_50_200, range_52w (position in the 52-week band), volatility_60d, liquidity (a control, since the investable set is already ranked on it).

Fundamental factors (KR and US only, request them explicitly): earnings_yield (diluted EPS / price), roe, net_margin, gross_margin, debt_ratio, asset_growth (YoY total assets), accruals ((net income − operating cash flow) / assets). Two more need market capitalisation and are therefore US only: book_yield (equity / market cap, the inverse of P/B) and sales_yield (revenue / market cap). Their market cap uses the share count that was already reported on the signal date, never today's — elsewhere we hold only today's share count, and multiplying a 2022 price by a 2026 share count is not a 2022 market cap, so those markets are refused with an explicit error. Each reads only the annual report that was ALREADY PUBLIC on the signal date. They rank fewer names than price factors, so every factor carries coverage_pct — read it before putting a 40%-coverage spread next to a 100%-coverage one. Taiwan is refused for these with an explicit error rather than a near-empty table, because TWSE publishes a latest-period snapshot instead of a series. Book/price and sales/price are absent on purpose: they need market cap, and we have no history of shares outstanding.

Args:

  • market: 'kr' | 'us' | 'tw' (required). Japan and Europe carry no price data, so they cannot be studied here.

  • years: history window, 2-20 (default 5). US bars start 2023-03-28 (volume from 2024-07-01), so US windows are shallower.

  • hold: forward-return window in trading days, 5-250 (default 20).

  • rebalance: trading days between measurement dates, 5-250 (default 20). Set equal to hold for non-overlapping, inference-ready observations.

  • quantiles: 3-10 buckets (default 5).

  • universe: how many of the most-traded names form the investable set, 20-1000 (default 300).

  • factors: subset of the keys above; omit for the six price factors. Fundamental factors are never in the default set — name them.

  • slippage_bps: one-way slippage assumption used only for the reported cost figure (default 5).

Returns: {range, universe, rebalances, overlapping, cost_per_rebalance_pct, factors[]{key, label, definition, fundamental, coverage_pct, asfiled_pct, report_age_days, monotonic, quantiles[]{q, avg_return, median_return, win_rate, avg_names}, long_short{avg, net_avg, t_stat, positive_share, turnover}, ic{mean, stdev, ir, t_stat, positive_share, dates}}, correlation[][], caveats[]}.

Reading the numbers: ic.ir is mean/stdev and is NOT a t-statistic — ic.t_stat is. The two long-short and IC t-statistics can disagree, and that disagreement is information: in a 2026-09 Korean run earnings_yield had an IC IR of 0.90 while its long-short t was 1.39, meaning the signal was spread broadly across the ranking while the extreme buckets themselves were noisy. report_age_days is how stale the annual report was at the signal date; it is also the look-ahead guard, since a negative value would mean a report was used before it was public.

Examples:

  • Does momentum pay in Korea? {market:'kr', factors:['mom_12_1','reversal_1m'], hold:20, rebalance:20}

  • Inference-ready quarterly study: {market:'us', hold:60, rebalance:60, years:3}

  • Does cheapness or quality pay in Korea? {market:'kr', factors:['earnings_yield','roe','accruals','asset_growth'], hold:60, rebalance:60}

  • Do value and momentum overlap? {market:'kr', factors:['earnings_yield','mom_12_1']} — read the correlation cell, not just the two spreads.

Use when: judging whether a ranking rule is worth building a screen on, comparing candidate signals, or checking whether two signals overlap. Don't use for: picking names today (screeners), simulating a specific portfolio (backtest_portfolio), or any factor that needs market capitalisation (PBR, PSR) — we hold no history of shares outstanding. Errors: a market with no price data, or a window too short for the warm-up (260 sessions plus the hold) -> explicit error, not an empty result. Notes: Returns are GROSS — signal strength and trading friction are separate questions, so cost is reported next to it (long_short.net_avg subtracts measured turnover times the round-trip cost). Delisted names are included. Dividends are excluded in every market. Fundamental factors update once a year and carry a small restatement look-ahead (the stored figures are the latest values under the original filing date). Simulation on historical data, not investment advice; a factor that worked in one window can stop working.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
holdNoForward-return window in trading days (default 20)
labelNoName this study so you can find it again with get_backtest_runs (it is saved either way).
yearsNoHistory window in years (default 5)
marketYesMarket with daily bars: 'kr', 'us' or 'tw'
factorsNoSubset of factors; omit for the price set (mom_12_1, reversal_1m, trend_50_200, range_52w, volatility_60d, liquidity). Fundamental keys (KR/US only): book_yield, sales_yield, earnings_yield, roe, net_margin, gross_margin, debt_ratio, asset_growth, accruals
universeNoMost-traded names forming the investable set (default 300)
quantilesNoNumber of buckets (default 5)
rebalanceNoTrading days between measurement dates (default 20). Equal to hold = non-overlapping observations.
slippage_bpsNoOne-way slippage in bp used for the reported cost figure (default 5)
response_formatNo'markdown' for tables, 'json' for compact machine-readable outputmarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
holdYes
rangeYes
marketYes
caveatsYes
factorsYes
universeYes
quantilesYes
rebalanceYes
rebalancesYes
correlationYes
overlappingYes
cost_per_rebalance_pctYes

Schema Changelog

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

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark it readOnlyHint=true, and the description adds substantial behavioral context: returns are gross, delisted names are included, dividends are excluded, fundamental factors carry a restatement look-ahead, and certain markets/refusals produce explicit errors. It also explains the distinction between IC IR and t-statistic, all beyond what annotations or schema provide.

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

Conciseness5/5

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

The description is long, but the length is earned by the tool's complexity: 10 parameters, a large factor taxonomy, market restrictions, and subtle output semantics. It is front-loaded with the core purpose, then organized into clear sections for args, returns, examples, usage boundaries, and caveats. Every section adds decision-relevant information.

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 parameter ranges, factor availability by market, data history limitations, error behavior, output interpretation, and look-ahead concerns. Even though an output schema exists, the description adds necessary interpretive context such as coverage_pct, net_avg, and the meaning of report_age_days. An agent has everything needed to call and interpret this tool correctly.

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 description coverage is 100%, but the description goes far beyond the schema by explaining the meaning of each factor, market-specific constraints, why rebalance=hold gives non-overlapping observations, the role of coverage_pct, and what slippage_bps affects. It also provides worked examples that map parameter combinations to research questions.

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 states a specific verb and resource: 'Measure whether a ranking signal actually separates future returns, point-in-time, on KR/US/TW daily bars from the local finbridge.db.' It also positions the tool relative to its siblings by saying this question comes 'BEFORE a screener', which distinguishes it from screen_canslim, screen_minervini, and similar tools.

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?

The description gives explicit 'Use when' and 'Don't use for' sections, naming alternatives such as screeners, backtest_portfolio, and any factor requiring market capitalisation. This gives an agent clear routing criteria rather than leaving the decision to inference.

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