Skip to main content
Glama
dolseom

gongsi-mcp

by dolseom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

공시 원문 읽기

read_disclosure

Fetch the full text of a DART disclosure using its 14-digit receipt number. Get markdown with tables preserved, the board decision date, or a viewer URL when only HWP is attached.

Instructions

접수번호(rcept_no)로 공시 원문을 표 구조를 보존한 마크다운으로 돌려줍니다.

  • 표가 그대로 마크다운 표로 나오므로 항목별 기재 내용을 바로 비교할 수 있습니다

  • board_date(이사회 의결일)를 원문에서 추출해 함께 줍니다

  • HWP 첨부만 있는 공시는 body_unparsable 에러와 함께 뷰어 URL 을 안내합니다

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNomarkdown(기본) = 표 구조 보존. text = 공백 정규화된 평문
rcept_noYesDART 접수번호 14자리
max_charsNo본문 최대 길이 (기본 60,000자). 초과 시 truncated=true 로 잘라서 준다
force_refreshNo캐시를 무시하고 재다운로드 (기본 false). 접수된 공시는 불변이므로 보통 불필요

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

No annotations, so description carries the burden. It discloses error behavior for HWP-only disclosures and board_date extraction. However, it doesn't mention truncation via max_chars or caching behavior with force_refresh, which are described only in the schema. Given no annotations, this is a gap.

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?

Concise, front-loaded purpose, uses bullet points for additional details. No wasted words.

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?

Covers main behavior, error case, and board_date extraction. Missing explicit response structure (truncated flag) and caching behavior, but those are in schema. Given no output schema, it could be more explicit about return fields, but it's adequate.

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 coverage is 100%, so description adds no additional parameter semantics. The description mentions rcept_no but doesn't go beyond schema descriptions for format, max_chars, or force_refresh.

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 specific verb+resource (returns disclosure text) with format (markdown) and key features (table preservation, board_date extraction, error handling). It distinguishes from search_disclosures (search vs read) and read_detection_result (different resource).

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?

Implies usage when you have a receipt number and need the full text. Provides context about table preservation and board_date extraction, which hints at when it's beneficial. However, it doesn't explicitly name alternatives or when not to use it.

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

Deploy Server

Other Tools