Skip to main content
Glama

Dart Kr

by io.github.pipeworx-io

Dart Search Filings

dart_search_filings
Read-onlyIdempotent

AUTHORITATIVE list of recent Korean corporate disclosures filed to DART (Korea's SEC equivalent). Returns rcept_no (receipt ID), rcept_dt (filing date), corp_name, report_nm (disclosure title), corp_code. Filter by company via corp_code (e.g., "00126380" Samsung Electronics; see pack docstring for major chaebol codes), filing date range, or filing type. Use for "what did Samsung file last week", "recent KOSPI material events", "this quarter's ownership changes".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bgn_deNoFiling date start (YYYYMMDD). Defaults to 30 days ago when omitted.
end_deNoFiling date end (YYYYMMDD). Defaults to today when omitted.
page_noNoPage number (1-based, default 1).
corp_codeNo8-digit DART corp identifier (Samsung 00126380, SK Hynix 00164779, etc.). Omit to list filings across ALL companies in the date range.
pblntf_tyNoDisclosure category: A (periodic report), B (major events), C (issuance), D (ownership change), E (audit), F (fund), G (asset-backed securities), H (foreign), I (subscriber). Omit for all.
page_countNoResults per page (1-100, default 10).

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the description doesn't need to restate safety. It adds useful behavioral details like default date ranges (30 days ago to today) and that omitting corp_code searches all companies, providing transparency beyond annotations.

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 a single, focused paragraph that front-loads the purpose and immediately lists key return fields. It uses no filler sentences and has a natural flow from purpose to filters to examples.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's core functionality, return fields, and filtering options. Although there is no output schema, the description mentions the key return fields (rcept_no, rcept_dt, etc.). It misses some nuances like pagination but is complete for most use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the description adds value by giving concrete examples for corp_code (e.g., '00126380' for Samsung) and expanding on pblntf_ty categories (e.g., 'B (major events)'). This enriches parameter understanding beyond the schema.

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 clearly states the tool provides an 'AUTHORITATIVE list of recent Korean corporate disclosures' from DART, with specific fields returned. It includes concrete use cases like 'what did Samsung file last week', distinguishing its purpose effectively.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage examples (e.g., filtering by company, date range, filing type) and specifies the tool is for recent filings. It doesn't explicitly mention when not to use or alternatives, but the context is clear enough for an AI agent.

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

All Dart Kr 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

A3.9/5.0
Disambiguation2/5

Multiple tools overlap heavily: ask_pipeworx_beta deliberately matches ask_pipeworx exactly right now, discover_tools and suggest_questions both serve as what-can-I-do entry points, and ai_visibility_check is just the single-entity version of scan_competitor_ai_presence. An agent will struggle to pick the right variant without carefully reading long descriptions.

Naming Consistency3/5

All tools are snake_case and several families share clear prefixes (dart_*, polymarket_*, ask_pipeworx_*), but the overall set mixes verb_noun (discover_tools, validate_claim), noun_phrase (entity_profile, deep_research), bare verbs (remember, recall, forget), and prefix-noun (dart_financials). Readable but not unified.

Tool Count2/5

36 tools is far above the 25+ heavy threshold, and the count is inflated by redundancy: ask_pipeworx_beta is a literal duplicate today, suggest_questions overlaps discover_tools, and ai_visibility_check is subsumed by scan_competitor_ai_presence. The broad Pipeworx platform justifies many tools, but the exposed surface is bloated.

Completeness4/5

The surface covers the apparent domain well: universal querying (ask_pipeworx family + deep_research), tool discovery, entity resolution, profiles, comparisons, change feeds, claim verification, Korean DART filings, Polymarket analysis/fill-risk, memory, subscriptions, and feedback. Minor gaps remain—there's no explicit fetch-by-citation-URI tool despite claims those URIs are fetchable, and no way to retrieve full DART filing text beyond discovery.

Resources