FinBridge

Screen ETFs (FinBridge DB)

screen_etfs

Read-only

Screen exchange-traded funds in the local finbridge database on the things that actually distinguish an ETF: premium/discount to NAV, fund size (AUM), the index it tracks, price momentum, and — for US funds — the audited calendar-year TOTAL return from the fund's own prospectus.

Funds only. For an operating company use get_valuation (one company) or query_db (many at once).

⚠Funds file no annual financial statements, so the statement-based tools (get_dart_financials, get_valuation) have nothing to say about them — that is why they are screened here instead.

Coverage differs by market and the response says so per row:

KR (1,170 listed ETFs): NAV, AUM (net assets, KRW), listed units and the tracked index come from the same daily feed as prices, 2020-01-02 onward. premium_pct is close/NAV-1 computed on the SAME day (mixing dates would be meaningless).
US (5,868 ETFs): no NAV or AUM source exists that we may redistribute, so those fields are null. Instead total_return_pct carries the fund's audited calendar-year total return (distributions reinvested) from SEC prospectus data — the only distribution-inclusive number available.

⚠ret_20d / ret_120d are PRICE returns in every market: ETF distributions are not in the daily bars, so income funds look worse than they were. For US funds compare against total_return_pct to see the gap. ⚠aum is in the listing currency (KRW today). Do not rank across markets on it. ⚠total_return_pct is pinned to ONE calendar year across all rows (reported as total_return_year), because prospectus refresh dates differ per fund — ranking a 2024 figure against a 2025 one would be a silently wrong table.

Args:

market: 'kr', 'us', or 'all' (default)
min_aum: minimum net assets in listing currency (KR only; e.g. 100000000000 = 1,000억)
max_abs_premium_pct: keep funds trading within this |premium| of NAV, e.g. 0.5
min_premium_pct: keep funds at or above this premium (negative values find discounts)
min_price, min_volume: liquidity floors (vol_avg20 is the 20-session average)
index_contains: substring of the tracked index name — 'TR' finds total-return index trackers, '코스피' finds KOSPI trackers
name_contains: substring of the fund name or ticker
total_return_year: calendar year for total_return_pct; omit for the best-covered year
sort_by: aum | premium | abs_premium | ret_20d | ret_120d | ret_250d | volume | total_return (default aum); order: 'asc'|'desc' (default desc)
limit: 1-100 (default 20); response_format: 'markdown'|'json'

Returns: {count, market, total_return_year, sort_by, order, rows: [{market, symbol, name, as_of, close, nav, premium_pct, aum, index_name, ret_20d, ret_120d, vol_avg20, total_return_pct, total_return_period}]}

Examples:

Large KR ETFs trading close to fair value: {market:'kr', min_aum: 100000000000, max_abs_premium_pct: 0.3, sort_by:'aum'}
KR ETFs at the deepest discount to NAV: {market:'kr', sort_by:'premium', order:'asc'}
KR trackers of a total-return index: {market:'kr', index_contains:'TR', sort_by:'aum'}
US ETFs by audited total return: {market:'us', sort_by:'total_return'}

Use when: choosing or comparing funds. Don't use for stocks (get_valuation / query_db) or for a single fund's price history (get_stock_prices). Errors: 'database has not been built yet' — ingest has not run; an empty result is not an error (count 0).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Max rows, 1-100 (default 20)
`order`	No	Sort direction (default desc)	desc
`market`	No	Market: 'kr', 'us', or 'all' (default)	all
`min_aum`	No	Minimum net assets in listing currency (KR only; US is null)
`sort_by`	No	Sort key (default aum)	aum
`min_price`	No	Minimum last close in listing currency
`min_volume`	No	Minimum 20-session average volume
`name_contains`	No	Substring of the fund name or ticker
`index_contains`	No	Substring of the tracked index name ('TR' for total-return indices)
`min_premium_pct`	No	Keep funds at or above this premium in percent (negative finds discounts)
`response_format`	No	'markdown' for a table, 'json' for compact output	markdown
`total_return_year`	No	Calendar year for total_return_pct; omit for the best-covered year (the response says which)
`max_abs_premium_pct`	No	Keep funds within this \|premium to NAV\| in percent

Output Schema

TableJSON Schema

Name	Required	Description	Default
`rows`	Yes
`count`	Yes
`order`	No
`market`	Yes
`sort_by`	No
`data_as_of`	No
`total_return_year`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 22, 2026
RemovedSep 20, 2026

Changed1 schema field changedSep 7, 2026

addedOutput schema / properties / data_as_of

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "properties": {},
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

First observedSep 6, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral context: market-specific coverage (KR vs US), price vs total return caveat, currency caveat for AUM, single-year pinning for total_return_pct, and the 'database has not been built yet' error case. These go well beyond the annotations and are critical for correct interpretation.

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 exceptionally well-structured: it front-loads the purpose, then provides parameter semantics, coverage caveats, return format, examples, and usage guidance in logical sections. Every sentence contributes information; there is no redundancy or filler, making the length justified by the tool's complexity.

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?

Given the tool's complexity (13 optional parameters, market-specific behavior, data quality caveats), the description is complete: it explains coverage differences, return semantics, parameter usage with examples, the exact return structure, and error handling. With annotations covering the read-only/destructive profile and an output schema described in the Returns section, nothing an agent needs to call this correctly is missing.

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?

Although the schema has 100% parameter description coverage, the description enriches it further: it explains the meaning of min_aum with an example (100000000000 = 1,000억) and notes it's KR-only because US AUM is null; clarifies index_contains 'TR' for total-return indices; explains premium_pct is same-day; and provides real usage examples for each filter. This adds value beyond the schema.

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 clearly states the tool screens ETFs in the local FinBridge database on specific distinguishing metrics (premium/discount to NAV, AUM, tracked index, momentum, and US audited total return). It explicitly distinguishes from operating-company tools by directing to get_valuation or query_db, and from statement-based tools like get_dart_financials.

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?

Explicitly says 'Use when: choosing or comparing funds' and 'Don't use for stocks (get_valuation / query_db) or for a single fund's price history (get_stock_prices).' It also explains why statement-based tools are not applicable to funds, giving clear when/when-not guidance with named alternatives.

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

All FinBridge tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.