FinBridge

Peer Companies

get_peers

Read-only

Comparison references for one company across KR / US / TW / JP / EU. The default uses a sourced business theme or broad source classification and does not assert direct competition or add unrelated companies to fill the limit. Explicit rank='size' returns same-currency size references and does not assert an industry relationship. Also returns the company's business-segment revenue split where available (Japan from 有価証券報告書 XBRL, the US from SEC DERA financial-statement datasets; US segment names are usually end markets, not industries) — informational unless rank='segments'.

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'|'eu' (optional) — disambiguates codes/names shared across markets (TW and JP both use 4-digit codes; 'eu' companies are addressed by ISIN).
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 omitted = business-related references; 'size' = explicit size references with verified equal market-cap currency; '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 normalized 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: existing fields plus policy_version, purpose, insufficiency_reason; each peer also has selection_reason, comparison_role and evidence_status. Broad/theme rows are business-related references, not verified direct competitors. Explicit size rows are size-reference only.

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: curated business themes remain separate from official company-level classifications. Segment names may be geographic (Japan/Asia/USA) when a company defines its reportable segments by region. Unverified cross-currency absolute market-cap ordering is never used. Errors: unknown/ambiguous company -> candidate list; no classification -> basis_kind='size' with a note.

Input Schema

TableJSON Schema

Name	Required	Description
`rank`	No	Omit for business-related references; 'size' explicitly requests same-currency size references; 'segments' uses business-mix similarity
`limit`	No	Peers to return (default 5)
`market`	No	Restrict resolution to one market ('eu' = ESEF filers, identified by ISIN)
`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
`as_of`	No
`basis`	No
`notes`	No
`peers`	Yes
`sector`	No
`company`	Yes
`purpose`	No
`segments`	No
`basis_kind`	No
`data_as_of`	No
`basis_label`	No
`industry_mix`	No
`policy_version`	No
`insufficiency_reason`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 1, 2026
- addedOutput schema / properties / basis_kind
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / basis_label
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / insufficiency_reason
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / policy_version
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / purpose
```
Added value: +{
+  "type": "string"
+}
```

Changed1 schema field changedSep 10, 2026

changedInput schema / properties / rank / description

Previous value: -"'size' (default) or 'segments' = business-mix similarity"New value: +"Omit for business-related references; 'size' explicitly requests same-currency size references; 'segments' uses business-mix similarity"

Changed10 schema fields changedSep 7, 2026

addedOutput schema / properties / as_of

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / properties / basis / $ref

Previous value: -"#/properties/company/properties/name_en"New value: +"#/properties/as_of"

changedOutput schema / properties / company / properties / market / $ref

Previous value: -"#/properties/company/properties/name_en"New value: +"#/properties/as_of"

addedOutput schema / properties / company / properties / name_en / $ref
```
Added value: +"#/properties/as_of"
```
removedOutput schema / properties / company / properties / name_en / type
```
Removed value: -[
-  "string",
-  "null"
-]
```

changedOutput schema / properties / company / properties / page_url / $ref

Previous value: -"#/properties/company/properties/name_en"New value: +"#/properties/as_of"

changedOutput schema / properties / company / properties / source / $ref

Previous value: -"#/properties/company/properties/name_en"New value: +"#/properties/as_of"

changedOutput schema / properties / company / properties / stock_code / $ref

Previous value: -"#/properties/company/properties/name_en"New value: +"#/properties/as_of"

changedOutput schema / properties / company / properties / ticker / $ref

Previous value: -"#/properties/company/properties/name_en"New value: +"#/properties/as_of"

addedOutput schema / properties / data_as_of

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

Changed2 schema fields changedSep 6, 2026

changedInput schema / properties / market / description

Previous value: -"Restrict resolution to one market"New value: +"Restrict resolution to one market ('eu' = ESEF filers, identified by ISIN)"

changedInput schema / properties / market / enum

Previous value: -[
-  "kr",
-  "us",
-  "tw",
-  "jp",
-  "all"
-]New value: +[
+  "kr",
+  "us",
+  "tw",
+  "jp",
+  "eu",
+  "all"
+]

First observedSep 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations cover safety (readOnly=true, destructive=false, openWorld=false), and the description adds substantial behavioral context beyond that: the non-assertion policy for default rows, same-currency constraint for size ranking, segment-data provenance (有価証券報告書 XBRL / SEC DERA), the conglomerate-matching rule, and explicit error/fallback behavior. This is rich disclosure on top of structured fields.

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 front-loaded and sectioned (Args / Returns / Examples / Use when / Notes / Errors), with examples that anchor each mode. It is long and repeats the 'business-related references, not verified competitors' point several times, which is mildly redundant but defensible given the tool's misuse risk.

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?

An output schema exists, yet the description still correctly frames what comes back (policy_version, purpose, insufficiency_reason, selection_reason, evidence_status) without over-specifying formats. Combined with the routing guidance and per-market identifier rules, an agent has everything needed to call this 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 coverage is 100%, so baseline is 3, but the description goes well beyond it: it defines what rank='segments' actually computes (cosine similarity over mapped segment industries, tie-break by normalized size), clarifies same_market_only's default and cross-market implication, and documents company-identifier formats per market. That materially changes how an agent would set these params.

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?

States a specific verb+resource (find comparison reference peers for one company) and instantly distinguishes itself: it produces references, not asserted competitors, across five named markets. The three rank modes are named up front, so an agent can tell it apart from screen_*/financial-statement tools without opening the schema.

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?

Explicit 'Use when' (comparison tables / choosing competitors) paired with 'Don't use for strategy screens (screen_*) or full financial statements (get_dart_financials / get_edgar_financials)'. This names the alternatives and the condition that routes away from this tool, leaving nothing to inference.

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.