nmjib_process_guideEnter a pyeong size to get the 22-step renovation process order, group workdays, and total schedule days.
반셀프 인테리어 공정 순서 22단계(보양→철거→설비→…→마감)와 평형별 표준 풀리모델링 영업일(15~65평, 내만집 일정 엔진 데이터). 평수를 주면 그 평수의 공정 그룹별 영업일과 합계를 계산한다. "공정 순서", "며칠 걸리나", "도배 마루 뭐가 먼저" 질문에 쓴다.
| Name | Required | Description | Default |
|---|---|---|---|
| pyeong | No | 공급/전용 평수(기본 30) |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds that it calculates business days by process group and total based on schedule engine data. However, it does not describe the output format, edge cases (e.g., pyeong outside 15–65), or how the 22-step order is returned, leaving some behavioral ambiguity. This is adequate but not 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?
The description is a single dense sentence that packs the 22-step detail, pyeong range, engine data reference, and example usage. It is front-loaded with the core function and includes useful query examples. No wasted words, though the length is a bit compressed; it remains clearly structured.
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 only one parameter and no output schema, the description explains it calculates business days by group and total, which gives a basic expectation. However, it is ambiguous whether the return includes the 22-step order itself or just the day breakdown, and it doesn't specify error handling or behavior outside the stated range. For a simple calculator, this is acceptable but not fully 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 100% for the single parameter pyeong, which already has a description ('공급/전용 평수'). The tool description repeats that the input is pyeong and mentions a range of 15~65, which slightly conflicts with schema min/max (10/80). It does not add significant new meaning beyond the schema's own description, so baseline 3 applies.
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 clearly states the tool's function: it takes a pyeong value and calculates interior process order (22 steps) and standard business days by process group. It distinguishes itself from siblings (checklist, cost reference, FAQ search) by focusing on schedule/order. The example questions ('process order', 'how many days', 'what comes first') make the purpose unambiguous.
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 provides direct usage context by listing the exact question types it answers ('공정 순서', '며칠 걸리나', '도배 마루 뭐가 먼저'). It implies usage for schedule-related queries but does not explicitly mention exclusions or alternatives. This is clear context without explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.