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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds non-obvious context: the omitting-topic fallback to a full list, and the licensing/citation constraint that results are for query purposes only and the source URL must be cited. It does not describe pagination or the shape of the aggregated payload.
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 sentences, front-loaded with what gets returned, then lookup keys, then the legal/citation note. Dense but each sentence carries distinct information; the copyright sentence is slightly tangential to tool selection but is a genuine usage constraint.
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 usefully enumerates the returned content types and the optional-topic fallback, which is what an agent needs to know before calling. Minor gaps remain around result size/pagination and how the aggregated sections are structured, but the core is covered.
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 both parameters are already documented, making 3 the baseline. The description restates the topic lookup keys (name/related term/slug) that the schema already lists and says nothing about the limit parameter's per-type cap or default beyond what the schema provides.
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 names a specific resource (회계 주제 / accounting topics) and enumerates exactly what is returned: definition and related terms, key standard paragraph ranges, representative Q&A, audit-inspection cases, and practical commentary. An agent can tell it is a topic-level aggregator, though it never explicitly contrasts itself with siblings like get_standard, get_qna, or list_audit_cases, which overlap in content.
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?
Usage is implied: query by topic name/related term/slug, and omitting topic yields the full topic list. There is no explicit guidance on when to prefer this aggregator over the narrower sibling tools (get_qna, get_standard, get_paragraphs) or any stated exclusions, leaving the routing decision to inference.
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.