Skip to main content
Glama

FinBridge

Screen Companies (FinBridge DB)

screen_companies
Read-only

Screen companies across five markets on annual fundamentals stored in the local finbridge database: Korea (DART), the US (SEC EDGAR), Taiwan (TWSE/TPEx), Japan (EDINET) and Europe (ESEF/IFRS). Filters and sorting run on standard metrics plus derived ratios; only annual rows (quarter=0) are considered. Base amounts are in each company's reporting currency — KRW, USD, TWD, JPY, or for Europe whatever the filer reports in (EUR, DKK, SEK, NOK, PLN, ...) — so absolute-value thresholds are market-dependent and cross-market (market='all') screens work best with ratio metrics (margins, roe, debt_ratio).

Coverage note: Taiwan carries only the latest reported period, because TWSE publishes a snapshot rather than history. Europe is still loading and is thinner than the others: about 1 in 8 rows has no operating_income (the filer tags it with a company extension rather than the IFRS concept) and about 1 in 5 has no revenue (banks and investment entities report interest revenue or fair-value gains, not a single IFRS revenue total — we leave the column empty rather than fill it with a component that would make margins mean different things per row). Germany and Ireland are largely absent from the ESEF index, and European rows carry no ticker yet (page_url is null). Every market here has financial statements — none of them is master-only.

What 'eu' means: any issuer that files under ESEF, i.e. has securities admitted to an EU/EEA/UK regulated market. That is a listing venue, not a domicile, so foreign issuers listed in Europe appear here too (Samsung Electronics, Toyota Caetano Portugal, Kazatomprom) and amounts stay in the filer's own reporting currency. A company cross-listed in several of our markets appears once per market with that market's own filing, so market='all' can show it more than once — this is not new to Europe (Toyota is already under both 'us' as TOYOTA MOTOR CORP and 'jp' as トヨタ自動車株式会社). Screen one market at a time when you need each company exactly once.

Period fallback: a single-market screen normally uses each company's latest ANNUAL report. When a market has no annual rows yet (Taiwan today reports a half-year cumulative), the screen drops to that market's latest available period and the response says which one in the 'period' field — e.g. "FY2026 Q2 (year-to-date cumulative)". Within one market every row is then the same period, so the ranking holds. market='all' never does this: lining up a half-year revenue against a full-year one would be a silently wrong table.

Args:

  • market: 'kr' (DART), 'us' (EDGAR), 'tw' (TWSE/TPEx), 'jp' (EDINET), 'eu' (ESEF), or 'all' (default)

  • fiscal_year: specific fiscal year; omit to use each company's latest annual report

  • filters: up to 5 of {metric, op, value}. op: gt|gte|lt|lte|eq. value is a number (ratios are in percent, e.g. 20 = 20%).

  • sort_by: metric to sort on (default 'revenue'); order: 'asc'|'desc' (default 'desc')

  • limit: 1-100 (default 20); response_format: 'markdown'|'json'

Metrics: revenue, gross_profit, operating_income, net_income, eps_diluted, assets, liabilities, equity, cash_and_equivalents, operating_cash_flow, plus derived operating_margin (operating_income/revenue100), net_margin (net_income/revenue100), roe (net_income/equity100), debt_ratio (liabilities/equity100).

Returns: {count, market, fiscal_year|'latest', sort_by, order, rows: [{name, source, ticker|stock_code, fiscal_year, currency, }]}. If a company reports under multiple accounting bases for the same year it may appear once per basis.

Examples:

  • KR companies with operating margin > 20%: {market: 'kr', filters: [{metric: 'operating_margin', op: 'gt', value: 20}], sort_by: 'operating_margin'}

  • US mega caps by revenue in FY2025: {market: 'us', fiscal_year: 2025, sort_by: 'revenue', limit: 10}

Use when: ranking or filtering many companies at once. Don't use for a single known company's statement detail (query_db or get_dart_financials / get_edgar_financials). Errors: 'database has not been built yet' — ingest has not run; an empty result is not an error (count 0).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax rows, 1-100 (default 20)
orderNoSort direction (default desc)desc
marketNoMarket: 'kr' (DART), 'us' (EDGAR), 'tw' (TWSE/TPEx), 'jp' (EDINET), 'eu' (ESEF), or 'all' (default)all
filtersNoUp to 5 metric filters, ANDed together
sort_byNoMetric to sort by (default revenue)revenue
fiscal_yearNoSpecific fiscal year; omit to use each company's latest annual report
response_formatNo'markdown' for a table, 'json' for compact machine-readable outputmarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsYes
countYes
orderNo
marketYes
periodNo
sort_byNo
fiscal_yearNo

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 only state readOnlyHint=true, but the description goes far beyond that: only annual rows (quarter=0) are considered, amounts are in each filer's reporting currency, Taiwan has only the latest period, Europe has specific data-coverage gaps, period fallback behavior is explained, market='all' never mixes periods, and empty results are not errors. None of this contradicts the annotations.

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 it is organized into labeled, decision-relevant sections: market scope, coverage caveats, 'eu' semantics, period fallback, args, metrics, returns, examples, use-when, and errors. It is front-loaded with the core purpose and every section earns its place given the complexity of five markets and several data-quality nuances.

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 market scope, data quality, currency handling, duplicates, fallback behavior, parameter semantics, metric definitions, return shape, examples, when-not-to-use guidance, and error messages. It even explains the reasoning behind behaviors such as why market='all' refuses period fallback, which an agent needs to make correct calls.

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?

Even though schema coverage is 100%, the description adds essential meaning beyond the schema: formulas for derived ratios, the percent convention for ratios, market-dependent absolute-value caveats, fiscal_year omission meaning 'latest annual report', filters being ANDed, max and default values, the period field, and concrete examples. This substantially enriches the raw schema definitions.

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 verb and resource: 'Screen companies across five markets on annual fundamentals stored in the local finbridge database.' It names all five markets and the regulatory sources, and later explicitly distinguishes itself from query_db, get_dart_financials, and get_edgar_financials by saying it is not for single-company statement detail. This makes the tool clearly distinguishable from sibling screening and financial-statement 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 contains an explicit 'Use when: ranking or filtering many companies at once' and a 'Don't use for a single known company's statement detail' branch with named alternatives. It also gives practical guidance on when to screen one market at a time, why market='all' can duplicate cross-listed companies, and why cross-market screens work best with ratio metrics.

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.

Resources