get_topic회계 주제(예: '자산손상', '리스', '수익')의 정의·관련어, 핵심 기준서 문단 범위, 대표 질의회신·감리지적사례·실무해설을 한 번에 반환. 주제명·관련어·slug 로 조회하며, topic 을 생략하면 전체 토픽 목록. 결과는 이용자 질의에 대한 조회 목적으로만 제공되며 원문 저작권은 제정·발행기관에 있다. 인용 시 응답의 출처 URL 을 표기할 것.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 질의회신·실무해설 종류별 최대 건수, 기본 8 | |
| topic | No | 주제명·관련어·slug (예: '자산손상', '손상차손', 'asset-impairment') |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it discloses the aggregated multi-source return, the copyright restriction, and the citation obligation to include source URLs — none of which the annotations convey.
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?
Three dense sentences, front-loaded with the return contents before the query mechanics and the legal/citation caveat. Every sentence carries information, though the copyright/citation sentence could be tightened.
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?
With no output schema, the description carries the burden of describing the return payload, and it does so thoroughly by enumerating the result categories. It also covers query modes, the list-all fallback, and citation requirements, leaving no critical gap for correct invocation.
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 adds meaning the schema does not: it clarifies that 'topic' accepts names, related terms, or slugs (with examples) and that omitting it switches to a list-all mode, which is default-behavior information absent from the 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?
States a specific verb and resource (get_topic) and enumerates exactly what is returned: topic definition/related terms, standard paragraph ranges, representative Q&A, audit findings, and practice commentary. This clearly separates it from siblings like get_paragraphs, get_qna, get_standard, and list_standards, which each cover only one of those slices.
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?
Explains the lookup keys (topic name, related term, slug) and the fallback behavior when 'topic' is omitted (returns the full topic list). It does not name an explicit alternative tool or a when-not-to-use condition, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.