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

Annotations already cover readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the key behavioral fact that this MCP does not invoke the LLM and only assembles instructions — a genuinely non-obvious trait for a tool named 'build_minutes_prompt' that an agent might otherwise assume performs the summarization itself. 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?

Well-structured: a purpose sentence up front, followed by a behavioral note, then clean Args and Returns sections. The behavioral note earns its place by preventing the agent from expecting an LLM call. The docstring-style formatting (Args/Returns headers) is slightly verbose but reads efficiently and front-loads the core purpose.

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 two-parameter, read-only, idempotent tool with an output schema and full parameter coverage, everything an agent needs is present: purpose, role in the pipeline, parameter defaults, and the return concept (rules + template + original text). No consequential gaps remain.

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%; note_id and with_line_numbers are already documented, with with_line_numbers explaining the 'L14' citation format and default true. The Args section of the description largely restates the schema (note id, default True), adding little beyond it. With full schema coverage, 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 action — combining meeting notes with a standard template to return a meeting-minutes writing prompt — which clearly distinguishes it from siblings that read notes, extract facts, validate drafts, or save minutes. The title '회의록 작성 프롬프트 생성' reinforces this. Nothing ambiguous about what resource is acted on or what is produced.

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 tool's role in the pipeline: it does not call the LLM API, the host (Claude/Codex) performs summarization, and this tool only assembles formatting instructions. This tells the agent this is the prompt-preparation step rather than a summarizer or validator. It lacks explicit 'use X instead' routing or when-not-to-use guidance, but the workflow context is clearly conveyed.

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 readOnlyHint, idempotentHint, and destructiveHint, so the description doesn't need to restate safety. It adds genuine value beyond annotations by disclosing the heuristic nature — false positives are possible, the check is advisory, and it normalizes date expressions to ISO to avoid false positives. These traits are not derivable from the structured fields and help an agent calibrate trust in the results.

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 sentence, and the inspection-item list plus the advisory note are well-organized with headers. The structure is clear, but the Args section largely duplicates the schema and could be trimmed. Minor redundancy keeps this 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?

An output schema (GroundingResponse) covers the return shape, so the description need not detail it. Everything else an agent needs is present: what the tool inspects, that it is advisory with possible false positives, how it fits in the save pipeline, and how to remediate findings. Nothing material is missing for a correct call.

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 all three params (note_id, minutes_markdown, max_findings) already documented in the schema. The description repeats the Args with nearly identical information, adding only marginal context such as the default of 30 for max_findings. Since the schema carries the heavy lifting, the baseline of 3 is appropriate — the description adds no substantial new parameter 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 names a specific verb and resource — cross-checking people, dates, and numbers in minutes against the original note — and enumerates the exact inspection items (person_unsupported, date_unsupported, etc.). It distinguishes itself from validate_minutes_draft by stating that one checks structure while this checks factual grounding, so an agent can select it correctly without opening 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 description places the tool clearly in the workflow: it is advisory, does not block saving, and the save gate is validate_minutes_draft plus user approval. It also gives a recovery path — re-check the original with read_meeting_note and change unsupported claims to '미정'. It lacks an explicit 'use X instead' exclusion for every sibling, but the context is strong enough that when/when-not usage is clear.

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 it as read-only, non-destructive, and idempotent. The description adds valuable behavioral context beyond those hints: it warns that a second save overwrites existing minutes and frames the tool as a way to prevent data loss. It also previews the return type (DiffResponse with write_mode values), which is useful. This enriches the annotation profile without contradicting it.

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 and well-structured: a one-sentence purpose, a brief explanation of why it exists, and a clear Args/Returns breakdown. Every sentence earns its place, and the most important detail (the overwrite warning) is front-loaded. No fluff or 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?

For a read-only diff tool, the description fully covers what it does, why it is used, and what it returns (DiffResponse with write_mode). An output schema exists, so return details are already specified. 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?

Schema coverage is 100%, so each parameter already has a description. The description's Args section essentially repeats the schema information, adding only minimal context (e.g., diff_preview_lines defaults to 40, minutes_markdown is the full draft). Since the schema already carries the meaning, the description does not add significant new value, warranting a baseline 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 a specific action: shows the difference between saved minutes and the draft. It clearly identifies the resource (meeting minutes) and the operation (diff comparison). The added context about preventing overwrite accidents further clarifies its purpose and distinguishes it from siblings like preview_save_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 explicitly explains when this tool is useful: before a second save with the same note_id overwrites the existing file. It positions the tool as a safety check, giving clear contextual usage. However, it does not mention alternative tools or explicitly state when not to use it, so it stops short of a perfect 5.

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 convey read-only, idempotent, and non-destructive hints. The description goes beyond these by revealing that content in ambiguity_flags should remain 'undecided' in the minutes, and by noting that truncated_categories indicates categories that were cut due to limits. This provides actionable behavioral context that helps the agent use the output correctly.

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 with a clear opening purpose, a rationale, a list of returns, then Args/Returns/Examples sections. It is informative but not overly verbose, though some repetition (e.g., restating default value) could be trimmed. Front-loading the purpose and usage examples makes it 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?

Given the tool's complexity with multiple output categories and an existing output schema, the description provides sufficient context: what it returns, how to interpret ambiguity_flags, and when to use it. The examples cover both positive and negative usage cases, making it complete for an agent to call the tool correctly in a workflow.

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?

Both parameters are fully described in the schema (100% coverage), so the description adds no substantive new semantic information. It restates the default value of max_items_per_category and its purpose ('context protection') but this closely mirrors the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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 extracts 'quotable facts' with line numbers from the original text before drafting, listing specific categories (attendees, speech lines, date expressions, decision candidates, action item candidates, ambiguity flags). It distinguishes itself from sibling check_minutes_grounding by explicitly stating it is not for verifying completed drafts, making its purpose and differentiation 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 explicit usage scenarios: 'use right before draft writing' and 'when evidence check gives a warning', and a clear non-use case: 'do not use when verifying a completed draft, use check_minutes_grounding instead'. This gives an agent precise conditions for when to invoke this tool versus alternatives.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is disclosed. The description adds valuable context that the returned note_id is meant to be passed to other tools and that the list contains notes with difficulty levels, line counts, etc. This goes beyond the annotations without contradicting them.

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: a one-sentence purpose, a usage note about the workflow, a Returns section, and clear examples. Every sentence adds value, and the content is front-loaded with the main purpose.

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 no-parameter list tool with a rich output schema and safety annotations, the description provides purpose, usage guidance, return format hints, and examples. It covers everything an agent needs to know to invoke it correctly and understand its role in the workflow.

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?

There are zero parameters, so schema coverage is complete and the description need not explain parameter semantics. The baseline of 4 applies. The description does mention the return structure, which is helpful but not about 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?

The description clearly states it lists synthetic meeting notes from an education package, and distinguishes itself from read_meeting_note by noting that you should use that tool when you already have a note_id and need the original text. The verb 'list' and resource are 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?

It explicitly says this is the starting point for meeting minutes work and provides a concrete example of when NOT to use it (when you already have note_id and need the original text), naming the alternative tool read_meeting_note. This gives agents clear selection criteria.

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, covering safety. The description adds the return fields (note_id, path, line count, UTC timestamp, hash) and the overwrite-check use case, which is meaningful beyond the structured metadata. No contradictions.

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 two sentences plus a Returns block, with the primary purpose front-loaded. Every sentence earns its place; the overwrite warning and return format are concise and valuable.

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 parameterless read-only tool with annotations covering safety and an output schema (and the description enumerating the return fields), the definition is fully sufficient for correct invocation. No missing information.

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 baseline is 4. The description adds no parameter info because none exists, and the empty schema is fully covered. Nothing else 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 already-saved meeting minutes, using a specific verb (조회/retrieve) and resource (saved minutes). It also adds the overwrite warning context, which distinguishes it from similar list tools like list_dummy_notes.

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 frames the purpose as checking what exists before saving, providing clear context for when to use it. It does not name alternatives or exclusions, but the use case is unambiguous given the tool's specificity.

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, and the description adds rich behavioral context beyond that: the approval_token is a hash of (note_id, body) guaranteeing content integrity, the token does NOT replace user approval, and the token is only issued when validation passes. This precisely discloses the safety-critical behavior of the tool without contradicting any annotation.

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, followed by a critical safety warning, then clean Args and Returns sections. It is longer than average, but every section earns its place — especially the bolded warning that the token doesn't replace user approval, which is essential for correct usage. Slightly verbose but well-organized.

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 fully covers what an agent needs: purpose, usage sequence, safety guarantee regarding content integrity, the requirement for explicit user approval, and the routing to save_approved_minutes. The output schema (PreviewResponse) handles return-value details, so the description's Returns section listing status, approval_token, validation, grounding, diff, and approval_request is sufficient. 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 coverage is 100% and the schema's own descriptions are unusually thorough — include_preview even explains the context-saving tradeoff. The description's Args section largely restates the schema rather than adding new meaning. Baseline 3 is appropriate because the schema already documents all four parameters well and the description adds only marginal context.

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 purpose: 'shows save target, changes, validation, grounding results at once and issues an approval token' — a single gateway before saving. It clearly distinguishes itself from the sibling save_approved_minutes by being the pre-save preview step. The verb+resource combination makes the tool's role unmistakable and differentiates it from the other validation/preview 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?

The description explicitly positions itself as the 'single gateway right before saving' and provides a precise usage sequence: show approval_request to the user, wait for explicit approval, then call save_approved_minutes. It also states the condition for token issuance (structural validation must pass). This is ideal routing guidance that names the next tool to use and the precondition for use.

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 known. The description adds significant behavioral context beyond those: it specifies the return structure (NoteContentResponse with content, total_lines, truncated), error behavior (ToolFailure with NOTE_NOT_FOUND / INVALID_NOTE_ID, and includes a list of valid note_ids), and the purpose of with_line_numbers for citation anchors. The synthetic nature of the data is also disclosed. This goes well beyond annotations and helps the agent predict side effects and outcomes accurately.

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: a purpose sentence, a contextual paragraph, then labeled Args, Returns, and Raises sections. It is not bloated, but it duplicates parameter details that already exist in the schema, which adds minor redundancy. However, the structure is logical and front-loaded enough that an agent can quickly grasp the core purpose before diving into details. The redundancy does not significantly harm readability.

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 tool with four parameters and an output schema, the description covers everything an agent needs: what it does, when to use the range feature, parameter semantics, return structure, and error handling. It also discloses the synthetic nature of the data and why line numbers matter (for citations). Since the output schema exists and is likely detailed, the description's summary of return fields is sufficient. 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%, meaning every parameter already has a clear description in the input schema. The description's Args block largely repeats that information (note_id, start_line, end_line, with_line_numbers) with only minor additions, such as explaining with_line_numbers is for citation anchors—which is already present in the schema description. The description adds little beyond what the schema provides, so it meets but does not exceed the baseline of 3 for tools with high schema 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 opens with a clear statement: 'note_id에 해당하는 합성 회의 메모 원문을 읽습니다' (reads the original text of the synthetic meeting memo for the given note_id). It names the verb (read), the resource (synthetic meeting memo), and even characterizes the memo as synthetic, which distinguishes it from real data. The mention of line-range reading further clarifies a specific capability that separates it from straightforward read tools. No ambiguity remains about what this tool does.

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 a concrete usage scenario: '근거 검사에서 경고가 난 줄만 다시 확인할 때도 이 범위 인자를 씁니다' (use the range argument when re-checking only lines that raised warnings in grounding checks). This tells an agent when the range parameters are relevant. It does not explicitly name alternatives or exclusions, but the purpose is clear enough that an agent can infer when to select this tool over siblings like list_dummy_notes or extract_note_facts. The schema for note_id also hints at list_dummy_notes as the source of IDs, so usage context is adequately covered even if not stated in the description itself.

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 fully covered. The description adds value by specifying the event fields (시각, note_id, write_mode, 변경 줄 수, 내용 해시) and that results are ordered 최신순. This is consistent with 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?

The description is compact, with a purpose statement first, then a use-case line, then structured Args and Returns sections. No wasted words. It loses one point because it could be even more terse (e.g., merging the first two sentences) and the Args/Returns formatting is a bit verbose but acceptable.

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 tool is a simple read operation with an output schema provided. The description covers the purpose, use case, parameter semantics, and return type (AuditResponse with events[]). Given the readOnlyHint and output schema, nothing else is needed for an agent to invoke it correctly. Complete for its complexity.

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 both parameters already have clear descriptions in the schema (limit: '최신순 최대 건수', note_id: '특정 메모로 필터링. 생략하면 전체.'). The description essentially repeats these, adding no new semantic meaning beyond what the schema provides. Baseline 3 is correct.

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 uses a clear verb (조회합니다) and a specific resource (회의록 저장 감사 로그) with ordering (최신순). It also names the exact use case (AWAITING_APPROVAL → SAVED 흐름의 실행 증거 제출), which distinguishes this from any sibling tool that might list minutes but not audit logs.

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 explicitly states when to use this tool: 'AWAITING_APPROVAL → SAVED 흐름의 실행 증거를 제출할 때 사용합니다.' This gives clear context. It does not explicitly mention when not to use it or name alternatives, but the use case is narrow enough to prevent misuse. A 4 is appropriate because it lacks exclusion guidance but provides solid context.

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?

Goes well beyond annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true) by explaining that the token only guarantees technical integrity, not user approval; that the tool is destructive (overwrite possible) and idempotent; and that errors include recovery guidance in the exception messages. All behavioral traits are disclosed without 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?

The description is well-structured with headings for Args, Returns, and Raises, uses bullet points for preconditions, and front-loads the core requirement. While moderately long, every sentence contributes necessary information (preconditions, token semantics, error handling) and there is no fluff or 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?

Covers the complete lifecycle: prerequisites, parameter semantics, return value (SaveResponse), error conditions and their recovery, and how it fits among siblings (only write tool). The presence of an output schema further reduces the burden. Nothing an agent needs to call this tool 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?

The input schema already provides 100% coverage and detailed descriptions for all four parameters, including token mismatch and expected_write_mode enforcement. The description's Args section largely repeats this but adds important context about the token's limited guarantee and the preconditions, adding marginal value beyond the schema. A baseline of 3 is lifted to 4 because the description clarifies the interaction between parameters (e.g., the relationship between approval_token and minutes_markdown).

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 verb (saving minutes to a file) and the resource (meeting minutes), with a precise condition (approval token match). It explicitly identifies itself as '이 서버에서 유일한 쓰기 도구' (the only write tool on this server), distinguishing it from all sibling tools, which are read/preview 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?

Provides explicit preconditions: preview_save_minutes must return AWAITING_APPROVAL and issue a token, and the user must explicitly approve saving. It also gives an exclusion: '사용자가 "저장해"라고 말하지 않았다면 호출하지 마세요' (don't call unless the user says 'save'). This is clear, unambiguous guidance on when 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.

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds meaningful context by explaining the gate mechanism (errors block approval token in preview_save_minutes) and that issues include rule_id, severity, line, and fix so the agent can self-correct. This goes beyond what annotations convey and helps the agent understand downstream effects.

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: purpose, gate explanation, validation item lists, Args/Returns/Examples. It front-loads the key purpose and gate. While somewhat long, every section serves a function and the bullet-point lists of error/warning items are directly actionable. Minor redundancy with the schema's parameter description prevents 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?

With an output schema present, the description need not detail return values, and it doesn't. It provides the validation item lists, the gate relationship, and usage timing. The examples clarify both when to use and when not to use. This is complete for an agent to call the tool correctly without missing critical context.

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 the single parameter minutes_markdown already has a clear description ('검증할 회의록 초안 전문(마크다운)'). The description's Args section essentially repeats this without adding new information. Baseline 3 is appropriate since the schema does the heavy lifting and the description adds no meaningful extra semantics.

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: '회의록 초안의 구조를 검사합니다' (checks the structure of the minutes draft) and immediately labels it a '저장 게이트' (save gate). It distinguishes itself from siblings by explicitly naming check_minutes_grounding as the alternative for content-grounding checks, and the usage examples make the differentiation concrete.

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 usage timing: '초안을 쓴 직후, 저장 미리보기 전' (right after drafting, before preview) and an explicit exclusion: when checking grounding, use check_minutes_grounding. This leaves no ambiguity about when to call this tool versus alternatives.

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