Skip to main content
Glama

FinBridge

Company Valuation (FinBridge DB)

get_valuation
Read-only

Get the latest valuation snapshot for one KR, US, or Taiwan company from the local finbridge database: market cap (latest close x shares) with PER, PBR, PSR, ROE, debt ratio, and 3-year revenue/net-income CAGR, joined to the company's latest annual fundamentals. Includes metric-level calculation basis, dates, sources, missing reasons, and 1-2 same-market percentile hints. Computed by the nightly valuation ingest job.

Share counts: KR uses data.go.kr listed shares, US prefers SEC-reported shares, and Taiwan uses exchange-reported shares; the nightly job can fall back to net_income / eps_diluted when a positive result is available. PER prefers price / eps_diluted, falling back to market_cap / net_income. Taiwan exchange-published PER/PBR replace derived values when present. Any derived ratio whose required denominator is null or <= 0 is returned as null.

Args:

  • company: US ticker (e.g. 'AAPL'), KR 6-digit stock code (e.g. '005930'), or company name. Resolution priority: exact ticker > 6-digit code > exact name > partial name (multiple partial matches return a candidate-list error).

  • per_multiples: optional 1-5 positive user-supplied PER assumptions (maximum 1000)

  • pbr_multiples: optional 1-5 positive user-supplied PBR assumptions (maximum 100)

  • response_format: 'markdown' (default) or 'json'

Returns the existing valuation fields plus metric_evidence and multiple_scenarios. Ratios are plain numbers; roe/debt_ratio/CAGR and scenario upside/downside are in percent. A scenario is arithmetic from the user's multiple, not a target-price recommendation. If no multiple is supplied, no multiple or target price is invented.

Examples:

  • {company: '005930'} -> Samsung Electronics PER/PBR/ROE plus "PER in the cheapest N% of the KR market"

  • {company: 'AAPL'} -> Apple valuation snapshot with US-market percentiles

Caveats: if statements are in another currency than the listing (Korean listings reporting in USD/CNY/JPY), statement values are converted at one Federal Reserve H.10 rate on or before the price date before PER/PBR/PSR (fx_conversion shows the rate and date; no rate → null). ROE/debt ratio need no conversion; growth across a statement-currency change is null. market_cap keeps the listing currency. KR fundamentals are K-IFRS and US are US-GAAP, so cross-market comparisons are approximate. This is snapshot data (not real-time) and not investment advice.

Use when: assessing one company's valuation/quality at a glance, or comparing it to its own market. Don't use for many-company ranking (use query_db) or raw statements (get_dart_financials / get_edgar_financials). Errors: unknown company -> no-match or candidate-list error; 'no valuation snapshot' -> the valuation ingest job has not produced a row for this company (needs a price and latest-annual fundamentals).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
companyYesUS ticker (e.g. 'AAPL'), KR 6-digit stock code (e.g. '005930'), or company name
pbr_multiplesNoOptional 1-5 positive PBR assumptions supplied by the user; no default is invented
per_multiplesNoOptional 1-5 positive PER assumptions supplied by the user; no default is invented
response_formatNo'markdown' for a table + interpretation, 'json' for compact machine-readable outputmarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pbrNo
perNo
psrNo
roeNo
ttmNo
as_ofNo
notesNo
priceNo
sharesNo
companyYes
currencyNo
data_as_ofNo
debt_ratioNo
market_capNo
ni_cagr_3yNo
updated_atNo
fiscal_yearNo
rev_cagr_3yNo
peer_contextNo
fx_conversionNo
interpretationNo
metric_evidenceNo
peer_comparisonNo
multiple_scenariosNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / fx_conversion
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "properties": {},
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
  2. Changed4 schema fields changed
    • addedInput schema / properties / pbr_multiples
      Added value: +{
      +  "description": "Optional 1-5 positive PBR assumptions supplied by the user; no default is invented",
      +  "items": {
      +    "exclusiveMinimum": 0,
      +    "maximum": 100,
      +    "type": "number"
      +  },
      +  "maxItems": 5,
      +  "minItems": 1,
      +  "type": "array"
      +}
    • addedInput schema / properties / per_multiples
      Added value: +{
      +  "description": "Optional 1-5 positive PER assumptions supplied by the user; no default is invented",
      +  "items": {
      +    "exclusiveMinimum": 0,
      +    "maximum": 1000,
      +    "type": "number"
      +  },
      +  "maxItems": 5,
      +  "minItems": 1,
      +  "type": "array"
      +}
    • addedOutput schema / properties / metric_evidence
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "properties": {},
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • addedOutput schema / properties / multiple_scenarios
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "properties": {},
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
  3. Changed3 schema fields changed
    • addedOutput schema / properties / data_as_of
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "properties": {},
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • addedOutput schema / properties / notes
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    }
      +  ]
      +}
    • addedOutput schema / properties / peer_comparison
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "properties": {},
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
  4. Changed1 schema field changed
    • addedOutput schema / properties / ttm
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "properties": {},
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
  5. First observed

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, and the description adds substantial behavioral context: the nightly ingest job, snapshot-not-real-time caveat, share-count and PER fallback logic, Taiwan exchange-published value precedence, null denominator behavior, currency conversion details, and the explicit 'not investment advice' disclaimer. No contradiction with the read-only annotation.

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 tightly organized with labeled sections: intro, share/PER methodology, Args, examples, Caveats, Use when, and Errors. It front-loads the core purpose and then layers edge cases and disclaimers. Every section contributes actionable guidance; nothing is redundant filler.

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?

For a complex, multi-market valuation tool, the description is complete: it covers return semantics (plain numbers vs percents, metric_evidence, multiple_scenarios), units, fallback behavior, currency conversion, basis of accounting, error conditions, and what should not be inferred from scenarios. Even with an output schema present, the description provides the interpretive context needed to use results 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 enriches parameter understanding beyond the schema: it explains company resolution priority (ticker > code > exact name > partial name), the candidate-list error for multiple partial matches, the meaning and bounds of per_multiples/pbr_multiples ('no default is invented'), and response_format behavior for markdown vs json. These are semantics not present in the schema descriptions.

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 names a specific verb and resource: 'Get the latest valuation snapshot for one KR, US, or Taiwan company from the local finbridge database.' It enumerates the metrics returned (market cap, PER, PBR, ROE, etc.) and explicitly differentiates from siblings by saying what it is not for (many-company ranking, raw statements). An agent can immediately tell this is a single-company valuation tool.

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 and a 'Don't use' section naming alternatives: 'use query_db' for ranking and 'get_dart_financials / get_edgar_financials' for raw statements. This gives clear selection criteria and exclusions beyond any schema or annotations.

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.