The dart-notes-mcp server enables precise, rule-based searching and retrieval of financial statement footnotes from Korean companies' DART filings, going beyond simple keyword search to find specific accounting disclosures across companies, markets, and industries.
search_company_notes — Search footnotes across multiple companies for a specific accounting issue, with filtering by market segment (코스피, 코스닥, 코넥스, 비상장), industry code (KSIC) or name, fiscal year, specific company list, and maximum company count
get_company_note — Retrieve the full text (including tables) of a specific accounting topic's footnote for a single company
list_note_topics — List all registered precision topic rules (e.g., supplier finance, convertible bonds, lease, goodwill impairment) with their matching logic
list_industries — Browse industries available in the metadata cache, filterable by market or industry name keyword
resolve_company_info — Look up a company's market segment and industry metadata by name or code
meta_status — Check the current status of the market × industry metadata cache, showing company counts per market
build_company_meta — (Admin) Build or refresh the listed-company metadata cache (~2,800 companies), with a limit parameter for partial testing
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dart-notes-mcp 코스피 반도체 업종에서 공급자금융약정 2024 주석 보여줘"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
DART 전자공시 재무제표 주석(footnotes) 정밀검색 MCP. 회계사가 주석을 작성할 때 "다른 회사는 이 회계이슈를 주석에 어떻게 썼나" 를 시장(코스피/코스닥/코넥스/비상장)·업종(KSIC)별로, 정확히 찾기 위한 도구.
DART Open API에는 공시 본문(주석) 내용을 검색하는 엔드포인트가 없다.
공시검색(list.json)은 회사·날짜·보고서명 같은 메타데이터만 검색한다.
주석 본문은 오직 공시원문 document.xml(ZIP, EUC-KR) 안의 회사별 HTML에만 있다.
그래서 이 MCP는 원문 다운로드 → 주석을 섹션으로 분해 → 토픽 정밀매칭 을 직접 수행한다.
Related MCP server: dart-risk-mcp
DART/일반검색은 "전환사채 취득"을 치면 전환사채·취득 키워드가 우연히 같이 있는 주석까지 전부 나온다. 이 MCP는 토픽별 규칙으로 노이즈를 차단한다:
계층 | 역할 | 예 (공급자금융약정) |
TITLE-ANCHOR | 주석 제목 정확매칭 → 고신뢰 | 제목 |
SUBJECT (required AND) | 주제 동의어 중 1+ 필수 | 공급자금융약정·역팩토링·공급망금융·매입채무금융 |
FACET (관점 AND) | 관점/aspect 신호 필수 | (전환사채 취득자) 금융자산·매도가능증권 분류 |
PERSPECTIVE | 잘못된 관점 차단 | (취득자) 발행자 신호 |
EXCLUDE / NEGATIVE | 보편어·예외 차단 | 금융약정·팩토링·상생협력 / 신용카드·금융보증 |
→ 노이즈를 낼 바엔 0건 반환(precision 우선). 매칭마다 reasons로 왜 잡혔는지 표시.
내장 토픽(11종):
supplier_finance(공급자금융약정), convertible_bond_holder(전환사채 취득자),
convertible_bond(발행자), related_party(특수관계자), lease(리스), contingency(우발부채)
revenue_recognition(수익인식 IFRS15), goodwill_impairment(영업권 손상),
defined_benefit(확정급여/보험수리적), ecl(기대신용손실), share_based_payment(주식기준보상)
자유어도 가능(전 토큰 AND + intent 라우팅). 반복 이슈는 src/dart_notes_mcp/topics.py에
규칙 한 줄 추가 시 정밀도가 가장 높다(예: 영업권 손상 = 영업권 AND 손상신호 2그룹 요구로
'손상' 보편어 노이즈 차단).
메타 캐시(1회): 상장사 시장구분(corp_cls)·업종(induty_code→KSIC명)을 SQLite에 캐시
→ 시장×업종 필터는 런타임 API 호출 0.
전문 인덱스(v2, 권장): 사업연도별 전체 사업보고서를 1회 받아 주석 섹션을 SQLite+FTS5(trigram)
로 인덱싱(index_build). 검색 = FTS 후보 좁힘 → 동일 토픽규칙으로 정밀필터.
API 호출 0 · ~200ms · 전수 커버. (정밀도는 온디맨드와 동일, 속도·완전성만 향상)
온디맨드 폴백: 미인덱싱 연도·특정 회사 지정 시 원문을 즉시 받아 검색.
search_company_notes는 해당 연도가 인덱싱돼 있으면 자동으로 인덱스 사용.
python -m dart_notes_mcp.index_build --year 2024 # FY2024 전체(열거→fetch→적재)
python -m dart_notes_mcp.index_build --year 2024 --enumerate-only # 건수만실측: FY2024 사업보고서 3,276개사, 주석 텍스트 ~0.4 GB(인덱스 포함 ~1 GB 미만), 1회 빌드 ~25–30분(10병렬)·API ~3,300콜(일 한도 20,000 내). 연도 인자만 바꿔 과거연도 확장.
cd C:\Users\kyhh0\dart-notes-mcp
python -m pip install -e .인증키: .env.example → .env 복사 후 DART_API_KEY=<40자 키> 입력.
메타 캐시 구축(1회, 상장사 ~2,800개·수분):
python -m dart_notes_mcp.build_meta # 전체
python -m dart_notes_mcp.build_meta --limit 300 # 빠른 테스트MCP 등록 (Claude Code / Desktop claude_desktop_config.json):
{
"mcpServers": {
"dart-notes": {
"command": "python",
"args": ["-m", "dart_notes_mcp.server"],
"cwd": "C:\\Users\\kyhh0\\dart-notes-mcp"
}
}
}도구 | 용도 |
| 핵심 — 여러 회사 주석 정밀검색 |
| 단일 회사 주석 전문(표 포함) |
| 등록된 정밀 토픽 규칙 |
| 캐시에 존재하는 업종(회사수) |
| 회사 → 시장·업종 메타 |
| 캐시 현황 |
| (관리) 메타 캐시 구축 |
"코스피 반도체 업종에서 공급자금융약정 2024 주석 보여줘"
→ search_company_notes(topic="공급자금융약정", market=["코스피"], industry_name="반도체", year=2024)
"전환사채 취득자 회계처리 사례 (발행자·우연출현 제외)"
→ search_company_notes(topic="전환사채 취득자 회계처리", year=2024)
공급자금융약정으로 대형 제조·유통사 검증 — 실제 공시는 medium/high, 정책 보일러플레이트는 low ⚠ 로 정확히 분리:
회사 | 판정 | 매칭 위치 |
한온시스템 | ★ high | 전용노트 "공급자금융약정" (TITLE-ANCHOR) |
현대모비스·현대제철·삼성전기 | ★ medium | "매입채무 및 기타채무" 주석 |
기아 | ★ medium | "금융위험 관리" 주석 |
포스코인터내셔널 | ★ medium | "우발채무와 약정사항"(공급망금융) |
삼성전자·이마트·롯데쇼핑·현대위아 | low ⚠ | 회계정책/작성기준 노트의 일반 언급뿐(실제 공시 없음) |
파서는 삼성전자(64섹션)·이마트(주석-prefix 포맷)·현대제철(86섹션) 등 서로 다른 HTML 포맷에서 모두 정상 섹션 분해. 실전에서 발견한 함정(마지막 노트의 본문 흡수, 144Hz→44h 오탐, 정책노트 일반언급)은 모두 차단·테스트에 고정.
비상장(E) 은 전수 enumeration이 비현실적 → companies=[회사명] 지정 시 on-demand 조회.
(메타 캐시는 상장사 기준. 비상장 업종필터는 v1 미지원)
주석 HTML은 회사·연도·감사인별 편차가 커, 드물게 섹션 분해가 빗나갈 수 있음 (번호 연속성 게이트로 완화). 결론·조서 인용 전 DART 원문 대사 권장.
연결(CFS)·별도(OFS) 주석을 모두 보존(수치가 다를 수 있어 임의 dedup 안 함).
year는 사업연도(귀속). 공급자금융약정은 2024 최초적용.
python tests\test_core.py # 파서 + 정밀매칭(양성/함정음성)
python tests\test_search_offline.py # 검색 파이프라인(FakeClient)인증키 비커밋: DART_API_KEY는 .env에만(.gitignore로 *.env 차단). 코드 하드코딩 없음.
키 누출 방지: httpx 예외 문자열에 요청 URL(=키)이 포함될 수 있어, 오류는 상태코드/타입명만 노출.
ZIP 폭탄 방어: 공시원문 ZIP의 응답크기·엔트리수·비압축 총량 상한 검증.
경로 검증: 캐시 파일명(rcept_no)은 14자리 숫자만 허용 + 디렉터리 이탈 차단.
입력 검증: year(19992027)·max_companies(150 클램프, 음수 슬라이스 우회 차단)·시장 화이트리스트.
프롬프트 인젝션 방어: 반환되는 DART 공시 본문은 신뢰불가 데이터임을 content_safety로 명시.
XXE/엔티티 폭탄: corpCode XML 파싱에 defusedxml(설치 시) 적용. 리다이렉트 추적 비활성화.
향후(권고): 보고서 조회 결과 캐시, bounded concurrency, 토픽 규칙 추가 확장.
공시 데이터: 금융감독원 OPEN DART(opendart.fss.or.kr) — 본 도구는 비공식 클라이언트.
업종 매핑(data/ksic/): 통계청 한국표준산업분류(KSIC) 기반, FinanceData/KSIC.
본 도구 코드: MIT License (LICENSE).
⚠ 인증키(DART_API_KEY)는 .env에만 두며 저장소에 커밋하지 않는다(.gitignore).
(관리) 상장사 시장×업종 메타 캐시를 구축/갱신한다. 상장사 ~2,800개
company.json 수집으로 수분 소요. 보통은 CLI python -m dart_notes_mcp.build_meta
로 1회 실행 권장. limit로 일부만 테스트 가능.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses time cost ('수분 소요' - takes minutes) and testing capability (limit). However, it does not explicitly state that the operation may overwrite existing cache or require specific permissions, leaving some behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the primary action. It efficiently conveys purpose, timing, and parameter usage without redundancy. Minor lack of structural formatting (e.g., bullet points) is acceptable for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description covers purpose, time cost, CLI recommendation, and partial testing. It is sufficiently complete for an admin cache-building tool, though it could mention return behavior or success indication.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate for the lone parameter 'limit'. It adds meaning by explaining that limit allows partial testing, which is crucial for understanding the parameter's role. This goes beyond the schema which only defines type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds/updates a meta cache for listed companies' market and industry, using specific verb '구축/갱신' (build/update) and naming the resource '상장사 시장×업종 메타 캐시'. It effectively distinguishes from sibling query tools like get_company_note or list_industries by targeting cache construction, not data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description recommends running via CLI for full execution and mentions limit for partial testing, but does not explicitly state when to use this tool versus alternatives or when not to use it. It implies use for cache building but lacks exclusionary guidance or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
단일 회사의 특정 토픽 주석 '전문'(본문+표 전체)을 가져온다.
Args: company: 회사명 또는 고유번호. topic: 회계이슈(등록 토픽키 또는 자유어). year: 사업연도. 기본 2024.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | ||
| topic | Yes | ||
| year | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It only states it fetches full text and lists parameters, but does not cover error handling, authentication needs, rate limits, or what happens when input is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence stating the purpose followed by a structured list of arguments. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the return value beyond 'full text', and does not address error scenarios or output format. For a tool with no output schema, this leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides clear explanations for all three parameters: company (name or ID), topic (accounting issue), and year (default 2024). This adds significant meaning beyond the input schema, which has 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full text of a specific topic annotation for a single company, using specific verb and resource. However, it does not explicitly differentiate from sibling tools like 'search_company_notes' which likely performs a search, reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
메타 캐시에 실제 존재하는 업종(회사수 포함). 업종 필터값 선택에 사용.
Args: market: 시장 필터(['코스피','코스닥' ...]). contains: 업종명 부분일치(예: '반도체','의약').
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | ||
| contains | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, description indicates read-like behavior (lists existing data) but doesn't specify ordering, pagination, or side effects. Adequate for a simple list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence purpose plus bulleted args. Front-loaded, no fluff. Could be slightly more structured but very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given lack of annotations and presence of output schema, description covers basics but misses behavioral specifics (e.g., results format, default behavior, error conditions). Satisfies minimal completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, description provides examples and explanations for both parameters (market filters like '코스피', contains for partial name match), adding significant value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'list' and resource 'industries', notes inclusion of company count and use for filter selection. Distinguishes from sibling tools which deal with company meta or notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States purpose for filter selection but provides no when-not-to-use or alternatives. Siblings don't offer industry listing, so context is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
등록된 정밀 토픽 규칙 목록(주제어·관점 facet·scope). 자유어도 가능하지만, 반복 이슈는 규칙 등록 시 정밀도가 가장 높다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose any behavioral traits such as idempotency, side effects, or required permissions. It only describes the output content without safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short (two sentences) and conveys the core functionality. Minor improvement could remove the extra explanation about free words and precision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description adequately states what is listed. However, it lacks context about the output structure or any filtering capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds no parameter information since none exist, but it does not detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists registered precision topic rules, mentioning specific components like topic words, perspective facets, and scope. It distinguishes the tool from its siblings, none of which relate to topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or what prerequisites exist. There is no mention of 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.
시장×업종 메타 캐시 현황(시장별 회사수).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of revealing behavioral traits. It only states what the tool returns, but does not disclose whether it is read-only, cached, requires authentication, or any side effects. The lack of behavioral info makes it risky for an agent to invoke without additional knowledge.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that conveys core purpose. It is front-loaded and contains no fluff. However, the Korean language might reduce clarity for non-Korean agents, and the sentence could be slightly more informative without adding length. Still, it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is minimal. The tool has zero parameters, so the main missing context is what exactly the 'meta cache status' means and what format the output takes. It is adequate for a simple status retrieval but leaves questions about interpretation and relationship to other meta tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params, schema coverage 100%). Per baseline rule, score is 4. The description adds no parameter-level detail because none exist, but it does clarify the output scope (per market). This is adequate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's resource (market×industry meta cache) and the returned data (number of companies per market). However, it lacks an explicit action verb like 'get' or 'list', relying on the noun 'status' to imply retrieval. Still, the purpose is discernible and different from siblings like build_company_meta (which builds meta) and list_industries (which lists industries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention context, prerequisites, or situations where this tool is preferred over siblings such as build_company_meta or list_industries. An agent would have to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
회사명/고유번호 → 시장·업종 메타.
| Name | Required | Description | Default |
|---|---|---|---|
| name_or_code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, or side effects. The description is too minimal to inform an agent about safe or expected behavior beyond the stated transformation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core functionality with no extraneous words. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides a high-level summary but lacks details about the return format (single object or list), error conditions, or edge cases. It is minimally adequate for a straightforward lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the single parameter 'name_or_code'. The description compensates by indicating the parameter can be a company name or code, which adds some meaning beyond the schema. However, it lacks details like format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '회사명/고유번호 → 시장·업종 메타.' clearly identifies a specific verb ('resolve') and resource (company info to market/industry meta). It distinguishes from sibling tools like 'build_company_meta' (which implies creation or update) and 'list_industries' (which lists all industries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. Usage is only implied by the purpose; explicit when-to-use or when-not-to-use is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
여러 회사의 재무제표 주석에서 특정 회계이슈를 '정밀' 검색한다.
유사 키워드 난잡검색을 막기 위해 토픽별 규칙(주제 동의어 AND + 관점 facet + 발행자/우연출현 차단)으로 매칭한다. 노이즈를 낼 바엔 비매칭(precision 우선).
Args:
topic: 회계이슈. 등록 토픽키(예: 'supplier_finance','convertible_bond_holder')
또는 자유어(예: '공급자금융약정', '전환사채 취득자 회계처리'). 자유어는
intent 라우팅 또는 전 토큰 AND로 처리. list_note_topics로 등록규칙 확인.
market: ['코스피','코스닥','코넥스','비상장'] 중 택(코드 'Y','K','N','E'도 허용).
industry_code: KSIC 업종코드 접두 리스트(예: ['26','27'] 또는 ['264']).
industry_name: 업종명 부분일치(예: '반도체').
year: 사업연도(귀속). 기본 2024. 예: 공급자금융약정은 2024 최초적용.
companies: 회사명/고유번호 직접 지정(필터보다 우선, 비상장 포함 가능).
max_companies: 조회 상한(API 호출수 보호). 기본 12.
Returns: 회사별 매칭 주석 섹션(제목·연결/별도·신뢰도·매칭사유·본문발췌·표).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| market | No | ||
| industry_code | No | ||
| industry_name | No | ||
| year | No | ||
| companies | No | ||
| max_companies | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description details matching logic (topic rules, synonyms, facet, blocking), return format (title, confidence, excerpt, table), and API protection via max_companies. Missing: authentication, rate limits beyond max_companies, and whether read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with core purpose and matching philosophy. Parameter list is clear. Slightly verbose in matching explanation, but each sentence adds value. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, no annotations, the description covers parameter meanings, return format fields, and API protection. Lacks explicit return structure details (e.g., data type of confidence). References sibling tool list_note_topics for topic keys.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates. Each parameter is described with purpose, allowed values (market codes, industry code prefixes), default (year), and special notes (topic can be key or free-text). Examples provided for topic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches financial statement notes of multiple companies for specific accounting issues with precision. It distinguishes from siblings like get_company_note and list_note_topics by specifying cross-company search and topic-based matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (precise search, avoid noise) and references list_note_topics for topic registration. It implies precision priority, but does not explicitly state when not to use or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0build_company_metaget_company_notelist_industrieslist_note_topicsmeta_statusresolve_company_infosearch_company_notesScored across 7 tools
Each tool has a clearly distinct purpose: cache management, single note retrieval, multi-company search, listing industries, listing topics, cache status, and company resolution. No overlaps or ambiguity.
Most tools follow a verb_noun pattern (build_company_meta, get_company_note, list_industries, list_note_topics, resolve_company_info, search_company_notes). The one exception is meta_status, which uses noun_noun, causing a minor inconsistency.
With 7 tools, the server is well-scoped for its purpose of accessing Korean financial statement notes. Each tool contributes a necessary function without redundancy or excessive specialization.
The set covers core operations: metadata building, single note retrieval, cross-company search, and listing of industries and topics. Minor gaps exist, such as the lack of a tool to list companies within an industry or to retrieve topics available for a specific company, but these can be worked around.
Full-text search over FSS/FSC accounting supervision documents for Korean accounting professionals
Full-text search over K-IFRS/K-GAAP standards and KASB accounting Q&A for Korean accountants
Search company disclosures and financial statements from the Korean market. Retrieve stock profile…
Powerful OpenDART API-based Korean corporate disclosure tools for accounting professionals