Skip to main content
Glama

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
NameRequiredDescriptionDefault
rankNoOmit for business-related references; 'size' explicitly requests same-currency size references; 'segments' uses business-mix similarity
limitNoPeers to return (default 5)
marketNoRestrict resolution to one market ('eu' = ESEF filers, identified by ISIN)
companyYesTicker, KR 6-digit code, TW/JP 4-digit code, or name
response_formatNoOutput format (default markdown)
same_market_onlyNoOnly peers from the company's own market

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_ofNo
basisNo
notesNo
peersYes
sectorNo
companyYes
segmentsNo
data_as_ofNo
industry_mixNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
  2. Changed10 schema fields changed
    • 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"
      +    }
      +  ]
      +}
  3. Changed2 schema fields changed
    • 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"
      +]
  4. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark the tool as readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral context: it does not assert direct competition, does not fill limits with unrelated companies, the rank='size' mode is explicitly size-reference only, and segment splits are informational unless rank='segments'. It also notes that unverified cross-currency absolute market-cap ordering is never used. This goes far beyond the annotations and clarifies edge cases.

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?

Although long, the description is structured into Args, Returns, Examples, Use when, Notes, and Errors sections. Every sentence adds value—no filler. The opening sentence states the core purpose immediately, and the structure allows an agent to quickly find relevant details. The length is justified given 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?

The description covers the return structure (policy_version, purpose, insufficiency_reason, plus per-peer selection_reason, comparison_role, evidence_status) and error behavior (unknown/ambiguous company -> candidate list; no classification -> basis_kind='size'). It also includes nuanced notes about segment names and curated themes. With a comprehensive output schema and rich description, nothing an agent needs to call it 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?

Schema coverage is 100% (every parameter has a description), but the tool description adds significant extra meaning: it explains how market disambiguates shared codes (TW/JP 4-digit), what same_market_only affects (cross-market peers allowed by default), the semantics of rank='segments' with cosine similarity and tie-breaking, and the default of limit=5. It also clarifies response_format defaults. This is far more than the schema alone provides.

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 precise purpose: 'Comparison references for one company across KR / US / TW / JP / EU.' It explicitly distinguishes itself from siblings by stating 'Don't use for strategy screens (screen_*) or for full financial statements (get_dart_financials / get_edgar_financials)' and names alternatives. The verb+resource is clear, and the differing ranking modes (business-related, size, segments) make the tool's scope unambiguous.

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 includes an explicit 'Use when' section: 'building a comparison table or choosing competitors for a financial comparison.' It then lists exclusions ('Don't use for strategy screens (screen_*) or for full financial statements (get_dart_financials / get_edgar_financials)'). This gives the agent both positive and negative routing guidance, which is ideal.

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.