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 screen_companies / 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

Name	Required	Description	Default
`company`	Yes	US ticker (e.g. 'AAPL'), KR 6-digit stock code (e.g. '005930'), or company name
`pbr_multiples`	No	Optional 1-5 positive PBR assumptions supplied by the user; no default is invented
`per_multiples`	No	Optional 1-5 positive PER assumptions supplied by the user; no default is invented
`response_format`	No	'markdown' for a table + interpretation, 'json' for compact machine-readable output	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`pbr`	No
`per`	No
`psr`	No
`roe`	No
`ttm`	No
`as_of`	No
`notes`	No
`price`	No
`shares`	No
`company`	Yes
`currency`	No
`data_as_of`	No
`debt_ratio`	No
`market_cap`	No
`ni_cagr_3y`	No
`updated_at`	No
`fiscal_year`	No
`rev_cagr_3y`	No
`peer_context`	No
`fx_conversion`	No
`interpretation`	No
`metric_evidence`	No
`peer_comparison`	No
`multiple_scenarios`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 13, 2026

addedOutput schema / properties / fx_conversion

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

Changed4 schema fields changedSep 9, 2026

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"
+    }
+  ]
+}

Changed3 schema fields changedSep 7, 2026

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"
+    }
+  ]
+}

Changed1 schema field changedSep 6, 2026

addedOutput schema / properties / ttm

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

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 the safety profile (readOnly, non-destructive, closed-world), but the description goes far beyond it: it discloses snapshot vs real-time nature, the nightly ingest job, null-return rules for bad denominators, FX conversion behavior, cross-market accounting differences, and error semantics. This is unusually rich behavioral context that the annotations cannot convey.

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?

Content is front-loaded and clearly sectioned (prose, Args, Returns, Examples, Caveats, Use when, Errors), and each block is substantive. It is verbose, however, and the Share counts / PER fallback paragraph could be tightened for an agent-scanning tool description.

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 single-company valuation tool with an output schema, the description covers inputs, units (ratios plain, ROE/CAGR in percent), returns, multi-currency caveats, and error states. Even though an output schema exists, the documented field semantics (metric_evidence, multiple_scenarios, fx_conversion) give an agent everything needed to call and interpret it.

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 adds real meaning beyond the schema: the company resolution priority (exact ticker > 6-digit code > exact name > partial name) and the candidate-list error on ambiguous partial matches, plus clarification that scenario outputs are arithmetic from user multiple, not invented defaults.

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 ('get the latest valuation snapshot for one company') and enumerates the exact metrics returned (market cap, PER, PBR, PSR, ROE, debt ratio, CAGR). It explicitly differentiates from siblings by naming screen_companies/query_db for ranking and get_dart_financials/get_edgar_financials for raw 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 'Use when / Don't use for' block gives explicit inclusion criteria (assess one company's valuation, compare to its own market) and explicit exclusions with named alternatives for both exclusion cases. Nothing is left 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.