Skip to main content
Glama

get_periodic_report

Read-onlyIdempotent

MyDART MCP의 get_periodic_report 도구는 사업보고서 세부 섹션 28종을 정형 데이터로 조회합니다 — 한 섹션 또는 여러 섹션 동시.

[Purpose]

  • Section tables: 배당·자기주식·최대주주·소액주주·임원보수·회계감사인·회사채 미상환 등.

  • 재무제표 figures: get_financials. auditor_opinion is one word — KAM·내부회계·강조사항: get_audit_profile / get_audit_report.

[Usage]

  1. "삼성전자 2025년 배당 내역" → corp="삼성전자", year=2025, report_type="dividends"

  2. "카카오 최대주주가 누구야" → corp="카카오", report_type="shareholders" (year 생략 = 최신)

[Response]

  • Amounts are STRINGS. Section status: 000 성공 / 013 무자료.

  • periods legend maps 당기/전기/전전기 → fiscal years — cite 기수 only after reading it.

[Rules]

  • Non-December closer: quote fiscal_year_note verbatim — one year off vs the audit tools.

  • ARRAY: per-element status (success·013·error mix); all-013 flips to { mode:"no_data", … }.

  • Listed [013] ≈ legitimate absence (no 배당·자기주식, no eligible 개인별 보수), not failure.

  • 개인별 보수 2종은 2026-05 서식 개정으로 구판↔V2 이원 — 도구가 자동 라우팅(endpoint· compensation_format 표시). V2 는 1인당 3행(당기·전기·전전기)이라 합계는 fscl_year="당기"만, 주식기준보상 세부는 stk_bsd_cmpn.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
corpYes회사명/종목코드/corp_code
yearNo결산 사업연도 (회계연도) — the FISCAL year, NOT the filing year. When omitted, the most recently PUBLISHED year is selected automatically, based on 결산월(acc_mt) and report type. Confirm the year actually used via year/year_defaulted in the response.
reportNoReport typeannual
max_itemsNoCap on rows returned per section (default 150). The excess is cut and flagged via truncated=true, and total_count then carries the real row count — this keeps responses from bloating on row-heavy, prose-heavy sections such as 임원현황·타법인출자·채무증권.
report_typeYes28 sections — **a single string OR an array** (an array is collected in parallel and returned as sections[]). Families: 주주 4 (largest_shareholder etc.) / 임직원 3 (executives etc.) / 보수 6 (executive_compensation_* etc.) / 회계감사 3 (auditor_opinion etc.) / 자본 3 (dividends·treasury_stock etc.) / 자금사용 2 (*_fund_use) / 타법인출자 1 / 채무증권 6 (*_unredeemed etc.). See the enum list for exact value names (the name IS the meaning). Group aliases expand to their members too — 'shareholders' (주주 4) and 'executive_compensation' (보수 6).

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark the operation as readOnly, idempotent, and non-destructive, and the description builds on that rather than repeating it. It adds rich runtime behavior beyond annotations: amounts are strings, status codes 000/013, full-array 013 flips to no_data mode, 013 can be a legitimate absence, fiscal-year alignment can differ for non-December clorders, and V2 routing is automatic for comp sections.

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?

The content is well organized into Purpose/Usage/Response/Rules and front-loads the main action. It is dense and uses a mixed Korean-English style with some repeated 013 themes, but every section earns its place and the structure makes the complexity navigable.

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?

Given the 28-section parameter, lack of output schema, and many caveats, the description is remarkably complete. It covers status handling, no-data modes, fiscal-year mapping, string formatting, array error behavior, and even compensates any auto-routing specifics needed for newer section variants.

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 baseline is 3 even without parameter guidance. The [Usage] examples reinforce parameter selection, but the schema already defines corp, year, report, max_items, and report_type, including group aliases and allowed values; the description does not add substantial new parameter semantics beyond that.

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 first sentence states a specific verb and resource: it retrieves 28 business-report detail sections as structured data, either one section or multiple. The [Purpose] section also distinguishes it from get_financials and get_audit_profile/get_audit_report, so it is easy to tell apart from close siblings.

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?

The description includes explicit usage examples mapping user requests to corp, year, and report_type, and explains what happens when year is omitted. It also names alternatives for financial-statements and auditor-opinion detail, giving practical routing guidance instead of leaving the choice to inference.

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

Try in Browser

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