FinBridge

Disclosure Feed (FinBridge DB)

get_disclosure_feed

Read-only

Recent regulatory disclosures from the local finbridge database (filings table, refreshed nightly + intraday for KR), newest first — positioned as a faster-than-news primary source. By default returns only MATERIAL filings: US Form 8-K (current reports) and KR 주요사항보고서 (major events: capital raises, M&A, convertible bonds, buybacks, etc.).

Args:

market: 'kr' (DART), 'us' (EDGAR), or 'all' (default)
company: optional — restrict to one company (US ticker, KR 6-digit code, or name). Takes priority over watchlist.
material_only: default true (8-K / KR type-B only); false = all filing types
forms: optional explicit form_type filter (e.g. ['10-K','8-K'] or ['A','B']); overrides material_only
days: look-back window in days, 1-120 (default 14); or use from/to
from/to: optional explicit YYYY-MM-DD range (overrides days)
limit: 1-100 (default 30); response_format: 'markdown'|'json'
brief: default true — attach the plain-language fact summary (headline_en/headline_ko/facts_en/facts_ko/company_en/event_type) where one exists. Rows without a summary are unaffected. The markdown rendering shows the English side; both sides stay in the JSON.
watchlist: default false — restrict to the authenticated account's watchlist companies instead of all companies. Needs a personal API key (not the admin token). Ignored when 'company' is also given.

Returns: {count, market, since, rows:[{source, company_name, form_type, title, filed_date, url, items?, headline_en?, headline_ko?, facts_en?, facts_ko?, company_en?, event_type?}]}. 'items' (8-K item codes) is included when available. Summary fields are present only for filings that have one. Note: with brief:true, a filing that only exists as a summary (not yet in our filings index) can still appear — such rows omit form_type/items and, for non-DART sources, url.

Examples:

Latest US material events this week: {market:'us', days:7}
Samsung's recent major-event filings: {company:'005930', material_only:true, days:90}
All of a company's filings: {company:'AAPL', material_only:false}
My watchlist's recent disclosures with summaries: {watchlist:true}

Use when: scanning for catalysts / breaking corporate events, or one company's recent filings. Don't use for filing BODIES (open the url) or for financial statement values (get_dart_financials / get_edgar_financials / query_db). Notes: Filing metadata only; bodies are at the linked source URLs. Not investment advice. Errors: empty result is not an error (count 0).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`to`	No	Explicit end date YYYY-MM-DD
`days`	No	Look-back window in days (default 14)
`from`	No	Explicit start date YYYY-MM-DD (overrides days)
`brief`	No	Attach the fact-summary fields where one exists (default true). Rows without a summary are unaffected.
`forms`	No	Explicit form_type filter; overrides material_only
`limit`	No	Max rows (default 30)
`market`	No	Market: 'kr', 'us', or 'all' (default)	all
`company`	No	Optional company filter: US ticker, KR 6-digit code, or name
`watchlist`	No	Restrict to the authenticated account's watchlist companies (default false). Needs a personal API key. Ignored when 'company' is set.
`material_only`	No	Only material filings (US 8-K / KR type-B). Default true
`response_format`	No	'markdown' or 'json'	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`rows`	Yes
`count`	Yes
`since`	No
`market`	No
`company`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 22, 2026

addedInput schema / properties / brief

Added value: +{
+  "default": true,
+  "description": "Attach the fact-summary fields where one exists (default true). Rows without a summary are unaffected.",
+  "type": "boolean"
+}

addedInput schema / properties / watchlist

Added value: +{
+  "default": false,
+  "description": "Restrict to the authenticated account's watchlist companies (default false). Needs a personal API key. Ignored when 'company' is set.",
+  "type": "boolean"
+}

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 already provide readOnlyHint=true and destructiveHint=false, but the description layers on rich operational detail: refresh cadence (nightly + intraday for KR), default material_only behavior, summary-only rows that may omit form_type/items/url, 'empty result is not an error', and precedence rules between args. This fully discloses edge cases and side effects without contradicting annotations.

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?

The description is long but well organized with distinct sections (Args, Returns, Note, Examples, Use when, Errors). It is front-loaded with the purpose statement. Some non-essential marketing language ('positioned as a faster-than-news primary source') and the 'Not investment advice' disclaimer could be trimmed, but overall each section earns its place 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?

With 11 optional parameters and an output schema present, the description nevertheless documents every relevant operational aspect: default ranges, limits, precedence, authentication requirements, output shape including optional summary fields, edge cases, and error semantics. It includes multiple examples covering different markets, companies, watchlists, and materiality settings, so an agent has everything needed to call it 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 adds essential semantic detail: override precedence (from/to overrides days, forms overrides material_only, watchlist ignored when company set), the watchlist's personal-API-key requirement, and the effect of brief on returned fields. It also supplies concrete examples for each major parameter combination.

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 definition: 'Recent regulatory disclosures from the local finbridge database (filings table, refreshed nightly + intraday for KR), newest first' and specifies the material filing types by market. It differentiates from siblings by explicitly naming what it is not for ('filing BODIES', 'financial statement values' with get_dart_financials/get_edgar_financials/query_db).

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?

Contains an explicit 'Use when' section ('scanning for catalysts / breaking corporate events, or one company's recent filings') and a 'Don't use for' section that points to alternative tools for bodies and financial values. This gives clear routing guidance and leaves 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.