Skip to main content
Glama

get_attachments

Read-onlyIdempotent

MyDART MCP의 get_attachments 도구는 공시의 첨부파일 목록과 형제문서 본문·페이지 이미지를 다룹니다.

[Purpose]

  • Attachment list + 형제문서 routing; body text = mode=text (뷰어 원문), 구조 보존은 download_document.

  • 자금부정통제 붙임·경영진 운영실태보고서 live here (mode=text; 붙임 = attachment_links[].retrieve).

  • Scan-only (도장·서명·스캔 서식): mode=images only.

[Usage]

  1. 정관·영업보고서 본문 → list 로 dcm_no 확보 → dcm_no, mode="text"

  2. 표가 이미지뿐이면 mode="images" (뒷장 image_from, PDF 페이지 pages)

[Response]

  • format: hwpx/hwp/pdf/docx/doc/xlsx/xls/zip/html/unknown

  • images: source="viewer" or "pdf" — different field shapes.

[Rules]

  • supported:false → unsupported_reason·suggestion·note·retrieve·next_step = the fallback route; follow it verbatim.

  • No bulk sweeps — mass viewer calls bring DART IP bans.

  • Ladder: text (표 lossless) → empty·링크 껍데기 body → images → download_url. Attachment files are never parsed server-side.

  • images returns pictures: OCR·판독 is the client's job, 1 image per capped call (image_from).

  • partial:true ⇒ section_errors[]; markdown is partial — 빈 곳 ≠ 사실 없음.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNolist: the attachment list only — nothing is downloaded, so it is the cheap call. text: the document body as 마크다운 via the 뷰어 원문 (XML→HTML) path — it skips PDF conversion, so text and tables are lossless and it is hundreds of times lighter. The primary path for sibling documents (정관·영업보고서·운영보고서 etc.) and the route to take whenever body text is what you want. images: return embedded images (도장·스캔본·차트 and other raster that text cannot capture). With NO filename/index it takes the 뷰어 원본 JPEG route (manifest.source="viewer": originals in document order, per-section eleId); with filename or index it scans THAT attachment PDF instead (source="pdf": decoded PNGs, largest area first, with page numbers; pages narrows it). The two routes return different field shapes. There is no file-parsing mode: an attachment file itself is reached through download_url, never parsed server-side.list
indexNo0-based index of the attachment to scan, in images mode (filename takes precedence). Like filename it picks the PDF-scan route; omit both to get the 뷰어 임베드 원본 JPEG.
pagesNoPage filter for images mode (1-based, PDF-scan path only). e.g. "3", "1-5", "2,4,7-9". It narrows pages WITHIN the attachment picked by filename/index, so it requires one of them. Unset on a filename/index call = a scan of only that PDF's FIRST 40 pages. At most 2000 pages per call — a wider span is rejected, not silently trimmed.
dcm_noNoTarget 문서번호(dcmNo). Defaults to the 본문 document. One 공시(rcept_no) carries, besides the 본문, sibling documents (감사보고서·내부회계관리제도운영보고서·영업보고서·정관 etc.) each with its own dcmNo; take sibling_documents[].dcm_no from a list result to read that document (list its attachments, or mode=text/images). A sibling's attachments are invisible without it — always list first, then pass sibling_documents[].dcm_no.
filenameNoExact filename of the attachment to scan, in images mode (no partial-match fallback). Giving it PICKS the PDF-scan route — omit both filename and index to get the document's 뷰어 임베드 원본 JPEG instead. An EXACT match is required; on failure the error lists the available names.
rcept_noYes14-digit 접수번호 (separators are stripped automatically)
sectionsNoWhich sections to fetch, in mode="text" — the **sections[] array index** (0-based). NOT the eleId: in these documents eleId runs "1".."8", so eleId happens to equal index+1 and is easy to confuse. e.g. to read the 3rd and 6th entries of sections[], pass [2, 5]. Unset = the previous behavior (the first 24 sections, all fetched). [] = 목차 only — zero body calls, sections[] carries just the titles (md_chars all 0); read them, then call again with the indices you want (2-pass). The pick happens BEFORE the 24-node ceiling, so it reaches sections 25~158 of a 사업보고서 본문 that are otherwise unreachable at any truncate_at. Max 24 picks; out-of-range indices are dropped with a note in `notes` (all-out-of-range is rejected). In this mode every sections[] entry carries its own index — check it against what you asked for (an off-by-one that stays in range otherwise returns a neighbouring section silently).
image_fromNoStart offset in document order for the 뷰어 원본 JPEG route (0-based, default 0). Channels with a response cap fit only ~1 scan page per call, so this is how you reach later pages — e.g. the 자금부정통제 표 is usually the 2nd page of an 운영실태보고서, so image_from=1. The response carries `from` and a note telling you the next offset. PDF-scan route uses pages instead.
max_imagesNoMax images returned in images mode (largest area first). Default 12.
truncate_atNoMax length of the mode=text 마크다운 (default 100,000 chars; out-of-range values are clamped to the bound)
min_dimensionNoIn images mode, an image whose shorter side is under this many pixels is treated as decoration (아이콘·괘선) and dropped. Default 24. Lower it to catch small 도장/서명. It filters the PDF-scan path only (source:"pdf") — 뷰어 원본 JPEG images pass through unfiltered.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only indicate read-only/idempotent behavior, so the description carries the transparency burden and succeeds. It discloses IP-ban risk, that attachment files are never parsed server-side, that OCR is the client's job, and that partial:true means empty sections are not evidence of absence.

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 description is well-structured with Purpose/Usage/Response/Rules headers and front-loaded scope. It is long, but the tool is complex; it earns a 4 rather than 5 because some content overlaps with the already-detailed parameter descriptions.

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 complexity of a multi-mode tool with 11 parameters and no output schema, the description covers modes, response formats, fallback behavior, and operational guardrails. The only minor gap is that the exact shape of the list response is not spelled out in one place, though it is inferable from schema and usage examples.

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 baseline is 3, but the description adds routing semantics beyond the schema: mode=text for body text, mode=images for scans, dcm_no acquisition from list results, and image_from/pages selection guidance. It stops short of fully re-documenting each parameter because the schema is already exhaustive.

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 the tool's scope: '공시의 첨부파일 목록과 형제문서 본문·페이지 이미지를 다룹니다' and immediately distinguishes itself by stating '구조 보존은 download_document'. It clearly identifies the resource, the modes, and how this tool differs from a sibling.

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?

There is an explicit 'Usage' section with numbered steps: get dcm_no from list, then call with dcm_no and mode='text'; use mode='images' when tables are image-only; and route structure-preservation needs to download_document. It also gives an exclusion warning — 'No bulk sweeps — mass viewer calls bring DART IP bans'.

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