Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly and idempotent behavior, and the description adds meaningful context: the two-level comparison logic, the treatment of aggregation as normal, and the response shape (L3 finding list with empty report coordinates and populated source coordinates). There is no contradiction with the annotations.

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 in the first sentence, and each section—rationale, methodology, return shape, and examples—serves a clear function. The motivational paragraph is slightly longer than strictly necessary but still earns its place by explaining why this tool matters.

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 read-only comparison tool with annotated safety, complete schema descriptions, defaults, and an output schema, the description covers selection, invocation, interpretation, and return format. Nothing needed to call or interpret the tool is missing.

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 description coverage is 100%, so the schema already documents the roles of 보고서, 전주차, 기준주차, and 원본디렉터리. The description confirms the report-vs-source comparison but adds little parameter-level detail beyond what the schema provides, so the 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 first sentence states a specific action: checking whether judgments that should appear from the source are missing from the report, and labels the level (L3). The examples and the explicit pointer to verify_claims distinguish this from the nearest sibling, so an agent can identify it as the omission-checking tool.

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 gives an explicit use case ('빠뜨린 지연 과제가 있나요?') and an explicit exclusion: if checking whether written values are correct, use verify_claims. It also explains that aggregated reporting without individual items is normal, which clarifies when this tool should and should not flag an omission.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds crucial non-obvious behavior: it ignores the '이슈리스크' text and computes only from date/completion fields. It also explains the strategic rationale—catching delayed tasks that failed to write an issue—which is valuable beyond the annotations.

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 front-loaded with the key constraint in bold and uses short bullets and examples. It is slightly more verbose than strictly necessary due to rhetorical rationale ('그것이 핵심입니다'), but every substantive part earns its place by preventing misuse.

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?

Given the output schema exists, all parameters are optional with defaults, annotations cover safety, and the description covers purpose, non-usage, return summary, and examples, nothing essential is missing for an agent to select and invoke the tool 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?

Schema description coverage is 100%, with each parameter already documented including defaults and allowed values for '구분'. The description reinforces the original-data theme but does not add meaningful parameter-level detail beyond the schema, so the baseline of 3 is appropriate.

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 opens with a specific verb and resource: '원본 데이터만으로 판정 5종(신규완료·지연·일정변경·역행·미제출)을 계산합니다.' It explicitly distinguishes itself from report-based tools by stating it does not take reports as input, making sibling differentiation clear.

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 explicit when-to-use guidance ('이번 주에 보고되어야 할 변동이 뭔가요?') and when-not-to-use guidance with named alternatives: '보고서와 대조하려면 → check_completeness / verify_claims.' It also stresses that the tool should be used for original-data-only determination, not report comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds substantial behavioral context: values are kept as raw strings to avoid masking rounding errors, extraction is deterministic for table-based reports, and '미검증열' explicitly discloses unverified columns with reasons. This goes well beyond the annotations.

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 front-loaded with the core purpose, then gives behavioral guarantees, return summary, and examples. The '62 vs 62.0' rationale and the '미검증열' explanation are dense but purposeful; every sentence earns its place without redundancy.

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?

Given the output schema and annotations, the description is complete: parameters are covered, return contents are summarized including truncation, examples show how to phrase queries, and the sibling alternative is named. Nothing needed for correct invocation appears to be missing.

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 schema already documents both parameters. The description adds a concrete example of 필드 ('L-08 계획완료일') and clarifies that extracted values remain raw strings, but it does not meaningfully elaborate on the 보고서 parameter beyond the schema. This is slightly above the baseline.

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 clear verb and resource: extracting ('뽑습니다') claims that can be checked against the original source ('원본과 대조 가능한 주장'). It also differentiates itself from verify_claims in the example, so an agent can distinguish extraction from verification without opening other 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?

The description explicitly gives a '사용' vs '사용하지 않음' example: use this tool to ask what the report says, and use verify_claims instead when the task is to judge correctness. It also notes deterministic table-based extraction, which helps the agent decide when this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds crucial behavioral context: results are always `warning`, the tool never blocks saving, it intentionally avoids judging narrative appropriateness, and it excludes table values. This explains the tool's limitations and design rationale clearly.

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 well-structured and front-loaded: the purpose is stated first, followed by an illustrative example, explicit behavioral boundaries, and usage examples. Every section earns its place, and the bold key point makes the tool's non-blocking behavior immediately visible.

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?

Given the annotations, output schema, and sibling tools, the description is fully sufficient. It explains what the tool does, when to use it, when not to use it, what it returns, and why it behaves conservatively. No important operational detail is missing.

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. The description adds extra meaning by clarifying that the '보고서' parameter refers to the narrative text, not tables, and by illustrating the kind of mismatch it detects. It does not deeply elaborate the week or directory parameters, but the schema already documents those adequately.

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 specific function: flag candidates where values are correct but the narrative conflicts with the data (L4). It explicitly distinguishes this from L1/L2/L3 checks and gives a concrete example, so an agent can identify the exact resource and behavior.

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 both a use case ('지연된 과제를 괜찮다고 써 놓은 데가 있나요?') and a non-use case with a named alternative ('숫자 대조 → verify_claims'). It also clarifies that this tool only flags, does not judge, and does not look at tables, which prevents misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, which covers the safety profile. The description adds context about returning two lists (original Excel and .docx reports), but this is also covered by the output schema. No contradiction with annotations, but little incremental behavioral disclosure beyond what structured fields provide.

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 reasonably concise with the main purpose front-loaded. The 'Returns' section and example are useful but slightly redundant with the output schema. Overall efficient and easy to scan quickly.

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 simple read-only list tool, the description is complete: annotations cover safety, output schema covers return format, and the description covers workflow position, usage examples, and exclusions. An agent has everything needed to invoke it correctly without guessing.

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 description coverage is 100% – both parameters (원본디렉터리 and 보고서디렉터리) have descriptive text in the schema. The description does not add any parameter-specific information, so it stays at the baseline of 3.

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 explicitly states it queries the list of verifiable reports and original files for comparison, and includes a concrete example query. It also differentiates from the sibling tool preview_verification_report by specifying when not to use it, making 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 clearly identifies this as the starting point of verification work, instructs the agent to pass the obtained filenames to other tools, and provides both when-to-use ('검증할 수 있는 보고서가 뭐가 있나요?') and when-not-to-use examples with an explicit alternative (preview_verification_report).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable non-obvious behavior: the approval token is computed from finding content so any change alters it, and the approval request must be displayed verbatim. This gives the agent the workflow-level transparency that annotations cannot express.

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 core purpose is front-loaded, and the approval workflow is prominently placed near the top. There is minor redundancy between the first sentence and the explicit 'L1·L2·L3·L4 전부를 검사합니다' repetition, but the overall structure is compact and useful.

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?

Given the annotations, full parameter coverage, and an output schema, the description supplies the missing operational context: token integrity, verbatim approval display, and the save-after-approval gate. An agent has enough information to select and invoke this tool correctly without ambiguity.

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 description coverage is 100%, and each parameter already has a clear description: report path, previous week, target week, and source directory. The description adds no additional parameter-specific detail, so the baseline of 3 is appropriate.

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 opens with a specific verb and resource: it runs all four verification layers and returns the finding list, storage target, and approval request sentence. It also distinguishes itself from sibling intermediate tools by stating it covers L1·L2·L3·L4 in one call.

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 explicitly says intermediate tools are for showing humans why a judgment was made, implying this consolidated tool is for the full preview. It also gives a clear workflow rule: show `approval_request` verbatim and only call `save_approved_verification` after explicit user approval.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds meaningful behavioral context beyond those annotations: each table is returned with its immediately preceding heading, and the rationale for this design is explained. It also summarizes the return shape.

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 compact and front-loaded, stating the core operation in the first sentence, followed by a brief behavioral rule, return summary, and short usage examples. Every sentence earns its place; the rationale for heading attachment is useful rather than filler.

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 read-only single-parameter tool with an existing output schema, the description covers what the tool does, what it returns, and when not to use it. The non-obvious behavior of attaching preceding headings is explicitly stated, so an agent can invoke the tool correctly without surprises.

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 single parameter is fully documented in the schema with type, title, and description including an example file name. Schema coverage is 100%, so the description need not add much; the example C05.docx provides a small extra hint but does not carry a heavy semantic burden.

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?

Clearly identifies the operation: reading the structure of a verification .docx report, attaching preceding headings to each table, and returning table-level metadata plus task codes. The 'not use' example explicitly contrasts with extract_report_claims and verify_claims, helping an agent distinguish it from siblings.

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?

Provides explicit guidance on when to use this tool (asking what tables exist in the report) and when not to use it (comparing values, in which case extract_report_claims → verify_claims is the path). This gives the agent a clear routing decision.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even with readOnlyHint=true, idempotentHint=true, and destructiveHint=false in annotations, the description adds meaningful behavioral context: it stamps the baseline week onto rows, and every row carries file/sheet/row coordinates to support later issue pointing. It also discloses the output contents (row counts, per-week task counts, unsubmitted task codes), going well beyond what the annotations alone 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?

The description is well-structured with clear sections (main description, Returns, Examples) and front-loads the core purpose. There is slight redundancy between '그 규모를 돌려줍니다' in the first line and the 'Returns' details, but overall every section earns its place and no unnecessary content is present.

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?

Given the rich input schema, full parameter documentation, annotations, output schema, and explicit use/not-use examples, the description is complete for an agent to select and invoke the tool correctly. Nothing essential about purpose, behavior, or when to use it is missing.

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 description coverage is 100%, so the input schema already documents all three parameters (전주차, 기준주차, 원본디렉터리) with defaults and explanations. The description does not add additional parameter-level meaning, so the baseline score of 3 is appropriate.

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 opens with a specific verb+resource statement: '원본 엑셀을 읽어 정규화 사실표로 만들고 그 규모를 돌려줍니다' (reads the original Excel, builds a normalized fact table, and returns its scale). It also distinguishes itself from sibling tools with the explicit not-used example routing to compute_baseline_findings, so an agent can tell it apart even without checking the schema.

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 'Examples' section explicitly states when to use the tool ('원본에 몇 개 과제가 들어와 있나요?' / '누가 안 냈나요?') and explicitly states when not to use it ('판정 5종이 필요할 때 → compute_baseline_findings'). This gives clear usage guidance and a named alternative, satisfying the highest bar for this dimension.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description explains that saving writes an intellectual record rather than modifying the report, that errors are not a reason to refuse saving, and that the tool rejects only when the approval token mismatches current findings or when an error is paired with a 'pass' conclusion. This substantially enriches the agent's understanding of the tool's behavior and failure modes.

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 longer than average, but every section earns its place: safety condition, behavioral nuance, explicit rejection rules, return value, and usage examples. Critical approval guidance is front-loaded, and the structure makes the information easy to parse.

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 write tool with 6 parameters, annotations, and an output schema, the description covers the critical operational context: when to call, what the token is, what causes rejection, and what the response contains. The optional file/path parameters are sufficiently documented in the schema, so nothing essential is missing.

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 description coverage is 100%, so the schema already documents all parameters. The description adds valuable context around 승인토큰 and 결론 constraints, but these largely reinforce schema descriptions rather than introducing new parameter-level meaning.

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 opens with a clear verb and resource: saving user-approved verification results to a file, and explicitly states this is the only write tool, which distinguishes it from the sibling read/analysis tools. It immediately signals the tool's unique role in the workflow.

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 gives explicit when-to-use and when-not-to-use guidance: call only after explicit user approval, never before showing the preview, and never without the approval phrase. It also names preview_verification_report as the source of the approval token and lists the two rejection conditions, providing an agent with concrete gating logic.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral context beyond that: L2 checks task codes, suppression rules prevent duplicate findings, derived values are skipped when their source is already flagged, and rounding tolerance maps to warning rather than error. No contradiction with annotations.

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 detailed but every section earns its place: purpose, L1-vs-L2 rationale, suppression rules, rounding policy, return shape, and usage examples. The key purpose is front-loaded and the examples are compact and useful. Length is justified by the tool's non-obvious verification logic.

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?

The description explains the tool's core evaluation logic, edge cases, suppression behavior, rounding tolerance, and return shape. With an output schema present and full schema coverage, nothing an agent needs to invoke this tool correctly is missing. It handles a moderately complex verification task comprehensively.

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 description coverage is 100%, so the schema already documents all four parameters with names, defaults, and descriptions. The description adds general context about what 'verification' means and how findings are produced, but it does not add per-parameter meaning beyond the schema. Baseline 3 is appropriate.

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 opens with a specific verb and resource: '보고서의 값을 원본과 대조합니다' (compares report values against the original), then defines the two finding levels L1 and L2. It distinguishes itself from siblings by explicitly naming check_completeness as the tool for missing items, so an agent can select correctly.

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 gives an explicit positive use case ('보고서 숫자가 원본과 맞나요?') and a negative case (missing items → check_completeness). It also documents important behavioral conditions such as suppression rules and when rounding differences become warnings, which helps the agent decide when and how to invoke the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.