Skip to main content
Glama

FinBridge

by kr.gronox.mcp

Daily Stock Prices (FinBridge DB)

get_stock_prices
Read-only

Get daily OHLCV price history from the local finbridge database (populated by the nightly ingest jobs). Rows are returned newest first.

Price coverage by market — we only store what we have redistribution rights to:

  • Korea (DART + Financial Services Commission): full daily history, corporate-action adjusted. SERVED.

  • Taiwan (TWSE OpenAPI, Open Government Data License): daily history. SERVED.

  • US (Databento EQUS.SUMMARY): daily history from 2023-03-28. SERVED. Split-adjusted; dividend-adjusted closes exist where SEC-reported dividends do (adj_close).

  • Japan: NOT served. EDINET publishes disclosure documents, not prices, so we hold Japanese filings and the company master but no quotes.

Args:

  • company: a ticker (US 'AAPL', TW/JP 4-digit '2330'), a KR 6-digit stock code ('005930'), or a company name in the local language or English ('TSMC', 'Toyota', '삼성전자'). Resolution priority: exact ticker > 6-digit KR code > exact name (name or English name) > partial name (multiple partial matches return a candidate list error).

  • from / to: optional YYYY-MM-DD range bounds (inclusive)

  • limit: max rows, 1-500 (default 60)

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

Plan note: the free plan serves the most recent 130 trading sessions of each name; paid plans serve the full stored history. When the window is trimmed the response carries a plan_limit field saying so.

Returns: {company: {name, source, ticker|stock_code}, count, truncated, prices: [{date, open, high, low, close, volume}]} — newest date first; truncated=true means older rows exist beyond 'limit'.

Examples:

  • {company: '005930', limit: 30} -> last 30 KR trading days for Samsung Electronics

  • {company: '005930', from: '2026-01-01', to: '2026-06-30'} -> Samsung Electronics H1 2026

Use when: historical closes/volumes for charting or return calculations from ingested data. Don't use for real-time quotes (use live-source tools) or crypto (get_crypto_ohlcv). Errors: unknown company -> no-match or candidate-list error; JP/EU company -> no-prices error (those markets carry statements only); no price rows -> a market-specific hint (new listing, delisted, nightly lag).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoEnd date YYYY-MM-DD (inclusive)
fromNoStart date YYYY-MM-DD (inclusive)
limitNoMax rows, 1-500 (default 60), newest first
companyYesKR 6-digit stock code (e.g. '005930') or company name
response_formatNo'markdown' for a table, 'json' for compact machine-readable outputmarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYes
pricesYes
companyYes
truncatedNo

Schema Changelog

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

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations only convey read-only behavior, but the description discloses much more: data is populated by nightly ingest jobs, rows are newest-first, market coverage depends on redistribution rights, the free plan trims history and adds a plan_limit field, and errors include market-specific hints. All of this is consistent with readOnlyHint=true; there is no contradiction.

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 into front-loaded summary, market coverage, args, returns, examples, usage guidance, and errors. Each section carries necessary information for a complex multi-market tool, and the opening sentence immediately communicates the core function.

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 full calling context: data availability per market, identifier resolution rules, plan-based limitations, response structure including truncation, and error behavior for unknown or unsupported companies. Given the tool's complexity, the description leaves little for the agent to infer.

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 the schema already describes all five parameters, the description adds significant meaning: company resolution priority with market-specific examples, inclusive date range semantics, the 1-500 limit with its default and plan-trimming behavior, and response_format output differences. The examples further clarify real usage patterns.

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 first sentence states a specific action and resource: getting daily OHLCV price history from the local finbridge database. It further differentiates itself from siblings by explicitly ruling out real-time quotes and crypto, naming get_crypto_ohlcv as the alternative.

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' and 'Don't use' sections give explicit guidance: use it for historical closes/volumes for charting or return calculations, and avoid it for real-time quotes or crypto. The market-coverage section also tells agents when a request for Japanese or EU companies will fail, enabling routing to other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All FinBridge toolsInspect
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