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?, summary_status?, 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.

summary_status (with brief:true): 'ok' = summary attached; 'withheld_review' = a summary exists but failed our accuracy/wording checks and is withheld pending review (title+URL only — read the filing); 'not_generated' = no summary for this filing yet. 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

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

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026
- addedOutput schema / properties / rows / items / properties / summary_status
```
Added value: +{
+  "$ref": "#/properties/market"
+}
```

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 declare readOnlyHint=true / destructiveHint=false, and the description adds substantial non-obvious behavior: nightly + intraday KR refresh, default material_only semantics, that 'company' takes priority over the watchlist, that watchlist needs a personal API key, that forms overrides material_only, the summary_status states ('ok'/'withheld_review'/'not_generated'), and that empty results are not errors.

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?

Front-loaded with purpose and args, and the ordering is logical. However the Returns block restates the shape that already lives in the output schema, and the Args/Examples/Notes sections partially duplicate each other, so it runs longer than strictly necessary.

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 an 11-parameter, zero-required, read-only feed with an output schema, the description covers everything the agent needs: default behaviors, override precedence, auth caveats, the summary_status vocabulary, error semantics, and the boundary against body-retrieval tools.

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% (baseline 3), yet the description still adds precedence and interaction semantics the schema does not encode: from/to overriding days, company taking priority over watchlist, forms overriding material_only, watchlist ignored when company is set, and the range bounds for days/limit.

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 (recent regulatory disclosures) with concrete scope: which database/table, freshness cadence, and default material-only filtering across US 8-K and KR 주요사항보고서. It is clearly distinguishable from the market-specific siblings get_dart_filings and get_edgar_filings because it spans both markets in one feed.

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' (scanning for catalysts/breaking corporate events, or one company's recent filings) and 'Don't use for' that names the alternatives for excluded cases (filing bodies at the url; get_dart_financials / get_edgar_financials / query_db for statement values). Four concrete invocation examples further route the agent.

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.