FinBridge

Peer Companies

get_peers

Read-only

Comparison set for one company across KR / US / TW / JP: the company plus its closest peers, chosen from the same industry group (SIC / KSIC / TWSE / EDINET classification, normalised to one shared bucket) and ranked by market-cap proximity with same-market names first. Falls back to pure size peers when the company has no classification. Also returns the company's business-segment revenue split where available (currently Japan, from 有価証券報告書 XBRL) — informational, not yet used for ranking.

Args:

company: US ticker ('AAPL'), KR 6-digit code ('005930'), TW/JP 4-digit code ('2330', '7203'), or a company name (local or English).
market: 'kr'|'us'|'tw'|'jp' (optional) — disambiguates codes/names shared across markets (TW and JP both use 4-digit codes).
limit: 1-10 peers (default 5).
same_market_only: true = restrict peers to the company's own market (default false — a KR chipmaker can sit next to a US one).
rank: 'size' (default) = same industry group, nearest by market cap (or revenue where there is no price feed); 'segments' = rank by business-mix similarity — each company's segment revenue shares are mapped to standard industries (companies without segment data count as 100% their own industry) and compared by cosine similarity, ties broken by size. Conglomerates (Sony: games/music/pictures/electronics/finance) then get conglomerate peers instead of whichever single bucket they were filed under.
response_format: 'markdown' (default) or 'json'.

Returns: {company:{name, name_en, market, ticker|code}, basis:'sector'|'size'|'segments', sector:{group, label, name}, industry_mix:{vector:{industry:share}, primary:[industry], from_segments:bool} (rank='segments' only), peers:[{name, name_en, market, ticker|code, market_cap, per, pbr, roe, rev_cagr_3y, rs_pctile, ret_120d, similarity?, primary_industry?, has_segments?}], segments:{fiscal_year, rows:[{segment, kind, revenue_external, share_pct}]}, notes}.

Examples:

{company:'7203'} -> Toyota + transportation-equipment peers, with its Automotive / Financial Services segment split
{company:'005930', same_market_only:true} -> Samsung Electronics + KR tech-hardware peers only
{company:'6758', rank:'segments'} -> Sony ranked against other multi-segment conglomerates by business mix

Use when: building a comparison table or choosing competitors for a financial comparison. Don't use for strategy screens (screen_*) or for full financial statements (get_dart_financials / get_edgar_financials). Notes: company-level classification only; segment names may be geographic (Japan/Asia/USA) when a company defines its reportable segments by region. Market cap is in the company's listing currency, so cross-market rank by proximity is approximate. Errors: unknown/ambiguous company -> candidate list; no classification -> basis='size' with a note.

Input Schema

TableJSON Schema

Name	Required	Description
`rank`	No	'size' (default) or 'segments' = business-mix similarity
`limit`	No	Peers to return (default 5)
`market`	No	Restrict resolution to one market
`company`	Yes	Ticker, KR 6-digit code, TW/JP 4-digit code, or name
`response_format`	No	Output format (default markdown)
`same_market_only`	No	Only peers from the company's own market

Output Schema

TableJSON Schema

Name	Required	Description	Default
`basis`	No
`notes`	No
`peers`	Yes
`sector`	No
`company`	Yes
`segments`	No
`industry_mix`	No

Schema Changelog

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

First observedSep 6, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description richly discloses behavior: market-cap proximity ranking, same-market prioritization, fallback to size peers when no classification exists, the informational segment-revenue split, error behavior returning candidate lists, and currency caveats for cross-market comparisons. 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 earns its length for a tool with 6 parameters, 4 markets, and nuanced ranking logic. It is well-structured with Args, Returns, Examples, Use when, Notes, and Errors sections, and the core purpose is front-loaded before the parameter detail.

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?

With an output schema present and a description that details the return object's fields, ranking bases, segment payload, and error behavior, the tool is fully specified. It covers edge cases like missing classification, geographic segment names, and cross-market currency approximation, so an agent has everything needed to call it 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?

Although schema coverage is 100%, the description adds substantial meaning: accepted company identifier formats per market, the market disambiguation rationale, default behavior for same_market_only, and a detailed explanation of the 'segments' rank option including cosine similarity and tie-breaking. Examples map concrete values to expected behavior.

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: 'Comparison set for one company across KR / US / TW / JP: the company plus its closest peers.' It clearly defines the tool's scope and distinguishes it from siblings by explicitly naming what it is not for, such as strategy screens and full financial statements.

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 direct usage guidance: 'Use when: building a comparison table or choosing competitors for a financial comparison. Don't use for strategy screens (screen_*) or for full financial statements (get_dart_financials / get_edgar_financials).' It also explains fallback behavior and disambiguation contexts, leaving no ambiguity about when to invoke this tool.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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

Need Help?