Skip to main content
Glama
649,985 tools. Updated 2026-10-11 04:26

"Dart" matching MCP tools:

  • Search companies registered with DART, South Korea's corporate disclosure system, by name, 6-digit stock code, or 8-digit DART corp_code. Returns the corp_code required by the other dart_* tools. Not this tool for: US registrants (use search_edgar_company). Japan, Taiwan and Europe have no search tool — reach them through query_db on the companies table. Args: - query: company name in Korean ('삼성전자') or English ('Samsung Electronics'), 6-digit KRX stock code ('005930'), or 8-digit corp_code - listed_only: restrict to KRX-listed companies (default true). Set false to include ~90k unlisted entities. - limit: max results, 1-50 (default 10) Returns: {count, companies: [{corp_code, corp_name, corp_name_en, stock_code}]} — corp_name is the Korean name DART registers, corp_name_en the registered English name where the company files one (about three quarters of Korean issuers). stock_code is null for unlisted companies. Match priority: exact stock code > exact Korean name > listed Korean partial > unlisted Korean partial > English name. English matching reads our own company table, so it covers issuers whose English name we hold, not every DART entity. Examples: - {query: '삼성전자'} -> corp_code 00126380, stock_code 005930 - {query: '카카오', listed_only: false} -> listed 카카오 plus unlisted same-name entities - {query: 'Samsung Electronics'} -> 삼성전자 (matched on the registered English name) Use when you need a corp_code or must disambiguate similar names. Don't use for US companies (use search_edgar_company). Errors: DART_API_KEY not configured; no match returns count 0 (not an error).
    ConnectorAPI key
  • Get daily OHLCV price history from the local finbridge database (populated by the nightly ingest jobs). Rows are returned newest first. Listed equities and ETFs. Japan and Europe carry no prices at all, and crypto is not served. 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' Account limits: a free account includes the most recent 130 trading sessions of each name. Results follow the current account's history entitlement. 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 crypto, which is not served. FinBridge has no real-time equity quote tool — equity prices here are end-of-day closes from the nightly ingest; the only live data is regulator filings (get_dart_filings / get_edgar_filings). 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).
    ConnectorAPI key
  • Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks. Call with NO args for a `trending_scan` of the top ~200 markets by weekly volume; pass `event` for the strongest per-event partition_check, or `topic` for a themed cross-event scan. `event` (recommended for a specific market): pass a Polymarket event slug like "fed-decision-may-2026" or "when-will-bitcoin-hit-150k"; walks child markets, checks date-axis / threshold-axis ordering AND computes the partition_check (sum of YES prices across mutually-exclusive legs — should ≈1; deviations >3pp emit a BUY/SELL EVERY LEG signal). `topic` (for cross-event scanning): pass a seed question like "Strait of Hormuz traffic returns to normal" or "Fed rate decision"; searches related events across the platform, flattens markets, runs the comparator on the union. Cross-event mode catches "...by May 31" vs "...by Jun 30" patterns that single-event misses. SEMANTIC ANCHOR: cross-event pairs require ≥0.30 Jaccard similarity on question tokens (prevents Powell-Fed-Pause being paired with Powell-DOJ-probe); skipped_low_similarity surfaces the rejected pair count. PARTITION FILTER: drops will-person-X / will-manager-Y / will-someone-else- placeholder slugs; partitions with >20% placeholder fraction return null arb signal. Response: opportunities[] (gap_pp, suggested_trade, reasoning, monotonicity violation context), and in event mode partition_check{sum_yes_prices, gap_from_1, placeholders_filtered, suggested_trade}. FEES: every opportunities[] row and partition_check.arbitrage carry edge_pp_gross (== gap_pp / overround_pp), fees_pp, edge_pp_net, net_positive, plus polymarket_fee_pp, fee_basis and fee_categories[]. BOTH cost components are modeled: Polymarket's own per-category TAKER FEE (fee = shares × rate × p × (1-p), rates crypto 0.07 / sports-economics-culture-weather-other 0.05 / finance-politics-mentions-tech 0.04, geopolitics and world events fee-free; verified against Polymarket's own docs as of 2026-09-13) and Polygon gas (~$0.02/leg). The taker fee dominates: ~$1.75 per 100 shares on a crypto market at 50c versus $0.02 of gas, so rows that looked profitable before fleet #1927 may now show net_positive:false — that is the correction, not a regression. Each leg is priced at ITS OWN market's rate and price (the fee curve peaks at 50c and falls toward both extremes). fee_basis says where the rate came from: 'payload' (read off the market, the normal case), 'category' (mapped from its fee category), 'fee_free', or 'fallback' (rate unknown — charged at the modal 0.05 rather than assumed free, so an unreadable market is never reported as costless). Where fill_check reprices against live depth, this does NOT double-count that spread cost. FILL CHECK: when the partition signal fires, arbitrage.fill_check prices it against live CLOB depth (theoretical_edge_pp_at_book vs realizable_edge_pp at 1000 shares/leg, thin_legs[]) — realizable_edge_pp ≤ 0 means the overround exists only at last-trade, not in the book; do not trade it. For custom sizing use polymarket_fill_risk.
    ConnectorNo auth
  • Extract the settlement clause of a single Polymarket or Kalshi market: who publishes the settling number (source), the clock time + timezone it is taken at, the precision of the computation (e.g. "1-minute candle close" vs "60-second trailing average" vs "election outcome"), the evidence standard (official_source | consensus_reporting | any_credible_report | unspecified), and void_handling (cancellation/postponement settlement — reused verbatim from bet_research's cancellation_rule detector, not re-derived). Parses Polymarket's `description` field (fetched via polymarket_market) or Kalshi's `rules_primary` + `rules_secondary` fields (fetched via kalshi_market) with regex + a small vocabulary — no LLM pass, so an unusual clause reports confidence:"low" rather than a guess. Pass `market` as a Polymarket slug/URL or a Kalshi market ticker (e.g. "KXBTCD-26SEP1317-T66999.99"); a Kalshi EVENT ticker (e.g. "KXBTCD-26SEP1317") also works — it picks one representative market under that event, since the settlement mechanism is normally shared across all strikes/legs in one event. Use this before treating a polymarket_kalshi_spread row as a real arbitrage: two ladders that look alike can settle on different sources, at different times, with different precision — this tool is how you check. Pair with resolution_diff to compare two markets directly. KNOWN GAP: idiosyncratic phrasing that doesn't match the vocabulary returns confidence:"low" and evidence_standard:"unspecified" rather than an LLM-guessed answer.
    ConnectorNo auth
  • Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks. Call with NO args for a `trending_scan` of the top ~200 markets by weekly volume; pass `event` for the strongest per-event partition_check, or `topic` for a themed cross-event scan. `event` (recommended for a specific market): pass a Polymarket event slug like "fed-decision-may-2026" or "when-will-bitcoin-hit-150k"; walks child markets, checks date-axis / threshold-axis ordering AND computes the partition_check (sum of YES prices across mutually-exclusive legs — should ≈1; deviations >3pp emit a BUY/SELL EVERY LEG signal). `topic` (for cross-event scanning): pass a seed question like "Strait of Hormuz traffic returns to normal" or "Fed rate decision"; searches related events across the platform, flattens markets, runs the comparator on the union. Cross-event mode catches "...by May 31" vs "...by Jun 30" patterns that single-event misses. SEMANTIC ANCHOR: cross-event pairs require ≥0.30 Jaccard similarity on question tokens (prevents Powell-Fed-Pause being paired with Powell-DOJ-probe); skipped_low_similarity surfaces the rejected pair count. PARTITION FILTER: drops will-person-X / will-manager-Y / will-someone-else- placeholder slugs; partitions with >20% placeholder fraction return null arb signal. Response: opportunities[] (gap_pp, suggested_trade, reasoning, monotonicity violation context), and in event mode partition_check{sum_yes_prices, gap_from_1, placeholders_filtered, suggested_trade}. FEES: every opportunities[] row and partition_check.arbitrage carry edge_pp_gross (== gap_pp / overround_pp), fees_pp, edge_pp_net, net_positive, plus polymarket_fee_pp, fee_basis and fee_categories[]. BOTH cost components are modeled: Polymarket's own per-category TAKER FEE (fee = shares × rate × p × (1-p), rates crypto 0.07 / sports-economics-culture-weather-other 0.05 / finance-politics-mentions-tech 0.04, geopolitics and world events fee-free; verified against Polymarket's own docs as of 2026-09-13) and Polygon gas (~$0.02/leg). The taker fee dominates: ~$1.75 per 100 shares on a crypto market at 50c versus $0.02 of gas, so rows that looked profitable before fleet #1927 may now show net_positive:false — that is the correction, not a regression. Each leg is priced at ITS OWN market's rate and price (the fee curve peaks at 50c and falls toward both extremes). fee_basis says where the rate came from: 'payload' (read off the market, the normal case), 'category' (mapped from its fee category), 'fee_free', or 'fallback' (rate unknown — charged at the modal 0.05 rather than assumed free, so an unreadable market is never reported as costless). Where fill_check reprices against live depth, this does NOT double-count that spread cost. FILL CHECK: when the partition signal fires, arbitrage.fill_check prices it against live CLOB depth (theoretical_edge_pp_at_book vs realizable_edge_pp at 1000 shares/leg, thin_legs[]) — realizable_edge_pp ≤ 0 means the overround exists only at last-trade, not in the book; do not trade it. For custom sizing use polymarket_fill_risk.
    ConnectorNo auth
  • Extract the settlement clause of a single Polymarket or Kalshi market: who publishes the settling number (source), the clock time + timezone it is taken at, the precision of the computation (e.g. "1-minute candle close" vs "60-second trailing average" vs "election outcome"), the evidence standard (official_source | consensus_reporting | any_credible_report | unspecified), and void_handling (cancellation/postponement settlement — reused verbatim from bet_research's cancellation_rule detector, not re-derived). Parses Polymarket's `description` field (fetched via polymarket_market) or Kalshi's `rules_primary` + `rules_secondary` fields (fetched via kalshi_market) with regex + a small vocabulary — no LLM pass, so an unusual clause reports confidence:"low" rather than a guess. Pass `market` as a Polymarket slug/URL or a Kalshi market ticker (e.g. "KXBTCD-26SEP1317-T66999.99"); a Kalshi EVENT ticker (e.g. "KXBTCD-26SEP1317") also works — it picks one representative market under that event, since the settlement mechanism is normally shared across all strikes/legs in one event. Use this before treating a polymarket_kalshi_spread row as a real arbitrage: two ladders that look alike can settle on different sources, at different times, with different precision — this tool is how you check. Pair with resolution_diff to compare two markets directly. KNOWN GAP: idiosyncratic phrasing that doesn't match the vocabulary returns confidence:"low" and evidence_standard:"unspecified" rather than an LLM-guessed answer.
    ConnectorNo auth

Matching MCP Servers

Matching MCP Connectors

  • DartOAuth

    AI-native project management for tasks, docs, collaboration, and agents.

  • DART — Korea's Data Analysis, Retrieval and Transfer System. The Korean

  • Find CO-OPS tide, water-level and current stations and NDBC buoys near a location, by name, or by station ID, returning a unified list with source, data capabilities, coordinates, and — for NDBC — the physical platform class. This is the required first step for resolving a place name, a coordinate pair, or a bare station number to the station IDs the data tools take: CO-OPS tide and water-level IDs are numeric (e.g. 9447130 for Seattle), CO-OPS current IDs are alphanumeric (e.g. ACT4176), and NDBC buoy IDs are 5-character alphanumeric codes (e.g. 46041). Two axes are reported separately — capabilities and type name the data products a station serves (tide, current, water_level, met, current_profile, water_quality), while platform is the NDBC physical classification (buoy, fixed, oilrig, dart, tao, usv, other) that CO-OPS stations do not carry. Supply latitude and longitude together for a proximity search, or query for a name-or-ID substring matched against both sources, or state for CO-OPS coverage in one state; the filters combine, and results lead with an exact ID match unless a proximity search is ordering them by distance. A search that matches nothing is a success with total_found: 0 carrying an echo of the filters that were applied, and a search whose catalogs did not all answer says which source is missing. CO-OPS prediction stations carry a third axis as well, prediction_class, which says what a station can actually answer: a tide station is either reference, serving both hilo and the 6-minute curve, or subordinate, serving hilo only, while a current station carries its class per depth bin in bins[] — a harmonic or subordinate bin serves the normal flood/ebb/slack series, and a weak_and_variable bin may instead answer noaa_marine_get_currents with a coverage statement and no events, or report that CO-OPS publishes no predictions for it at all, so prefer a harmonic bin when one is in range.
    ConnectorNo auth
  • 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).
    ConnectorAPI key
  • Realizable-vs-theoretical edge check against live CLOB order-book depth. REQUIRES one of `market` (single-market mode) or `event` (basket/partition mode). SINGLE-MARKET: pass a market slug/URL + side (buy_yes|sell_yes|buy_no|sell_no, default buy_yes) + size_usd (default 1000 — max spend on buys, target proceeds on sells); walks the ladder and returns top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, and a verdict (clean|degraded|cannot_fill). BASKET: pass an event slug/URL + side (sell_yes = capture overround by selling every leg, buy_yes = capture underround; default auto from partition sum) + size_usd interpreted as settlement notional S (shares per leg; each share pays $1); returns theoretical_sum vs realizable_sum (top-of-book vs VWAP across all legs), capture_ratio, profit_usd at executed size, per-leg fill detail, thin_legs[], max_clean_notional_usd, and forced_directional_risk naming the legs most likely to strand you unhedged. USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500 — theoretical overround on thin books is not capturable, and partial basket fills convert an arb into an unhedged directional position (the dominant loss mode in real arb-bot P&L). FEES ARE NOT MODELLED HERE: vwap_fill_price/profit_usd are GROSS of Polymarket's own taker fee (rate 0.04-0.07 by category — see polymarket_edges/fees.ts), on top of which this tool prices depth-crossing cost; a thin-margin fill that looks clean here can still be net-negative after the fee.
    ConnectorNo auth
  • Prices Kalshi daily high-temperature markets against the NWS forecast for the market's OWN settlement station, and measures whether that forecast actually beats the market. Two modes. LIVE (default): returns the full strike ladder for one city and settlement date with market_prob (mid), forecast_prob, and edge_pp per strike, plus the settlement clause verbatim. BACKTEST (`backtest_days: N`): scores an archived gridded forecast against the market on settled days and returns brier_market vs brier_forecast with a plain-English `verdict`, so the edge is MEASURED rather than asserted. READ THE WARNINGS — they are not boilerplate. (1) These markets DO NOT settle on the NWS. They settle on The Weather Company (weather.com) at a Kalshi station code such as CLINYC, which the response quotes verbatim; so part of every edge_pp is NWS-vs-Weather-Company disagreement about the same day at the same station, which is not mispricing and not tradeable. `settlement_vs_forecast_basis_f` from backtest mode is that part as a number. (2) The station is DERIVED from the settlement clause, never from the city name: Chicago settles at MIDWAY and New York at CENTRAL PARK, so a city-centre forecast would misprice a whole ladder. A station that cannot be resolved yields rows with no forecast and a reason, never a guessed coordinate. (3) forecast_prob assumes a normal distribution around the NWS high whose width is ASSUMED, not fitted (stated in `distribution_assumption`) — run backtest mode to see whether it is calibrated. (4) edge_pp is gross: no Kalshi fees, no bid-ask. MEASURED RESULT, AND IT IS NOT THE FLATTERING ONE: on the first backtest (KXHIGHNY, 13 settled days to 2026-09-11, 58 market observations) the MARKET beat the forecast — Brier 0.1008 for the market against 0.1594 for the archived gridded forecast, lower being better. So on that sample there is NO forecast edge to sell, and a large edge_pp is more likely to be the model disagreeing with a better-informed market than an opportunity. The measured settlement-vs-forecast basis was 1.7F mean absolute over 8 pinnable days, slightly warm-biased, which is a big share of a typical edge_pp on a 2-degree bracket. Re-run backtest_days before believing any edge; if a later sample reverses this, the numbers say so. NWS is US-only, so the ~30 international Kalshi weather series (London, Paris, Tokyo) return market prices with forecast_unavailable rather than a forecast. Precipitation series are listed but not yet priced. Cities: nyc, chicago, los angeles, miami, austin, houston, denver, philadelphia — or pass `series_ticker` for any other (e.g. "KXHIGHTBOS").
    ConnectorNo auth
  • Tell the Pipeworx team something is broken, missing, or needs to exist. Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise). ONLY for tools served by this Pipeworx connection — if the tool came from a different MCP server in your client (another vendor's Gmail, Splunk, Slack, etc. connector), we cannot fix it and reporting it here only delays you; file it with that server instead. Not sure? Pipeworx tool names are the ones this connection lists. Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt. Filing without an account returns a `claim_token`; pass it back later as pipeworx_feedback({claim_token:"pwfb_…"}) to read whether it was fixed and what changed. The team reads digests daily and signal directly affects roadmap. Rate-limited to 5 per identifier per day. Free; doesn't count against your tool-call quota.
    ConnectorNo auth
  • Basic profile for a Korean DART-registered company: corp_name (Korean + English), KRX stock_code if listed, CEO name, market tier (KOSPI/KOSDAQ/KONEX/etc.), industry code, address, founding date, fiscal-year-end month, homepage. Use after dart_search_filings to enrich a corp_code into a readable entity, or as the first lookup when an agent is given a corp_code with no other context.
    ConnectorNo auth
  • Realizable-vs-theoretical edge check against live CLOB order-book depth. REQUIRES one of `market` (single-market mode) or `event` (basket/partition mode). SINGLE-MARKET: pass a market slug/URL + side (buy_yes|sell_yes|buy_no|sell_no, default buy_yes) + size_usd (default 1000 — max spend on buys, target proceeds on sells); walks the ladder and returns top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, and a verdict (clean|degraded|cannot_fill). BASKET: pass an event slug/URL + side (sell_yes = capture overround by selling every leg, buy_yes = capture underround; default auto from partition sum) + size_usd interpreted as settlement notional S (shares per leg; each share pays $1); returns theoretical_sum vs realizable_sum (top-of-book vs VWAP across all legs), capture_ratio, profit_usd at executed size, per-leg fill detail, thin_legs[], max_clean_notional_usd, and forced_directional_risk naming the legs most likely to strand you unhedged. USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500 — theoretical overround on thin books is not capturable, and partial basket fills convert an arb into an unhedged directional position (the dominant loss mode in real arb-bot P&L). FEES ARE NOT MODELLED HERE: vwap_fill_price/profit_usd are GROSS of Polymarket's own taker fee (rate 0.04-0.07 by category — see polymarket_edges/fees.ts), on top of which this tool prices depth-crossing cost; a thin-margin fill that looks clean here can still be net-negative after the fee.
    ConnectorNo auth
  • Prices Kalshi daily high-temperature markets against the NWS forecast for the market's OWN settlement station, and measures whether that forecast actually beats the market. Two modes. LIVE (default): returns the full strike ladder for one city and settlement date with market_prob (mid), forecast_prob, and edge_pp per strike, plus the settlement clause verbatim. BACKTEST (`backtest_days: N`): scores an archived gridded forecast against the market on settled days and returns brier_market vs brier_forecast with a plain-English `verdict`, so the edge is MEASURED rather than asserted. READ THE WARNINGS — they are not boilerplate. (1) These markets DO NOT settle on the NWS. They settle on The Weather Company (weather.com) at a Kalshi station code such as CLINYC, which the response quotes verbatim; so part of every edge_pp is NWS-vs-Weather-Company disagreement about the same day at the same station, which is not mispricing and not tradeable. `settlement_vs_forecast_basis_f` from backtest mode is that part as a number. (2) The station is DERIVED from the settlement clause, never from the city name: Chicago settles at MIDWAY and New York at CENTRAL PARK, so a city-centre forecast would misprice a whole ladder. A station that cannot be resolved yields rows with no forecast and a reason, never a guessed coordinate. (3) forecast_prob assumes a normal distribution around the NWS high whose width is ASSUMED, not fitted (stated in `distribution_assumption`) — run backtest mode to see whether it is calibrated. (4) edge_pp is gross: no Kalshi fees, no bid-ask. MEASURED RESULT, AND IT IS NOT THE FLATTERING ONE: on the first backtest (KXHIGHNY, 13 settled days to 2026-09-11, 58 market observations) the MARKET beat the forecast — Brier 0.1008 for the market against 0.1594 for the archived gridded forecast, lower being better. So on that sample there is NO forecast edge to sell, and a large edge_pp is more likely to be the model disagreeing with a better-informed market than an opportunity. The measured settlement-vs-forecast basis was 1.7F mean absolute over 8 pinnable days, slightly warm-biased, which is a big share of a typical edge_pp on a 2-degree bracket. Re-run backtest_days before believing any edge; if a later sample reverses this, the numbers say so. NWS is US-only, so the ~30 international Kalshi weather series (London, Paris, Tokyo) return market prices with forecast_unavailable rather than a forecast. Precipitation series are listed but not yet priced. Cities: nyc, chicago, los angeles, miami, austin, houston, denver, philadelphia — or pass `series_ticker` for any other (e.g. "KXHIGHTBOS").
    ConnectorNo auth
  • Tell the Pipeworx team something is broken, missing, or needs to exist. Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise). ONLY for tools served by this Pipeworx connection — if the tool came from a different MCP server in your client (another vendor's Gmail, Splunk, Slack, etc. connector), we cannot fix it and reporting it here only delays you; file it with that server instead. Not sure? Pipeworx tool names are the ones this connection lists. Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt. Filing without an account returns a `claim_token`; pass it back later as pipeworx_feedback({claim_token:"pwfb_…"}) to read whether it was fixed and what changed. The team reads digests daily and signal directly affects roadmap. Rate-limited to 5 per identifier per day. Free; doesn't count against your tool-call quota.
    ConnectorNo auth
  • Answers "which stocks scored highest on measured DART financials?" — kind='growth' is 성장 TOP8 (max 8 rows), kind='quiet' is 조용한 실적주. Scores come from a published formula over ACTUAL filed financials only — no prices, no analyst estimates. Mechanical, not stock picks. For 52-week high/low or turnaround LISTS use list_stocks(). | "실측 재무로 점수가 높은 종목"에 답합니다 — growth 는 최대 8건, quiet 는 조용한 실적주. 시세·전망치를 쓰지 않고 DART 실측 재무만 씁니다. 52주 신고저·흑자전환 목록은 list_stocks().
    ConnectorNo auth
  • MyDART MCP의 find_corp_code 도구는 회사명·종목코드로 DART 법인 식별자(corp_code)의 후보를 확인합니다. [Purpose] - IMPORTANT: first call when a company's corp_code is unknown. - Also to disambiguate same-named companies. - ID resolution only — 업종·data location: get_company_profile; disclosure listings: search_disclosures. [Usage] 1. "카카오" → corp_code 획득 → 재무제표 조회(get_financials) 2. "삼성전자" → corp_code 획득 → 임원 현황 조회(get_periodic_report) 3. "'동양' 들어가는 회사 후보 보여줘" → query="동양", limit=20 4. "005930이 어느 회사야?" → query="005930" [Response] - stock_code: present = listed (common shares); empty/absent = unlisted. - count = rows returned (capped by `limit`), not the total match count. 0 hits adds `notes`. [Rules] - `results` is a similarity-ranked candidate array — do not assume the first item is the answer. - corp_code identifies the DART LEGAL ENTITY CODE, not the listing ticker. 우선주 codes map to the 보통주 issuer; ETF/ETN codes have no mapping. - Common names may overflow the default `limit` — raise it when candidates look truncated.
    ConnectorNo auth
  • MyDART MCP의 get_corporate_event 도구는 주요사항보고서 자본·지배구조 이벤트 36종(증자·감자·CB/BW/EB·자기주식·합병/분할 등)과 5%룰·임원 지분공시를 조회합니다. [Purpose] - "Who raised/cut stakes, when": event_type="holdings" (5%룰 대량보유·임원/주요주주 소유보고). - 결정의 후속 발행·합병 조건(공모가·인수인): get_registration_statement. - List skims: search_disclosures; 사업보고서 snapshots (최대주주·주식총수): get_periodic_report. [Usage] 1. "카카오 최근 3년 자본 조달 흐름" → corp="카카오", mode="timeline" 2. "이 회사 CB 발행한 적 있어?" → corp="…", event_type="cb_issuance" 3. "자사주 취득·처분 2020년부터" → event_type=["treasury_acquisition","treasury_disposal"], start="2020-01-01" [Response] - date = 최초 공시일 (start/end axis), newest first; fields = latest 정정본 (rcept_no) — first_rcept_no if corrected. - 지분공시: total_count = all-time cumulative, filtered_count = in-period (DART takes no dates — filtered client-side). [Rules] - Empty timeline ≠ no events — default set = capital events only (name event_type for more); sections_meta may carry per-endpoint errors. - event_type_counts is pre-truncation (limit cuts timeline only).
    ConnectorNo auth
  • List major-event disclosures (주요사항보고서, DART type B): capital increases, mergers, convertible bonds, treasury stock, bankruptcy, lawsuits, etc. Optionally filter report names with a regex. Not this tool for: the full disclosure list or other report categories (get_dart_filings — periodic reports, securities issuance, ownership, KRX notices), US 8-K events (get_edgar_filings), or the cross-market stored feed (get_disclosure_feed). What this adds over get_dart_filings type='B': a 'kinds' regex over Korean report names (e.g. '증자|합병|전환사채'), a 180-day default window tuned for event scans, and matched-count totals — so use it when the question is 'which companies announced X', not 'what did company Y file'. Args: - corp: optional — Company: Korean name (e.g. '삼성전자'), 6-digit stock code (e.g. '005930'), or 8-digit DART corp_code (e.g. '00126380'). Omit for market-wide events. - from / to: YYYY-MM-DD (default: last 180 days) - kinds: optional JavaScript regex matched against the Korean report name, e.g. '증자|합병|전환사채' (capital increase | merger | CB) or '자기주식' (treasury stock). Filtering runs over every event in range when FinBridge's index covers the window, otherwise over the most recent 100 events DART returns. - limit: max results, 1-100 (default 20) Returns: {total, page, filings: [{rcept_no, corp_name, report_nm, flr_nm, rcept_dt, url}]} — same shape as get_dart_filings. When kinds is given, total = matched count within the scanned window. Examples: - {corp: '삼성전자', kinds: '자기주식'} -> Samsung treasury-stock decisions in the last 180 days - {kinds: '유상증자', from: '2026-01-01', to: '2026-06-30'} -> market-wide rights offerings in H1 2026 Use when: event-driven screening (rights offerings, mergers, CBs, treasury stock, lawsuits) market-wide or for one company. For every filing category, or when you already know the report you want, use get_dart_filings. Errors: no events in range (DART status 013) -> widen dates; invalid kinds regex; unknown company -> search_dart_company.
    ConnectorAPI key
  • Korean insider transactions for a listed KR company, from DART's 임원ㆍ주요주주 특정증권등 소유상황보고서 (elestock) — the Korean equivalent of SEC Form 4. Includes a buy-vs-sell summary and an optional buy/sell filter. Not this tool for: US insiders (get_edgar_insider_trades) or institutional managers, which are a different kind of holder entirely (get_edgar_13f). Buy vs sell is the SIGN of the reported share change (증감수): positive = 취득 (acquire / buy), negative = 처분 (dispose / sell). Insider BUYING is a stronger sentiment signal. Args: - company (required): KR 6-digit stock code (e.g. '005930'), company name, or 8-digit DART corp_code - limit: number of most-recent reports to return, 1-100 (default 20) - tx_type: 'all' (default) | 'buy' (share change > 0) | 'sell' (share change < 0) - response_format: 'markdown' (default) or 'json' Returns: {company:{corp_code, corp_name}, tx_type, summary:{buys:{count,shares}, sells:{count,shares}}, count, trades:[{filedAt, reporter, position, registered_exec, major_shareholder, change, shares_after, change_rate}], notes}. summary totals cover the whole fetched set regardless of the filter. Important: this elestock summary API does not provide transaction dates or prices. filedAt is the filing date, not the transaction date. The underlying filing may contain these details; use get_dart_document with the returned rcept_no to inspect its tables. Examples: - "삼성전자 임원 매수" -> {company:'005930', tx_type:'buy'} - "SK하이닉스 내부자 매도 최근" -> {company:'000660', tx_type:'sell'} Use when: monitoring KR officer / major-shareholder buy/sell activity. For US insiders use get_edgar_insider_trades. For institutional holdings use get_edgar_13f. Errors: unknown company -> use search_dart_company; a filter with no matches returns count 0 (not an error).
    ConnectorAPI key
  • Inspect the schema of the local finbridge database (SQLite with ingested KR/US company fundamentals, filings, and daily prices): tables, views, columns, per-table row counts (counted in the background and refreshed every 30 minutes; null with rows_note "counting…" right after a server start), and ready-to-run example queries for query_db. Read this before writing a query_db statement. It returns no company data itself — get_db_schema describes the tables, query_db runs the SELECT. Args: (none) Returns: {tables: [{name, columns: [{name, type}], rows}], views: [{name, columns: [{name, type}]}], examples: [sql_string]} Key objects: - companies: KR companies have source='dart' + stock_code (6-digit), US companies source='edgar' + ticker - financials: one row per company x fiscal_year x quarter (quarter=0 = annual); raw unscaled KRW/USD amounts - prices_daily: daily OHLCV per company_id - views v_financials (financials joined with company name/ticker/stock_code) and v_latest_annual (latest annual row per company) — prefer these in query_db Examples: - Call before writing SQL for query_db, to learn table/column names. - Check row counts to see how much data the nightly ingest has loaded. Use when: preparing a query_db, or checking ingest coverage. Don't use for market data itself (get_stock_prices / get_valuation read the same tables with the right joins already done). FinBridge has no real-time equity quote tool — equity prices here are end-of-day closes from the nightly ingest; the only live data is regulator filings (get_dart_filings / get_edgar_filings). Errors: 'database has not been built yet' — the ingest pipeline has not run on the server.
    ConnectorAPI key