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

Annotations already convey readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds meaningful context on top: the tool makes no external API calls and performs pure instruction assembly. This is genuinely informative behavior disclosure beyond the structured hints, and it does not contradict 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 well-organized into a functional summary, a behavioral note, and labeled Args/Returns sections. It is efficiently written with no redundant sentences, and the key behavioral fact (no LLM call) is front-loaded. Slightly more compact phrasing is possible, but the structure is clean and scannable.

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 an output schema exists for PromptResponse, the return format is already documented externally. The description notes the prompt contains rules + template + original text. Both parameters are covered by the schema, and annotations carry the safety profile. Nothing an agent needs to invoke this correctly appears to be missing for a tool of this simplicity.

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 note_id and with_line_numbers are already well-described in the schema, including the 'L14' citation-format detail. The description only briefly restates the parameters without adding new meaning. With full schema coverage, the baseline of 3 applies — the description contributes little 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 states a specific verb+resource: 'returns a minutes-writing prompt combining meeting notes and standard template'. It also clarifies the tool is not an LLM API caller, only an instruction assembler, which further sharpens the purpose. It doesn't explicitly name a sibling it is not, but the function is distinct enough among the listed siblings (all list/read/extract/validate/save operations).

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 explains the division of labor ('summarization is done by the host; this tool only assembles instructions'), which implies when it should be used — as a prompt-preparation step before host-side summarization. However, it never explicitly says 'use this instead of X' or 'do not use when Y', and it names no alternative. The usage context is implied rather than stated.

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?

The description clearly discloses the heuristic nature, possible false positives, and that it does not block saving, and explains date normalization designed to avoid false positives on legitimate minutes. This adds meaningful behavioral context beyond the annotations (readOnlyHint/idempotentHint/destructiveHint) and does not contradict them in any way.

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 most but well-structured with headers (검사 항목, 중요, Args, Returns) and bullet lists. Core purpose is front-loaded before details, and every section earns its place. Slight redundancy in the Returns section (output schema already covers the return structure) keeps it from a 5.

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 and the moderate complexity, the description is complete: it covers purpose, check item catalog, advisory caveat, alternative validation tool, args, and return semantics. An agent has everything needed to call the tool correctly and interpret results.

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 each parameter is already documented in the schema. The description's Args section mostly restates schema content (note_id = original memo id, minutes_markdown = full draft text) with only marginal additions like the max_findings default of 30, which the schema already specifies. Baseline 3 applies since the schema carries the load.

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 ('역으로 대조' — reverse cross-check) and resource (people/dates/numbers in minutes vs. original memo text). It enumerates concrete check items (person_unsupported, date_unsupported, number_unsupported, etc.), which lets an agent know precisely what the tool inspects and distinguish it from validate_minutes_draft (structural) and read_meeting_note (source lookup).

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 positions this as advisory: '자문(advisory)입니다... 저장을 막지 않습니다' and names the actual save gate as validate_minutes_draft(구조) + user approval, defining when-not. It also prescribes the follow-up workflow — re-check warnings against the original via read_meeting_note and mark as '미정' if ungrounded — leaving no inference about usage.

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, idempotentHint=true, and destructiveHint=false; the description adds value beyond them by revealing the overwrite mechanism (second save with the same note_id replaces the file) and exposing the return mode enum (CREATE / OVERWRITE / NO_CHANGE). This is consistent with the annotations - no contradiction.

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?

Purpose is front-loaded, followed by the overwrite-safety context, then a compact Args/Returns block. It is efficient, though the Args section partially duplicates the schema's parameters, a minor redundancy given the 100% coverage.

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 diff tool with a full output schema (DiffResponse) and complete param schema, the description is nearly sufficient: it covers purpose, usage context, params, and the return mode. A minor gap is that edge cases (e.g., behavior when a note does not exist, implying CREATE) aren't spelled out, but the output schema largely covers the response shape.

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 baseline is 3. The Args section largely restates the schema (note_id, 초안 전문, diff_preview_lines 기본 40) without adding syntax, format, or dependency details. Some added value comes from documenting the return enum, but that concerns the response, not the parameters.

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?

States a specific verb+resource: 'shows the difference between an already saved minutes and a draft' (이미 저장된 회의록과 초안의 차이를 보여 줍니다), and frames the purpose as a safety check to prevent overwrite accidents. It is clearly distinct from the write/validation siblings, though it never names an alternative like preview_save_minutes, so sibling differentiation is implicit rather than explicit.

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?

Gives concrete context for when to use it: a second save with the same note_id overwrites the existing file, so check what will be lost first. This is an explicit use-case statement, but it offers no 'when not to use' guidance and no alternative routing, leaving comparison against preview_save_minutes to inference.

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 this is a read-only, idempotent, non-destructive operation, so the safety profile is covered. Beyond that, the description adds valuable behavioral context: it discloses exactly what categories it returns (attendees, lines, dates, decision/action candidates) and the key semantics of ambiguity_flags — that flagged content should remain 'undetermined' in the minutes. The truncated_categories behavior is also surfaced. 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 front-loaded with the core purpose and rationale, then uses clear Args/Returns/Examples sections. It is slightly verbose — the anti-hallucination philosophy paragraph is contextually useful but could be tightened. Overall well-structured with no wasted sentences.

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 (NoteFactsResponse) documents the return structure, the description appropriately focuses elsewhere: how to use it, when not to, and the ambiguity_flags contract for post-processing. The truncated_categories edge case is disclosed. The only mild gap is that it doesn't explicitly state the line-number anchoring behavior is by source line, though that's implied. Near-complete for an agent to call 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%, so the schema already documents both parameters, including max_items_per_category's 'context protection' purpose and its default/range. The description's Args section mostly restates this information without adding new meaning, so the schema carries the load. 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 states a specific verb+resource+objective: extracting 'citable facts' from the source text along with line numbers, before draft writing. It clearly distinguishes itself from check_minutes_grounding, which validates completed drafts. The inclusion of the anti-hallucination anchoring rationale clarifies both what it does and why it exists.

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 is exemplary: it names two explicit 'use' scenarios (before drafting, when grounding fails) and one explicit 'do not use' scenario with a named alternative (check_minutes_grounding for validating finished drafts). The agent gets direct routing instructions rather than having to infer fit.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint all true/non-destructive), lowering the bar. The description adds meaningful context beyond annotations: the overwrite behavior for has_minutes=True notes on save, the recommendation of diff_minutes_against_saved, and the interpretation of minutes_saved_utc (null when absent). 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?

Purpose is front-loaded in the first line, followed by the entry-point sentence, a structured Returns block, a warning, and an Examples section. Each section earns its place, though the Returns block is somewhat dense with field detail. Slightly long but uniformly useful with no 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?

Complete for an entry-point list tool with an output schema present. It explains the workflow (start here, forward note_id), return semantics, the overwrite hazard, and usage/exclusion examples referencing the correct siblings (read_meeting_note, diff_minutes_against_saved). Nothing an agent needs to call it correctly 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?

Zero parameters, so the baseline is 4. There is nothing to document for parameters, and the description instead enriches the output semantics — clarifying that note_id is the key to pass onward and defining has_minutes/minutes_saved_utc meaning, which compensates fully for the empty input schema.

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?

States a specific verb (조회/retrieves) and resource (synthetic unstructured meeting notes included in the education package), and clarifies the list nature. The entry-point framing and the explicit 'do not use when you have note_id → read_meeting_note' differentiates it from siblings. Distinguishes from list_saved_minutes by emphasizing the synthetic/dummy nature of the data.

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?

Explicitly states it is the starting point for all minutes work and that note_id should flow to other tools. Provides three worked examples of when to use and the single exclusion condition (already knowing note_id and needing the original text), naming read_meeting_note as the alternative. Nothing is left to inference.

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. The description adds valuable behavioral context beyond those: it warns about overwrite behavior when using the same note_id, and describes the returned fields in a structured way. 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 concise, with the main purpose stated first, then an important caution, and a compact Returns section. Every sentence adds information, and there is no redundancy or 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 list tool with no parameters and an output schema, the description covers the purpose, the typical usage scenario (pre-save check), and the return structure. It is complete and self-sufficient for an agent to invoke 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 tool has zero parameters, so the description correctly omits any parameter details. According to the rubric, baseline is 4 for 0-parameter tools, and no further explanation is needed.

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 lists saved meeting minutes ('이미 저장된 회의록 목록을 조회합니다'). It distinguishes itself from writing tools by explicitly framing its purpose as a pre-save check, making it unambiguous which sibling it complements (e.g., save_approved_minutes).

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 clear context for when to use the tool: '같은 note_id로 저장하면 덮어쓰기가 되므로, 저장 전에 무엇이 있는지 확인하는 용도입니다.' It does not explicitly name alternatives, but the use case is well-defined and self-explanatory.

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/destructiveHint, so no credit for those. The description adds genuinely useful context: the token is a hash of (note_id, text) so the approved content cannot diverge from what is saved, and the token does NOT substitute for user approval — the approval_request must be shown and explicit consent obtained. This is material behavioral disclosure not present in 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: purpose in the first line, then the critical behavioral rules, then Args/Returns. The Args block in the description is somewhat redundant with the fully-covered input schema, which costs a little efficiency, but every other sentence earns its place and the Returns section usefully enumerates the response fields.

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 4-parameter tool with an output schema present and full schema description coverage, the description covers the essentials: purpose, pipeline position, token semantics, and the mandatory user-approval handoff before calling save_approved_minutes. Slight room remains on what an agent should do on a NEEDS_REVISION status, but nothing blocks correct invocation.

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% and each parameter already has a meaningful description in the schema, including usage guidance for include_preview ('이미 초안을 들고 있다면 False로 두어 컨텍스트를 아끼세요'). The description's Args block largely mirrors the schema verbatim, adding marginal value beyond the structured field definitions.

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 opening line states a specific verb plus resource: '저장 대상·변경 내용·검증·근거 결과를 한 번에 보여 주고 승인 토큰을 발급합니다' (shows save target/changes/validation/grounding and issues an approval token). The follow-up '저장 직전의 단일 관문입니다' (the single gateway before saving) positions it against siblings, clearly distinguishing it from save_approved_minutes and validate_minutes_draft.

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 clear workflow context: it is the mandatory single gate before saving, the token is issued only when structural validation passes, and save_approved_minutes should be invoked only after explicit user approval. It does not enumerate exclusions for other siblings like diff_minutes_against_saved or validate_minutes_draft, but it does identify the pipeline position and the next tool.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the Raises section lists specific ToolFailure error types (NOTE_NOT_FOUND / INVALID_NOTE_ID) and mentions that a list of available note_ids is included in error messages. It also describes the return fields (content, total_lines, truncated). This goes beyond annotations and helps the agent anticipate 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 well-structured with Args, Returns, and Raises sections. The purpose is front-loaded, each sentence contributes meaning (e.g., why range is useful, how line numbers are used), and there is no redundancy. It is appropriately sized for the tool's complexity.

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 an output schema exists, the description does not need to fully explain return values, but it still does. It covers error cases, parameter semantics, and usage context. It is complete for a read-only tool with simple parameters and annotations already covering safety. The agent has everything needed to 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?

Schema coverage is 100%, so the schema already documents all parameters. The description adds meaningful usage context beyond the schema: it explains that with_line_numbers is used for citation anchors in the meeting minutes grounding column, and clarifies that end_line omitted means read to the end. This is extra semantic value beyond mere restating, justifying a 4.

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?

Description clearly states 'read the original text of a synthetic meeting note by note_id' with a specific verb and resource. It distinguishes from sibling tools like list_dummy_notes and extract_note_facts implicitly, but does not explicitly name an alternative, so it falls short of a 5.

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 guidance on when to use the range parameters (to avoid wasting context on long notes, and to re-check only lines with warnings), but does not explicitly address when to choose this tool over siblings or when not to use it. There is no mention of alternative tools, so it partially meets the dimension but lacks exclusions.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral details: each event contains 시각 (time), note_id, write_mode, 변경 줄 수 (changed line count), and 내용 해시 (content hash), and the response is ordered latest first. This gives the agent a concrete expectation of what the audit log contains without repeating annotation information.

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 a clear purpose statement, a usage context line, and a compact Args/Returns block. It front-loads the main action and use case, then provides the essential parameter and return information. There is minor redundancy (e.g., Args block partially repeats schema descriptions), but it's not excessive. The description is concise and easy to scan.

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 audit log tool with an existing output schema (AuditResponse), the description covers the key aspects: the purpose, the specific flow it supports, the event contents, and the ordering. It doesn't explicitly mention pagination or that it only covers saved minutes (not drafts), but these are minor gaps given the output schema and the simplicity of the tool. The description is complete enough for an agent to call 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?

Schema description coverage is 100% (both limit and note_id have clear descriptions in the schema). The description adds some context (e.g., that limit is for 최신순 최대 건수, note_id filters a specific memo) but does not provide significantly different information beyond what the schema already documents. Since the schema carries the burden, the baseline 3 applies; the description doesn't go beyond that.

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 (조회/retrieve), a specific resource (회의록 저장 감사 로그/minutes save audit log), and the ordering (최신순/latest first). It further clarifies the intended use case (submitting execution evidence for the AWAITING_APPROVAL → SAVED flow), which distinguishes it from sibling tools like list_saved_minutes or read_meeting_note.

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 states when to use this tool: 'AWAITING_APPROVAL → SAVED 흐름의 실행 증거를 제출할 때 사용합니다.' This is a clear context for use. It doesn't explicitly name alternatives or exclusion criteria, but the purpose itself naturally separates it from siblings (e.g., list tools are for listing, read tools are for single notes). The context provided is sufficient for an agent to decide when this is the right tool.

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?

The description discloses that this is a write/destructive operation (consistent with destructiveHint), requires explicit user consent beyond the token, and explains that the token only ensures technical integrity, not user approval. It also details failure modes with recovery information, adding safety-critical context beyond what annotations 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 well-structured with a bolded uniqueness statement, numbered prerequisites, and separate sections for Args, Returns, and Raises. It front-loads the critical condition (token match) and is not unnecessarily verbose given the complexity, though it could trim some repetition of parameter details.

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 covers all necessary aspects: when to use, prerequisites, user consent, parameter meanings, return values, and error recovery. Since an output schema exists, it doesn't need to detail the response shape further, making it fully complete for a write tool.

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 already covers all parameters with clear descriptions, including the exact-match requirement for minutes_markdown and the safety purpose of expected_write_mode. The description repeats these details rather than adding new meaning, so it adds minimal value beyond the schema, which has full coverage.

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 action: saving meeting minutes to a file only when the approval token matches. It also explicitly identifies itself as the only write tool on the server, distinguishing it from preview_save_minutes and other read-oriented 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?

It specifies exact prerequisites: preview_save_minutes must have returned AWAITING_APPROVAL and issued a token, and the user must have explicitly approved. It warns not to call unless the user has said to save, and names the only write tool, leaving no ambiguity about when to invoke it.

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 and idempotentHint, so the safety profile is covered. The description adds context beyond that: it's a gate for preview_save_minutes, and issues include a 'fix' field enabling self-correction without asking. This is valuable behavioral insight not present in the annotations, though the description could have elaborated on the response format details if needed.

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 structured and front-loaded: it states the purpose and gate behavior first, then uses bullet points for the check items and concise examples. The inclusion of the list of error and warning categories is informative and not redundant. It is slightly long but appropriate for the complexity of the tool.

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 covers what the tool does, when to use it (and when not to), what it returns (via Returns section), and the check categories. With an output schema present, the return format is already specified, and the description does not need to duplicate it. It is self-sufficient for an agent to call 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%—the parameter 'minutes_markdown' is documented as '검증할 회의록 초안 전문(마크다운)' in the schema, and the description's Args section repeats this without adding new semantics. Since the schema already fully explains the parameter, the description adds no extra value here, warranting the baseline score 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 states the verb ('검사합니다') and resource ('회의록 초안의 구조') clearly, and positions it as a '저장 게이트' (storage gate). It lists specific error and warning categories, making the tool's purpose unambiguous. It also differentiates from siblings by naming check_minutes_grounding as the alternative for content grounding checks.

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?

Explicit usage context is given: use after drafting and before preview_save_minutes, and not for verifying content against the original text—instead use check_minutes_grounding. It also explains that errors block the approval token, which is a key workflow constraint.

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