답변·의견서 초안에 적힌 해석례·판례·결정례 문서번호(예: 서면-2023-법규기본-2595, 기획재정부 소득세제과-1059, 2015두41937, 조심2023서1234)와 조문 인용이 이 DB에 실제로 있는지 확인한다. 「법령명」·약칭(조특법·상증법)·'같은 법 시행령'·'제1조, 제2조' 열거를 읽고, 조문 뒤 괄호 제목은 현행 제목과 대조한다(title_check). 지어낸 번호·없는 조문·엉뚱한 제목을 거르는 용도이며, 본문 내용 일치 확인은 아니다. unchecked·unresolved_articles는 검사 못 한 것이다. 비세법 참조 법령(민법 등) 조문은 found_reference로 따로 표시한다.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 검증할 초안 본문 또는 문서번호 목록 | |
| max_citations | No |
Changes observed during successful MCP inspections.
Input schema / properties / max_citationsAdded value: +{
+ "default": 15,
+ "maximum": 30,
+ "minimum": 1,
+ "type": "integer"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the description does not need to repeat safety claims. It adds useful behavioral context: title_check semantics, unchecked/unresolved_articles meaning, found_reference for non-tax statutes, and the limitation that body-text consistency is not verified.
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 purpose is front-loaded and the paragraph is dense with necessary distinctions rather than filler. It is somewhat long, but the length is justified by the variety of citation formats and result labels it must cover.
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 verification tool with no output schema, the description explains scope, key output labels, and important limitations well. It still leaves some gaps around result structure and how max_citations truncation is surfaced, but it is substantially complete.
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 50%: the 'text' parameter is well documented in both schema and description, including citation formats and article enumeration handling. However, the description never mentions 'max_citations' or truncation behavior, leaving half the parameter set to the schema alone.
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 (문서번호와 조문 인용) with concrete citation examples. It clearly distinguishes verification from content matching ("본문 내용 일치 확인은 아니다") and from sibling search tools.
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 explains the intended context (draft answers/opinions) and what it is not for (content match verification), plus how to interpret unchecked/unresolved results. It does not explicitly name alternative sibling tools such as search_cases or search_interpretations for follow-up, but the usage boundary is clear.
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.