Compare Korean public notice files from consecutive years to identify changes in application requirements, submission documents, and deadlines, with cited original text evidence.
전년도와 올해 공고의 제출서류·신청기간 변화와 주요 변경 문구를 중요도 순으로, 양쪽 원문 근거와 함께 비교합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| after_path | Yes | MCP_DATA_DIR 기준 상대 파일 경로 | |
| before_path | Yes | MCP_DATA_DIR 기준 상대 파일 경로 |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so no contradiction exists. The description adds useful behavioral detail beyond annotations: results are ordered by importance and grounded with excerpts from both original documents, which helps the agent anticipate the output style.
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?
A single, dense sentence conveys the resource, comparison scope, ordering, and evidence requirement with no filler. The most important subject (comparing previous and current notices) is front-loaded.
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 low-complexity tool with two path parameters and no output schema, the description sufficiently covers what is compared, how results are ordered, and that both original texts serve as evidence. Nothing critical is missing for an agent to select and invoke it correctly.
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 schema only describes each parameter as a relative path under MCP_DATA_DIR. The description adds semantic meaning by mapping before_path to the previous year's notice and after_path to the current year's notice, and by clarifying that both sides are used for comparison and evidence.
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 verb (비교합니다), a clear resource (전년도와 올해 공고), and the comparison dimensions (제출서류, 신청기간, 주요 변경 문구). It also specifies output ordering by importance and inclusion of original-text evidence, which clearly distinguishes it from read_notice, extract_requirements, and get_evidence.
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 implies when to use this tool: when a between-year comparison of notices is needed. However, it does not explicitly state when not to use it or name alternative tools such as read_notice for reading a single notice or extract_requirements for pulling requirements, so some inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.