Skip to main content
Glama

MyDART

by kr.eocpa

search_audit_findings

Read-onlyIdempotent

MyDART MCP의 search_audit_findings 도구는 회사를 지정하지 않고 감사보고서 조건으로 상장사 목록을 찾습니다.

[Purpose]

  • List/aggregate: "의견거절 회사"·"내부회계 취약점 목록"·"○○회계법인 감사 회사".

  • Detail: get_audit_profile/get_internal_control; 원문: get_audit_report.

[Usage]

  1. "FY2024 코스피 의견거절 회사" → year=2024, market="kospi", opinion="disclaimer"

  2. 목록·집계만 필요 → fields="brief" (산문 제외·행 1/12)

  3. "24~25년 ICFR 취약점" → year=[2024,2025] (다년 — coverage.years[] 로 연도별 적재 확인)

[Response]

  • Output market Y=코스피/K=코스닥/N=코넥스; fs_div is KOREAN "연결"/"별도".

[Rules]

  • READ coverage.note FIRST — empty result over a non-ingested scope = "not seen", never "does not exist".

  • fs_div=both(default) → ≤2 rows/company: row count ≠ company count (dedupe by corp_code).

  • breakdown = population baseline in scope(year/market/fs_div) — finding filters ignored, scope ones not; ≠ count.

  • ICFR undetected: note ONLY on 연결(CFS) — "legitimately absent (<2조)" vs "expected-audit-but-missing"; 별도(OFS) has expected_type (or expected_type_note).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kamNoWhether 핵심감사사항(KAM) are present
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). Accepts a single year OR an array (e.g. [2024, 2025], max 10) for a multi-year query — rows then carry their own bsns_year and `coverage` returns a per-year breakdown (coverage.years[]).
limitNoCap on **rows** returned (SQL LIMIT applies to rows, not companies — with the default fs_div=both a company can occupy 2 rows, so the number of distinct companies shown is smaller than this cap). When the list is cut here, truncated=true while count still reports the full row count. To count companies, dedupe companies[] by corp_code — and if truncated=true that count is a floor, not the answer: narrow the scope (market·fs_div·asset_bucket) until truncated=false.
fieldsNoField width of each company row. full(default)=every field, incl. the 본문 산문 (의견근거·강조·기타·계속기업 text, KAM 제목 배열, ICFR 근거·취약점, applicability) — averages ~3,957 bytes/row. brief=list axis only, the same set as the 뷰어 스크리너 표: corp_name·corp_code·stock_code·bsns_year·market·fs_div·auditor·audit_opinion·going_concern·emphasis·other_matter·icfr{type,opinion}·kam_count·rcept_no (~318 bytes/row, 12x smaller — a whole 목록 fits in one response). Use brief for list/count asks and switch to full (or get_audit_report/get_internal_control) once a company is picked. coverage·breakdown·count·truncated are identical in both.full
fs_divNo재무제표 구분. CFS=연결, OFS=별도 (aliases consolidated/separate·연결/별도 also accepted). 별도 and 연결 are SEPARATE rows (의견·강조·KAM·ICFR are all held per 별도/연결). both = both (up to 2 rows per company), so row count ≠ company count — dedupe by corp_code when counting companies.
marketNo시장구분. Default all = every 상장사 (유가 kospi·코스닥 kosdaq·코넥스 konex are all loaded). Uppercase (KOSDAQ) and 한글 (코스닥/유가증권/코넥스/전체) aliases accepted.
auditorNoPartial match on 감사인명 (e.g. 삼정/한영/안진/삼일)
opinionNo감사의견 filter. unqualified=적정, qualified=한정, adverse=부적정, disclaimer=의견거절, modified=변형의견 (everything other than 적정: 한정/부적정/의견거절). 한글 values (적정·의견거절 etc.) also accepted.
emphasisNoPresence of 강조사항(EoM)
industryNo업종 — financial=금융 (KSIC 64~66: 은행·보험·금융지주 etc.), non_financial=비금융. The 주석 XBRL and ICFR 운영의무 thresholds differ between them. 한글 values (금융·비금융) also accepted.
asset_bucketNoSize bucket by 전기말 자산총액(별도). gte_2tn=2조이상, gte_500bn=5천억이상, gte_100bn=1천억이상, lt_100bn=1천억미만. 한글 values also accepted.
icfr_opinionNo내부회계관리제도 의견. adverse=부적정, disclaimer=의견거절 (covers both 감사 의견거절 and 검토 검토결론 불표명 — use icfr_type to tell 감사 from 검토), modified=변형 (everything other than 적정). 한글 values also accepted.
kam_requiredNoWhether KAM disclosure was mandatory by 규모·연도·시장 (적용시기 rules). kam=false & kam_required=true & kam_none_declared=false = suspected omission
other_matterNoPresence of 기타사항(OM)
going_concernNo계속기업 불확실성 mentioned in the 감사보고서
xbrl_requiredNoWhether 재무제표 주석 XBRL was mandatory for that year (적용시기 rules). Populated only after the backfill
include_referenceNoWhether to include the 적용시기 참조표 (full phase-in schedule for KAM·ICFR·XBRL 주석·자금부정통제, about 4.8KB). Each company row already carries its own verdict in the applicability field, so set true ONLY when you need the 법령 근거 text behind that verdict.
kam_none_declaredNoWhether the 감사보고서 explicitly declares '보고할 핵심감사사항 없음'. true=declared (kam_count=0 is then normal), false=undeclared or unknown. Combine with kam_count=0 to separate a genuine suspected omission from a declared absence
icfr_material_weaknessNoA 내부회계관리제도 중요한 취약점 exists

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds important behavioral rules beyond that: coverage.note must be read first, empty results over non-ingested scopes mean 'not seen' not 'does not exist', fs_div=both produces up to 2 rows per company, and ICFR absence semantics differ between 연결 and 별도. No annotation contradiction is present.

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 long but information-dense and well-structured with Purpose, Usage, Response, and Rules sections. Every section earns its place: examples are actionable, the response conventions prevent misreading output codes, and the rules prevent costly misinterpretations like treating missing coverage as nonexistence.

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 a 19-parameter tool with no output schema, this description is remarkably complete. It covers the tool's role, concrete invocation patterns, response format conventions, coverage caveats, row-count pitfalls, and ICFR-specific edge cases. The schema handles the remaining parameter detail, so nothing important is missing.

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?

Schema coverage is 100%, so the schema already documents all 19 parameters; the baseline is 3. The description adds genuine value by giving parameter-usage examples, recommending fields='brief' for list/count asks, explaining multi-year arrays via coverage.years[], and clarifying fs_div row implications. It does not need to restate every parameter.

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 specific verb and resource: it finds listed companies by audit report conditions without a company name. The [Purpose] section names concrete use cases and explicitly routes detail work to get_audit_profile/get_internal_control and raw text to get_audit_report, making sibling differentiation clear.

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?

It gives explicit when-to-use guidance: list/aggregate queries belong here, while detail and original-text queries belong to named sibling tools. Numbered examples map natural-language requests to concrete parameter values, so an agent knows exactly how to invoke it.

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