Skip to main content
Glama

MyDART

by kr.eocpa

get_going_concern

Read-onlyIdempotent

MyDART MCP의 get_going_concern 도구는 계속기업가정 관련 위험을 정량 재무지표와 감사보고서 언급 여부의 교차로 판정합니다.

[Purpose]

  • 계속기업 risk — esp. "figures risky, 감사인 silent" mismatches.

  • Lists: search_audit_findings; figures: get_financials; 문단 원문: get_audit_report.

[Usage]

  1. "이스타코 2024 계속기업 위험 있어?" → corp="이스타코", year=2024

  2. "별도 기준 정량 점검" → corp="…", year=2024, fs_div="OFS"

[Response]

  • flags.consecutive_op_loss = NUMBER of 연속 영업손실 years (not a bool); others bool|null.

  • grade: 판정불가(no data)/양호(0)/주의(12)/경계(34)/위험(5+)

  • cross_check.code: both/quant_only/text_only/none/insufficient_data/quant_unavailable/report_unavailable

[Rules]

  • NEVER read text.going_concern_mentioned null (report not secured = unknown) as false (checked, no mention).

  • quant_only covers TWO cases — risky figures with no mention confirmed, OR with report not secured; distinguish via going_concern_mentioned (false vs null).

  • grade "판정불가" is not "양호". flags null = account not secured, not false.

  • Response fs_div is post-fallback — a CFS request may return OFS.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
corpYes회사명/종목코드/corp_code
yearYes결산 사업연도 (회계연도, fiscal year) — the number you pass IS the 사업연도=회계연도=결산연도. Do NOT subtract it; pass it as-is. Only tools where year is optional auto-select the latest published year when omitted (if year is required in the tool you are calling, it cannot be omitted — confirm the year actually used via the response `year` field).e.g. 'FY2025'·'2025년 재무제표'·'2025 사업보고서'·'2025 회계연도' → all 2025 (결산일 2025-12-31). Convert ONLY when the user explicitly names the 공시(제출)연도, as in '○○년에 공시된 보고서': a 12월 결산법인 files by the end of March of the following year.(e.g. '2026년에 공시된 사업보고서' → 2025). Otherwise the input is ALWAYS on a 사업연도=회계연도=결산연도 basis. Relative expressions ('최근 N개년'·'작년' and the like) count back from the most recent PUBLISHED 사업연도 as of today: a 사업보고서 is filed within about 90 days after 결산 (12월 결산 법인 → March of the following year), so from April the latest is last year, and in Jan~Mar it is the year before last. e.g. if today is 2026-06 the latest is FY2025 → '최근 5개년'=2021~2025 (NOT 2020~2024). Supported floor is FY2015 (the range OpenDART's structured APIs cover) — 2014 and earlier are rejected. A 비12월 결산 (3·6·9월) 법인 may have its latest 사업연도 equal to the calendar year (e.g. a 3월 결산 company from July onward).
fs_divNo연결(CFS)/별도(OFS), default CFS. Falls back to 별도 automatically when 연결 is absent (the response fs_div reports the basis actually used). Aliases consolidated/separate·연결/별도 also accepted.
refreshNoBypass the cache and re-collect

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already carry readOnlyHint/openWorldHint/idempotentHint/destructiveHint, lowering the bar. The description goes well beyond them: flags.consecutive_op_loss is a NUMBER not a bool, exact grade tiers, cross_check.code enumeration, null-vs-false semantics for going_concern_mentioned, and the post-fallback fs_div behavior. No contradiction with annotations (read-only judgment tool matches readOnlyHint=true; open-world null handling matches openWorldHint).

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?

Well-organized with [Purpose], [Usage], [Response], and [Rules] headers, with the purpose front-loaded. It is long, but every section earns its place — the Rules section delivers essential null/boolean and fallback semantics that materially affect correct invocation. Dense yet scannable.

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?

Given the tool's complexity (a cross-analysis of financial figures and audit text) and the absence of an output schema, the description documents return semantics thoroughly: flag types, grade tiers, cross_check codes, null handling, and fallback behavior. Nearly everything an agent needs to call it and interpret results is present; only exhaustive flag enumeration is left implicit.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all four parameters — baseline is 3. The description adds little beyond usage examples mapping natural-language queries to corp/year/fs_div and reiterating the fs_div fallback already stated in the schema. It reinforces usage but does not add meaning the schema already provides.

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 precise purpose: judging going-concern risk via the cross of quantitative financial indicators and audit-report mention. It also explicitly maps sibling tools to their niches (search_audit_findings for lists, get_financials for figures, get_audit_report for paragraph text), so an agent can tell this tool apart without opening other schemas.

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?

Provides concrete example queries with direct parameter mappings ('이스타코 2024 계속기업 위험 있어?' → corp, year; '별도 기준 정량 점검' → fs_div="OFS"). The Purpose section names the alternative tools and their distinct functions, giving explicit routing guidance for when this tool vs. others applies.

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

All MyDART 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.7/5.0
Disambiguation5/5

Every tool targets a distinct aspect of the DART disclosure domain: full text, attachments, financial figures, audit facts, audit narrative, ICFR, going concern, company profile, events, periodic report sections, XBRL, valuation, usage stats, and two search entry points. Overlaps are resolved by explicit cross-references and clear purpose statements (e.g., get_audit_profile vs get_audit_report vs get_internal_control). No ambiguity remains.

Naming Consistency5/5

All 16 tools follow a consistent snake_case verb_noun pattern, with get_ for data retrieval, search_ for list queries, find_ for ID resolution, and download_ for the one document fetch. There is no mixing of camelCase, action words, or stylistic inconsistency. The pattern is immediately predictable.

Tool Count5/5

16 tools is slightly above the typical 3–15 range but fully justified by the breadth of DART (Korea's electronic disclosure system) – covering company lookup, filings, financials, audit reports, internal control, going concern, events, periodic reports, attachments, XBRL, valuation, and usage stats. Each tool address a distinct functional need, and no tool feels redundant or extraneous. The scope is comprehensive yet not bloated.

Completeness5/5

The tool surface covers the full lifecycle of disclosure data access: finding entities (find_corp_code), locating filings (search_disclosures), retrieving financials (get_financials, get_xbrl), reading full text (download_document), fetching attachments (get_attachments), and drilling into audit-related details (get_audit_profile, get_audit_report, get_internal_control, get_going_concern). Periodic report sections (28 types) and corporate events cover governance and capital changes. No obvious dead ends or missing critical operations for a read-only disclosure access server.

Resources