Full-text search over K-IFRS/K-GAAP standards, Q&A and KASB/KICPA material for Korean accountants
Scored across 7 tools
The set cleanly partitions the domain into three search tools (standards, supporting materials, QnAs) and three corresponding retrieval tools (get_paragraph, get_material, get_qna), plus a catalog tool. Cross-routing from search_qnas tf/qc results to get_material is explicitly documented, so no two tools appear to do the same thing.
All seven tools follow a predictable verb_noun pattern: search_*, get_*, and list_standards. The plural/singular distinction (search_standards vs list_standards) is natural and does not break the convention.
Seven tools is well-scoped for a search-and-retrieval server: three search entry points, three get-full-text tools, and one catalog listing. Every tool has a clear role and none feels redundant.
The surface covers the core lifecycle for this domain: discovery via three search tools, full-text retrieval for paragraphs, QnAs, and materials, and a standards catalog. Minor gaps exist (e.g., no direct enumeration of QnAs or materials without a search query, no full-standard table-of-contents retrieval), but agents can work around them via search and context expansion.
MyKIFRS MCP의 get_material 도구는 회계기준원·공인회계사회 자료와 외부 기관 고시의 전문(상세 본문과 첨부 파싱 본문)을 반환합니다.
[Purpose]
Full text of one material_key (search_materials; search_standards kind assure·ext_std; search_qnas kind tf·qc).
[Usage]
"tf:40689 전문" → material_key="tf:40689"
"길어서 잘렸는데 이어서" → material_key="tf:40689", offset_chars=60000
[Response]
{ material_key, board, category, date, title, url, files:[{name, parsed}], body_total_chars, offset_chars, truncated, body }
body = 상세 본문 + 첨부마다 "[첨부] 파일명" 머리를 단 파싱 본문. A 첨부 opening "(이미지 PDF — OCR 전사본" was OCR-read — verify figures against url.
files[].parsed=false → 첨부 not extracted (zip·pptx 등) — point the user to url.
Miss → { error: "material_key 없음: …" } or { error: "material_key 형식 오류: …" }.
[Rules]
truncated=true means offset_chars+max_chars < body_total_chars — raise offset_chars to continue; raising max_chars grows the whole response.
board: search_materials' board legend, plus tf 정착지원TF · qc 품질관리실장 회의 · assure 감사인증·윤리기준 · ext_std 고시 원문.
| Name | Required | Description | Default |
|---|---|---|---|
| max_chars | No | 본문 최대 길이(자) | |
| material_key | Yes | 자료 식별자 "{board}:{id}" (search_materials·search_qnas 의 material_key, 예: tf:40689) | |
| offset_chars | No | 본문 시작 오프셋 (긴 자료 이어읽기) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: response field list, that body concatenates detail text with per-attachment parsed bodies, an OCR-accuracy caveat telling the agent to verify figures against url, parsed=false handling, and both error shapes. Minor deduction for not stating any size/latency traits, but otherwise rich.
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?
Front-loaded one-line purpose followed by Purpose/Usage/Response/Rules headers, so an agent can skim to the needed section. Slightly repetitive (title and purpose line restate the same scope) and a couple of sentences are awkwardly phrased, but nothing is padded.
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?
No output schema exists, and the description compensates fully by documenting the return object, truncation semantics, the attachment-extraction caveat, and both error variants. Nothing needed to call it correctly or interpret the result is missing.
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 100%, yet the description still adds meaning the schema lacks: the truncated = offset_chars+max_chars < body_total_chars relationship, and that raising max_chars grows the whole response while raising offset_chars continues reading. material_key's expected provenance (from search_materials/search_qnas) is also given.
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?
States a specific verb+resource (returns full text for one material_key) and scopes it against siblings by naming search_materials/search_standards/search_qnas as the key sources. An agent can distinguish this retrieval tool from the search tools without opening any schema.
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?
Gives concrete when-to-use mappings from user utterances to calls ("tf:40689 전문" → material_key, "길어서 잘렸는데 이어서" → offset_chars) and names the producing siblings. The continuation case is explicitly handled rather than left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MyKIFRS MCP의 get_paragraph 도구는 기준서 문단 전문을 앞뒤 문맥과 함께 반환합니다.
[Purpose]
To quote a found 문단 exactly — a search snippet is never quotable evidence.
To check 조건절·예외 with neighbors.
[Usage]
"1116호 33문단 원문" → unique_key="1116-33"
"앞뒤로 더 넓게" → unique_key="1116-33", context=5
[Response]
{ standard:{std_num, title, category}, target, related_qnas:[doc_number], items:[…] }
items[]: { seq, item_type, unique_key, para_num, level, title, ref, content_text }; item_type "paragraph"=본문, "title"=제목.
related_qnas → get_qna.
Miss → { error: "문단 없음: {unique_key}", similar:[{unique_key, para_num}] } (≤5).
[Rules]
unique_key = "{기준서번호}-{문단번호}"; 문단 numbers aren't digits-only (B58·6.1.1) — pass verbatim, never normalize.
Keys can carry a "-N" suffix ("1109-B2.7" misses, "1109-B2.7-1" hits — 12% of 문단). On a miss
retry a similar candidate; never read it as "the 문단 does not exist".
context expands within one part — boundaries return fewer items; not an error.
Quote content_text, never a snippet.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | 앞뒤로 포함할 항목 수 (기본 2) | |
| unique_key | Yes | 문단 키 (예: '1116-33') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), yet the description adds materially: the exact miss payload with at most 5 `similar` candidates, the fact that a "-N" key suffix causes misses for ~12% of paragraphs, and that context truncation at part boundaries is not an error. These are behavioral traits an agent could not infer from the annotation set.
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?
Front-loaded with a one-line purpose, then clearly headed sections ([Purpose], [Usage], [Response], [Rules]) so an agent can scan to what it needs. It is on the long side with mild redundancy — the "quote content_text, never a snippet" rule echoes the Purpose section and the response field list — which keeps it from a 5.
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 2-parameter read tool with no output schema, the description supplies the response shape (standard, target, related_qnas, items[] with item_type semantics) and the error shape, which is exactly what would otherwise be missing. Nothing needed to call it correctly or interpret a failure is absent.
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 100% (baseline 3), but the description goes well beyond: unique_key must be passed verbatim with no normalization, may contain non-digit parts (B58, 6.1.1), and may need a "-N" suffix; context is scoped to one part and silently clamps at boundaries. Both parameters gain meaning not present in the schema's terse descriptions.
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?
States a specific verb and resource — returns the full text of a 기준서 paragraph together with surrounding context — and explicitly distinguishes it from the search tools ("a search snippet is never quotable evidence"). An agent can tell instantly that this is the retrieval-of-exact-text tool versus search_standards.
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 [Usage] section gives two concrete call patterns ("1116호 33문단 원문" → unique_key="1116-33"; "앞뒤로 더 넓게" → context=5) that map user intent to arguments. The [Rules] section adds when-to-retry guidance on a miss and how to route to get_qna via related_qnas, which is explicit when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MyKIFRS MCP의 get_qna 도구는 질의회신 전문을 반환합니다.
[Purpose]
The 회신 full text for a doc_number (search_qnas, get_paragraph's related_qnas) or a qna_key (search_qnas).
[Usage]
"2017-001 회신 전문" → doc_number="2017-001"
"legacy:6009 전문" → qna_key="legacy:6009"
[Response]
{ results:[{source, qna_key, doc_number, date, title, rel_stds, full_content, org}] }
Miss → { error: "문서번호 없음: {doc_number}", similar:[{source, qna_key, doc_number, title}] } (≤5 부분일치) or { error: "qna_key 없음: {qna_key}" }.
source / org / rel_stds: same meaning as in search_qnas.
[Rules]
results is an array; doc_number is NOT unique ("GKQA03-100" → 2 rows). Never answer from the first row alone — pin one by qna_key.
qna_key = "{source}:{id}" exactly as returned; if both arguments are given, qna_key wins.
번호 formats differ by series ("2021-G-KQA005" · "GKQA01-085" · "금감원사례-1") — pass the value as received, never alter case or separators.
On a miss, re-ask using similar rather than guessing another 번호.
| Name | Required | Description | Default |
|---|---|---|---|
| qna_key | No | 행 식별자 "{source}:{id}" (search_qnas 의 qna_key, 예: legacy:6009) — 번호가 비었거나 중복일 때 | |
| doc_number | No | 질의회신 문서번호 — qna_key 를 주지 않을 때 필수 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: exact response shape, the miss payload with up to 5 partial matches, the warning that doc_number is non-unique ("GKQA03-100" → 2 rows) so results must not be answered from the first row, and that qna_key wins when both args are given. This is genuinely additive behavioral disclosure.
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?
Sectioned and front-loaded (Purpose/Usage/Response/Rules), and nearly every line carries operational value. Slightly long with some Korean/English duplication, but no sentence is filler.
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?
No output schema exists, and the description supplies one: the results array fields, the two error shapes, and the meaning of source/org/rel_stds. Combined with the miss-handling rule, an agent has everything needed to call and interpret this tool.
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 100%, so the baseline would be 3, but the description adds semantics the schema lacks: qna_key takes precedence when both are supplied, the "{source}:{id}" contract must be passed exactly as returned, and series-specific 번호 formats must never have case/separators altered. These are real invocation rules, not restatement.
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?
States a specific verb+resource: returns the full text of a 질의회신 for a doc_number or qna_key, and explicitly names its sources (search_qnas, get_paragraph's related_qnas), routing the agent away from list/search siblings. The title and body are consistent and an agent can distinguish this from search_qnas without opening a schema.
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?
Gives concrete user-phrase→argument mappings ("2017-001 회신 전문" → doc_number, "legacy:6009 전문" → qna_key) plus a fallback rule: on a miss, re-ask using `similar` instead of guessing. When-to-use and what-to-do-otherwise are both explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MyKIFRS MCP의 list_standards 도구는 수록된 기준서 카탈로그를 반환합니다.
[Purpose]
Which 기준서 are in the corpus, and which numbers feed search_standards' std_num filter.
[Usage]
"수록된 기준서 전부" → (인자 없음)
"감사기준서만" → category="audit"
"내부회계관리제도 관련" → category="icfr"
[Response]
{ count, standards:[{std_num, title, category}] }
category values: kifrs(한국채택국제회계기준) · interpretation(해석서) · concept(재무보고를 위한 개념체계) · translation(번역본) · kgaap(일반기업회계기준) · special(특수분야) · audit(감사기준서) · icfr(내부회계관리제도) · sme(중소기업회계기준) · nonprofit(비영리조직회계기준) · assurance(검토·인증업무 기준(목록만)) · other(기업회계기준 전문·적용의견서·회계감사실무지침·행동강령).
[Rules]
Lists 수집 성공(crawl_status='ok') 기준서 only — an absent 기준서 means "미수집", not "존재하지 않음".
감사인증·윤리기준 (검토·인증·품질관리 등)과 고시 원문 are outside this catalog — search_standards category="assure"·"ext_std".
category is a free-form string, not an enum: an unknown value returns count=0, not an error.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | 카테고리로 필터 (생략 시 전체) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent/closed-world profile, so the description is free to add the behavioral facts that actually matter: only standards with crawl_status='ok' are listed, and absence means '미수집' rather than '존재하지 않음'. It also discloses failure semantics — an unknown category returns count=0 rather than an error — which no structured field conveys.
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?
Sectioned as Purpose / Usage / Response / Rules with the core statement front-loaded, so an agent can skim the first line and stop. The twelve-value category enumeration is long but load-bearing given the free-form string risk; the only mild slack is restating the return shape in prose that also appears in the [Response] block.
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?
No output schema exists, so the description supplies the return shape ({count, standards:[{std_num, title, category}]}) itself. Combined with the crawl_status caveat, the out-of-scope routing, and the silent-empty-result warning, an agent has everything needed to call this correctly and interpret empties.
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 100% but the schema only says '카테고리로 필터 (생략 시 전체)'. The description enumerates all twelve category values, gives their Korean meanings, and warns that the field is a free-form string rather than an enum, so an unrecognized value silently yields count=0 instead of an error.
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?
States a specific verb and resource ('수록된 기준서 카탈로그를 반환합니다') and explicitly frames the output's downstream use: which std_num values feed search_standards' filter. That makes it trivially separable from the sibling search_standards, which retrieves content rather than enumerating the corpus.
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?
Gives three concrete user-intent → argument mappings ('전부' → no args, '감사기준서만' → category="audit", '내부회계관리제도' → category="icfr'). It also states exclusions and routes them to the sibling: 감사인증·윤리기준 and 고시 원문 are outside this catalog and belong to search_standards with category="assure"/"ext_std".
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MyKIFRS MCP의 search_materials 도구는 회계기준원·공인회계사회의 보조 자료(질의회신 교육자료·공개초안·IASB 동향·연구보고서·협의회 사례·가치평가 자료 등)를 전문검색합니다.
[Purpose]
Supporting (2-tier) material: 질의회신 교육·정비목록, 공개초안·IFRS 검토의견·제·개정 공표, IASB 동향, 연구보고서, 세미나·KAI Forum, 제정개정과제, KICPA 전·당기 협의회 사례, 가치평가 자료실 (위험 프리미엄·IVS).
1-tier is in the core tools: 기준서·감사인증·윤리기준·고시 원문 → search_standards; 회신·정착지원TF·품질관리실장 회의 → search_qnas.
[Usage]
"1028호 공정가치선택권 공개초안" → query="공정가치선택권", board="ed"
"2025 질의회신 교육 리스" → query="리스", board="edu"
"시장위험 프리미엄" → query="시장위험 프리미엄", board="valuation"
[Response]
{ hits, results:[{material_key, board, category, date, title, snippet}] }
board codes: listed in the board parameter's description. date null = 과제 페이지.
[Rules]
Tokens ≥3 chars → FTS (AND, rank); 1~2 chars → LIKE (newest first).
Supporting only, never 회신 — where it conflicts with 기준서·회신·1-tier, follow those.
Read the full text with get_material(material_key).
| Name | Required | Description | Default |
|---|---|---|---|
| board | No | 게시판으로 한정 (생략 시 전체) — qna_maint(질의회신 정비목록) · edu(질의회신 교육자료) · project(제정개정과제) · consult(의견조회) · ed(공개초안) · comment(IFRS 검토의견) · trend(IASB 동향) · amend(제·개정 공표) · research(연구보고서·KARI Report) · glossary(K-IFRS 주요용어) · event(세미나·KAI Forum) · kicpa_council(전·당기 감사인 의견불일치 조정 협의회 사례(KICPA)) · valuation(가치평가 자료실(KICPA — 위험 프리미엄·IVS·외부평가 서식)) | |
| limit | No | 최대 결과 수 (기본 10) | |
| query | Yes | 검색 키워드 (공백 구분) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds real behavioral detail beyond them: FTS (AND, rank) for tokens ≥3 chars vs LIKE (newest-first) for 1-2 chars, and that date=null means a 과제 페이지. It also routes to get_material for full text. Missing only things like pagination limits or result ordering across boards.
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?
Sectioned with headers ([Purpose]/[Usage]/[Response]/[Rules]) and front-loaded, with essentially no filler. Minor redundancy: the opening sentence restates what [Purpose] and [Rules] cover again.
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?
No output schema exists, but the description supplies the response shape ({hits, results:[...]}) and notes date can be null. Combined with the usage examples and FTS/LIKE rules, an agent has everything needed to call it correctly and interpret results.
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 100% and the board enum is fully documented in the schema, so baseline is 3. The description adds value by showing which board codes pair with which query intents and by explaining query tokenization thresholds, which is semantics the schema does not carry.
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?
States a specific verb and resource: full-text search of 회계기준원·공인회계사회 supporting materials, with an enumerated scope. It explicitly contrasts with 1-tier siblings (search_standards for 기준서, search_qnas for 회신), so an agent can pick the right tool without opening schemas.
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?
Provides three concrete query+board example pairs mapping user phrasing to parameters, states what this tool does NOT cover, and gives an explicit conflict-resolution rule ('where it conflicts with 기준서·회신·1-tier, follow those').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MyKIFRS MCP의 search_qnas 도구는 질의회신과 정착지원TF·품질관리실장 회의자료를 한 목록으로 전문검색합니다.
[Purpose]
회신 and KASB 실무 해석 (정착지원TF·품질관리실장 회의) for issues the 기준서 alone cannot settle.
문단-linked 회신 → get_paragraph related_qnas.
[Usage]
"전환사채 콜옵션 회계처리 질의회신" → query="전환사채 콜옵션"
"1118호 영업손익 TF 논의까지 30건" → query="영업손익", limit=30
[Response]
{ hits, results } by relevance; matched tf·qc keep ≥3 slots (≤limit/3). kind "qna" = 회신 {source, qna_key, doc_number, date, title, rel_stds, org, snippet} → get_qna; kind "tf"·"qc" = 정착지원TF·품질관리실장 회의 {material_key, category, date, title, snippet} → get_material.
org = 회신 기관 (회계기준원·금융감독원·신속처리질의·IFRS 해석위원회 논의결과·구 QnA); source = 수록 세대 (v2·legacy), never the 기관.
rel_stds is HTML — data-std + data-id → unique_key ("1109-6.1.1").
[Rules]
Tokens ≥3 chars → FTS (AND, rank); 1~2 chars → LIKE (회신 first).
kind tf·qc are 논의·회의 요약, not 회신 — never cite them as 질의회신.
qna_key pins one 회신 when doc_number is "" or duplicated. legacy 회신 (mostly 2000~2011, 구 기업회계기준) — check date.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 최대 결과 수 (기본 10, 회신·TF·회의자료 합계) | |
| query | Yes | 검색 키워드 (공백 구분) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly/idempotent/non-destructive), and the description adds real behavioral disclosure beyond them: token-length routing (≥3 chars → FTS with AND + rank, 1–2 chars → LIKE with 회신 first), and a result-packing rule that matched tf·qc keep at least 3 slots (≤limit/3). It also discloses data quirks — org vs source semantics, rel_stds being HTML with data-std/data-id, qna_key pinning for empty/duplicate doc_number, and the legacy-era caveat.
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?
Sectioned with [Purpose]/[Usage]/[Response]/[Rules] and front-loaded with what it searches, which is appropriate for a dense tool. The [Response] block is heavy — field lists, HTML note, org-vs-source aside — but it is load-bearing because there is no output schema; a little of it borders on reference material rather than selection guidance.
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?
No output schema exists, and the description fully covers the return shape ({hits, results}, per-kind object fields, relevance ordering with quota) so an agent knows what comes back and where to go next. Combined with search-mode rules and the legacy-date caveat, nothing needed to call it correctly is missing.
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 100%, so the baseline is 3, but the description genuinely adds meaning: query is whitespace-separated tokens whose length changes the search mode, and limit is a combined cap across 회신+TF+회의자료 with a reserved-slot quota behavior. It stops short of stating any default or bound changes beyond the schema's own text, so not a 5.
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?
States a specific verb and resource (전문검색 of 질의회신 + 정착지원TF·품질관리실장 회의자료 in one list), and the title/description pair makes clear it is the Q&A-side search versus search_materials/search_standards. It also scopes the domain ('issues the 기준서 alone cannot settle'), so an agent can distinguish it from the standard-text search siblings without opening either schema.
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?
Provides two concrete query examples showing the keyword style and limit usage, plus explicit routing both inward (문단-linked 회신 → get_paragraph related_qnas) and outward (kind "qna" → get_qna, kind "tf"/"qc" → get_material). It also states an exclusion rule — tf·qc are 논의·회의 요약, never to be cited as 질의회신 — which is exactly the when-not guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
MyKIFRS MCP의 search_standards 도구는 기준서 문단과 감사인증·윤리기준·고시 원문을 한 목록으로 전문검색합니다.
[Purpose]
The 기준 grounding a treatment ("사용권자산 손상 is which 문단?"): 기준서 문단 (K-IFRS·일반기업·감사·내부회계· 중소·비영리) plus 감사인증·윤리기준 and 고시 원문 (공익법인·집합건물 회계처리기준 등).
[Usage]
"사용권자산 손상 관련 기준" → query="사용권자산 손상"
"일반기업회계기준에서 리스 분류" → query="리스 분류", category="kgaap"
"1116호 안에서만 리스료 재측정" → query="리스료 재측정", std_num=1116
[Response]
{ hits, results } by relevance; a matched assure·ext_std keeps ≥1 slot (limit ≥3).
kind "paragraph" {std_num, std_title, category, unique_key ("1116-33"·"1109-6.1.1"), snippet} → get_paragraph; kind "assure"·"ext_std" {material_key, category, date, title, snippet} → get_material.
Empty query → { error: "검색어가 비어 있음" }.
[Rules]
One 쟁점 differs by family (K-IFRS vs 일반기업회계기준 vs 중소기업) — confirm category·std_title fits the entity before citing; narrow with category.
Tokens ≥3 chars → FTS (AND, rank); 1~2 → LIKE. 제목 rows excluded.
snippet (⟦…⟧ marks) is a fragment — quote get_paragraph/get_material text.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 최대 결과 수 (기본 10, 문단·원문 합계) | |
| query | Yes | 검색 키워드 (공백 구분) | |
| std_num | No | 특정 기준서로 한정 (예: 1116) — 주면 기준서 문단만 | |
| category | No | 기준 계열로 한정 (생략 시 전체) — kifrs(한국채택국제회계기준) · interpretation(해석서) · concept(재무보고를 위한 개념체계) · translation(번역본) · kgaap(일반기업회계기준) · special(특수분야) · audit(감사기준서) · icfr(내부회계관리제도) · sme(중소기업회계기준) · nonprofit(비영리조직회계기준) · other(기업회계기준 전문·적용의견서·회계감사실무지침·행동강령) · assure(감사인증·윤리기준(KICPA, 최신판 — 품질관리·검토·인증·윤리·가치평가서비스 수행기준 등)) · ext_std(외부 기관 기준·고시(공익법인·집합건물 회계처리기준, 분·반기 검토준칙, 공공감사기준 등)) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only, idempotent search. The description adds substantial behavioral detail beyond that: relevance ranking, a reserved result slot for assure/ext_std when limit >= 3, empty-query error behavior, FTS vs LIKE token thresholds, title-row exclusion, and a warning that snippets are fragments to be quoted from source tools.
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 structured with clear Purpose/Usage/Response/Rules headings and is front-loaded with the core operation. It is somewhat long and repeats the tool name in the opening sentence, but most sentences carry actionable information.
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?
There is no output schema, so the description must explain return values, and it does: it describes the { hits, results } shape, result kinds, key fields, and routing to get_paragraph/get_material. It also covers empty queries, ranking, result slot behavior, and snippet limitations, leaving little relevant ambiguity for the calling agent.
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 100%, so the baseline is 3. The description still adds meaning beyond the schema: category families are framed around entity reporting regimes, std_num is tied to returning only standard paragraphs, limit interacts with reserved assure/ext_std slots, and query token length affects FTS vs LIKE behavior.
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 states a specific verb and resource: full-text search across standards paragraphs and audit/ethics/external standards. It partially distinguishes from siblings by routing 'paragraph' results to get_paragraph and 'assure'/'ext_std' results to get_material, but it does not compare itself explicitly against search_materials, search_qnas, or list_standards.
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?
It gives concrete usage examples and explains when to narrow by category or std_num, including the warning to confirm category/std_title fits the entity. Alternatives are named only as follow-up retrieval tools, not as alternative search tools, so the when-not-to-use guidance is incomplete.
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.
search_materials3 fields changedInput schema / properties / board / descriptionPrevious value: -"게시판으로 한정 (생략 시 전체) — 1-tier: assure(감사인증·윤리기준(KICPA, 최신판 — 품질관리·검토·인증·윤리·가치평가서비스 수행기준 등)) · ext_std(외부 기관 기준·고시(공익법인·집합건물 회계처리기준, 분·반기 검토준칙, 공공감사기준 등)) / 2-tier: qna_maint(질의회신 정비목록) · edu(질의회신 교육자료) · project(제정개정과제) · consult(의견조회) · ed(공개초안) · comment(IFRS 검토의견) · trend(IASB 동향) · amend(제·개정 공표) · research(연구보고서·KARI Report) · glossary(K-IFRS 주요용어) · event(세미나·KAI Forum) · column(기고자료) · kicpa_case(IFRS 실무사례(KICPA 월간공인회계사)) · kicpa_council(전·당기 감사인 의견불일치 조정 협의회 사례(KICPA)) · kicpa_column(회계기준원 기고문(KICPA, KASB 기고자료에 없는 것)) · valuation(가치평가 자료실(KICPA — 위험 프리미엄·IVS·외부평가 서식))"New value: +"게시판으로 한정 (생략 시 전체) — qna_maint(질의회신 정비목록) · edu(질의회신 교육자료) · project(제정개정과제) · consult(의견조회) · ed(공개초안) · comment(IFRS 검토의견) · trend(IASB 동향) · amend(제·개정 공표) · research(연구보고서·KARI Report) · glossary(K-IFRS 주요용어) · event(세미나·KAI Forum) · kicpa_council(전·당기 감사인 의견불일치 조정 협의회 사례(KICPA)) · valuation(가치평가 자료실(KICPA — 위험 프리미엄·IVS·외부평가 서식))"Input schema / properties / board / enumPrevious value: -[
- "assure",
- "ext_std",
- "qna_maint",
- "edu",
- "project",
- "consult",
- "ed",
- "comment",
- "trend",
- "amend",
- "research",
- "glossary",
- "event",
- "column",
- "kicpa_case",
- "kicpa_council",
- "kicpa_column",
- "valuation"
-]New value: +[
+ "qna_maint",
+ "edu",
+ "project",
+ "consult",
+ "ed",
+ "comment",
+ "trend",
+ "amend",
+ "research",
+ "glossary",
+ "event",
+ "kicpa_council",
+ "valuation"
+]Input schema / properties / tierRemoved value: -{
- "anyOf": [
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ],
- "description": "근거의 층으로 한정 — 1=기준·고시 원문, 2=교육·해설·사례·초안 (생략 시 전체, 1-tier 먼저)"
-}search_standards3 fields changedInput schema / properties / categoryAdded value: +{
+ "description": "기준 계열로 한정 (생략 시 전체) — kifrs(한국채택국제회계기준) · interpretation(해석서) · concept(재무보고를 위한 개념체계) · translation(번역본) · kgaap(일반기업회계기준) · special(특수분야) · audit(감사기준서) · icfr(내부회계관리제도) · sme(중소기업회계기준) · nonprofit(비영리조직회계기준) · other(기업회계기준 전문·적용의견서·회계감사실무지침·행동강령) · assure(감사인증·윤리기준(KICPA, 최신판 — 품질관리·검토·인증·윤리·가치평가서비스 수행기준 등)) · ext_std(외부 기관 기준·고시(공익법인·집합건물 회계처리기준, 분·반기 검토준칙, 공공감사기준 등))",
+ "enum": [
+ "kifrs",
+ "interpretation",
+ "concept",
+ "translation",
+ "kgaap",
+ "special",
+ "audit",
+ "icfr",
+ "sme",
+ "nonprofit",
+ "other",
+ "assure",
+ "ext_std"
+ ],
+ "type": "string"
+}Input schema / properties / limit / descriptionPrevious value: -"최대 결과 수 (기본 10)"New value: +"최대 결과 수 (기본 10, 문단·원문 합계)"Input schema / properties / std_num / descriptionPrevious value: -"특정 기준서로 한정 (예: 1116)"New value: +"특정 기준서로 한정 (예: 1116) — 주면 기준서 문단만"get_material1 field changedInput schema / properties / material_key / descriptionPrevious value: -"자료 식별자 \"{board}:{id}\" (search_materials 의 material_key, 예: tf:40689)"New value: +"자료 식별자 \"{board}:{id}\" (search_materials·search_qnas 의 material_key, 예: tf:40689)"search_materials3 fields changedInput schema / properties / board / descriptionPrevious value: -"게시판으로 한정 (생략 시 전체) — tf(정착지원TF 논의내용) · qna_maint(질의회신 정비목록) · edu(질의회신 교육자료) · project(제정개정과제) · consult(의견조회) · ed(공개초안) · comment(IFRS 검토의견) · trend(IASB 동향) · amend(제·개정 공표) · research(연구보고서·KARI Report) · glossary(K-IFRS 주요용어) · event(세미나·KAI Forum·회의자료) · column(기고자료) · sus_project(지속가능성 과제) · sus_lib(지속가능성 제정개정자료) · sus_kr(한국 지속가능성 공시기준 적용지원) · sus_intl(국제 지속가능성 공시기준 적용지원)"New value: +"게시판으로 한정 (생략 시 전체) — 1-tier: assure(감사인증·윤리기준(KICPA, 최신판 — 품질관리·검토·인증·윤리·가치평가서비스 수행기준 등)) · ext_std(외부 기관 기준·고시(공익법인·집합건물 회계처리기준, 분·반기 검토준칙, 공공감사기준 등)) / 2-tier: qna_maint(질의회신 정비목록) · edu(질의회신 교육자료) · project(제정개정과제) · consult(의견조회) · ed(공개초안) · comment(IFRS 검토의견) · trend(IASB 동향) · amend(제·개정 공표) · research(연구보고서·KARI Report) · glossary(K-IFRS 주요용어) · event(세미나·KAI Forum) · column(기고자료) · kicpa_case(IFRS 실무사례(KICPA 월간공인회계사)) · kicpa_council(전·당기 감사인 의견불일치 조정 협의회 사례(KICPA)) · kicpa_column(회계기준원 기고문(KICPA, KASB 기고자료에 없는 것)) · valuation(가치평가 자료실(KICPA — 위험 프리미엄·IVS·외부평가 서식))"Input schema / properties / board / enumPrevious value: -[
- "tf",
- "qna_maint",
- "edu",
- "project",
- "consult",
- "ed",
- "comment",
- "trend",
- "amend",
- "research",
- "glossary",
- "event",
- "column",
- "sus_project",
- "sus_lib",
- "sus_kr",
- "sus_intl"
-]New value: +[
+ "assure",
+ "ext_std",
+ "qna_maint",
+ "edu",
+ "project",
+ "consult",
+ "ed",
+ "comment",
+ "trend",
+ "amend",
+ "research",
+ "glossary",
+ "event",
+ "column",
+ "kicpa_case",
+ "kicpa_council",
+ "kicpa_column",
+ "valuation"
+]Input schema / properties / tierAdded value: +{
+ "anyOf": [
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ],
+ "description": "근거의 층으로 한정 — 1=기준·고시 원문, 2=교육·해설·사례·초안 (생략 시 전체, 1-tier 먼저)"
+}search_qnas1 field changedInput schema / properties / limit / descriptionPrevious value: -"최대 결과 수 (기본 10)"New value: +"최대 결과 수 (기본 10, 회신·TF·회의자료 합계)"get_materialsearch_materialsget_paragraph1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_qna1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"list_standards1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"search_qnas1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"search_standards1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_usage_statsget_qna3 fields changedInput schema / properties / doc_number / descriptionPrevious value: -"질의회신 문서번호"New value: +"질의회신 문서번호 — qna_key 를 주지 않을 때 필수"Input schema / properties / qna_keyAdded value: +{
+ "description": "행 식별자 \"{source}:{id}\" (search_qnas 의 qna_key, 예: legacy:6009) — 번호가 비었거나 중복일 때",
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "doc_number"
-]get_paragraphget_qnaget_usage_statslist_standardssearch_qnassearch_standardsFull-text search over FSS/FSC accounting supervision documents for Korean accounting professionals
Korean accounting standards, audit, tax and legal sources and rulings, with citation checks
Korean accounting standards (K-IFRS, K-GAAP, audit, ICFR) and official Q&A, cited by paragraph.
Powerful OpenDART API-based Korean corporate disclosure tools for accounting professionals
Add one secure layer between your agents and this server.