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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds value by stating the default action is copy (non-destructive) and that move is conditional on server settings and user approval, which clarifies the boundary. This goes beyond the bare annotation and helps an agent understand the mutating nature and its constraints. 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 two concise sentences, front-loaded with the core action and then the crucial condition for move. No filler or repetition; every sentence earns its place.

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 9 parameters, nested objects, and an output schema, the description provides a high-level summary of the operation and its one key constraint (move requires approval). Given the schema covers parameters and annotations cover safety (destructive), the description is sufficient to guide an agent on when and how to invoke it. It could mention that approval_token comes from preview_organize, but that is hinted by the extended description of the token in the schema and the tool name.

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 parameters are fully documented. The description adds no extra explanation of individual parameters, but it does frame the approval_token as part of an 'approved' plan, which implicitly ties the token to the preview step. This is marginal additional meaning; 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 clearly states the tool executes an approved organization plan (승인된 정리 계획을 실제로 수행합니다), distinguishing it from preview (preview_organize) and undo (undo_last_organize) siblings. It also specifies the default mode (copy) and the condition for move, providing a specific verb+resource and operational scope.

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 context: it applies an approved plan, and explicitly states that move mode requires both server settings and user approval (이동은 서버 설정과 사용자 승인이 모두 있어야 합니다). This informs when move is permissible, but it does not explicitly say 'use after preview_organize' or exclude scenarios, though that is implied by the tool's name and sibling structure. Lacks explicit when-not guidance.

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 destructiveHint=false, so the safety profile is established. The description adds that it evenly excerpts documents and returns them at once, which is useful behavioral context, but it doesn't mention potential edge cases or how errors are handled. Given the annotations cover the key side-effect concerns, a score of 3 is appropriate.

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 concise sentences that front-load the main action and constraint, with zero filler. It effectively communicates purpose and usage in minimal space.

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 has an output schema, so return format is not the description's burden. The description covers the core purpose and when to use it, and the parameters are straightforward. It doesn't get into edge cases, but for a read-only tool with simple inputs, the description is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% — both parameters (paths and char_budget) already have descriptive text in the schema. The tool description does not add any extra meaning about the parameters beyond what the schema provides. Baseline of 3 is correct when the schema already documents parameters fully.

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 specific verbs ('발췌해' / excerpt, '돌려줍니다' / returns) with a clear resource (multiple documents) and a constraint (within a character budget). It also states it's for summarizing multiple documents together, which differentiates it from single-document tools like read_document. However, it doesn't explicitly name sibling alternatives to reinforce that distinction.

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 '여러 문서를 묶어 요약할 때 씁니다' (use when summarizing multiple documents together), providing a clear condition for when to invoke this tool. It doesn't mention when not to use it or name alternatives, but the given condition covers the primary use case effectively.

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 destructiveHint=false. The description adds context about what the tool reports (folders, storage, formats, limits) and its role as a prerequisite. This goes beyond the annotations by explaining the kind of information returned, which helps the agent understand the tool's scope. It does not contradict 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 (two sentences), front-loaded with the core purpose, and includes the crucial usage instruction. Every sentence serves a distinct function: stating what the tool does and when to call it. No redundant or filler content.

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 zero-parameter, read-only discovery tool with an output schema available, the description is complete. It tells the agent exactly what the tool reports and that it should be called first. The output schema likely covers the detailed structure, so the description doesn't need to enumerate fields. No missing information for 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?

The tool has zero parameters, so per the rubric the baseline is 4. There is no parameter information needed; the description appropriately focuses on the tool's purpose and usage rather than parameter details. No additional semantic explanation is required.

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 ('확인합니다' = check) and a clear resource (folders, storage locations, supported formats, and limits readable by this server). It clearly differentiates itself from the sibling tools (scan, read, search, etc.) by being a discovery/preflight call, and it explicitly frames itself as a prerequisite to those 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 explicitly states when to use this tool: '다른 도구를 부르기 전에 먼저 호출하세요' (call this first before calling other tools). This gives unambiguous usage guidance and positions it as a mandatory first step, effectively differentiating it from all sibling tools that perform actual operations.

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 annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds context that this is an overview tool rather than a full read, which is useful. It does not disclose any additional behavioral traits like pagination or performance, but given the annotation coverage, a 4 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the action and purpose, followed by a brief usage guideline. Every word earns its place, with 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 simple read-only tool with two parameters (one required) and an output schema, the description covers the essential context: what it does, when to use it, and that it provides an overview. The output schema handles return details, so nothing critical 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% (both path and keypoint_limit have descriptions in the schema). The tool description itself does not add any meaning beyond the schema, so the baseline of 3 applies. It does not elaborate on parameter format or behavior.

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 'opens' and resource 'document', and specifies what it returns: structure (sections, titles, length) and keywords. It also provides a usage context ('choose what to read before reading the whole text') that distinguishes it from siblings like read_document and search_documents.

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 a clear when-to-use condition: 'before reading the whole text'. However, it does not explicitly name alternatives or state when not to use it. While the sibling list implies alternatives, the description itself lacks explicit exclusions, so it falls short of a 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 declare readOnlyHint: true and destructiveHint: false, so the tool's safety profile is covered. The description adds the explicit 'does not touch files' statement, reinforcing the read-only behavior, but does not reveal additional behavioral nuances (e.g., whether it creates temporary state, requires specific permissions, or has any other side effects). Given the annotation coverage, this is adequate but not enriched.

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 exactly two short sentences with zero redundancy. The primary purpose is front-loaded, and the critical non-destructive nature is stated immediately. Every word contributes to the agent's understanding without wasted text.

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 7 parameters and nested objects, the description is brief, but all parameter semantics are covered by the schema descriptions, and the output schema exists to define the return value. The description precisely communicates the tool's role and safety, which is sufficient for an agent to understand when and how to invoke it. It slightly lacks an explicit mention of typical usage flow (e.g., 'preview before apply_organize'), but that is more of a usage guideline gap than a contextual one.

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 provides descriptions for all 7 parameters (coverage 100%), so the schema carries the full semantic load. The description does not add any parameter-specific meaning. Per the guideline, a high coverage baseline of 3 is appropriate; no additional insight is offered beyond what the schema already states.

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 ('만들어 보여줍니다' - creates and shows) and resource (a plan for dividing documents into folders). It explicitly distinguishes itself from mutation tools by asserting '파일을 전혀 건드리지 않습니다' (does not touch files at all), which clearly differentiates it from the sibling apply_organize. This is a precise, unambiguous purpose statement.

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 conveys clear usage context: use this to preview a folder-division plan before actually applying changes. The statement about not touching files implicitly steers the agent toward apply_organize when actual changes are needed. However, it does not explicitly name alternatives or state conditions for when NOT to use it, such as comparing to preview_save_summary. Still, the primary usage intent is evident.

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 destructiveHint=false, so the agent knows it's safe. The description adds beyond that: it produces a preview and issues an approval token, and explicitly confirms it doesn't write. This is useful behavioral context that complements the annotations 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?

Two sentences with zero filler. The key point (preview before saving, token issuance, non-destructive) is front-loaded and each sentence earns its place. Extremely efficient.

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 return format (likely containing the token and final path) doesn't need to be described here. The description covers the tool's purpose and non-destructive nature, and combined with the schema and annotations, an agent has enough to call it correctly. The only minor gap is that it doesn't explicitly mention needing to pass the token to save_summary, but this is implied by the workflow and siblings.

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 all five parameters are already documented in the input schema (e.g., title is noted as used in the filename). The description adds no additional parameter-level semantics 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 description states a clear verb (미리 보여주고, 발급), resource (최종 파일 경로와 내용), and explicitly disclaims writing (파일을 쓰지 않습니다). This differentiates it from save_summary, which actually persists. The purpose is unambiguous and distinct 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?

The description explicitly opens with '요약문을 저장하기 전에' (before saving), giving a clear temporal context. It implies a two-step flow with save_summary (which consumes the issued token), though it doesn't name the exact alternative. This is clear context without explicit exclusions or alternative names, so it earns a 4.

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 destructiveHint=false. The description adds useful context that the output includes section labels for citation purposes, which goes beyond the annotations. It does not contradict the annotations and provides additional behavioral detail, so it earns a 4.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the main action (reading document body) and immediately adds a key feature (section labels for citation). It is concise, with no filler, and every word contributes value.

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 read-only nature and the presence of an output schema, the description is sufficiently complete for an agent to understand the basic behavior. It does not mention pagination flow, but the start_char parameter description covers that. However, it lacks any mention of when to choose this tool over siblings, which is a gap covered by the usage guideline dimension. Overall, it is nearly complete for a read 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides. It makes no mention of how to use start_char, max_chars, or only_labels, leaving that to the schema, which is adequate.

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 reads document body text and mentions that it attaches section labels for citation. It is specific about the resource (document) and action (read), but it does not explicitly differentiate from siblings like outline_document or search_documents, so it scores 4 rather than 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?

There is no guidance on when to use this tool versus alternatives. The description only says what it does, not when it should be chosen or when it should not be used. No exclusions or references to sibling tools are provided, so it scores 2.

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 indicate a write operation (readOnlyHint: false) and non-destructive (destructiveHint: false). The description adds the token requirement and the 'user-approved' qualifier, which adds context beyond the annotations. It doesn't contradict the annotations, and there's no mention of permissions or side effects, but the core safety profile is already covered.

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?

Two short sentences with no filler. The central action is front-loaded, and the prerequisite is stated immediately. Nothing is redundant, and the entire description can be read in seconds.

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 that an output schema exists (so return values don't need explanation) and annotations cover the safety profile, the description is nearly complete. The token prerequisite is the key contextual detail, and it's included. One might want to know what happens if the token is invalid, but that's minor for a simple save operation.

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 all parameters have descriptions. However, those descriptions are minimal (e.g., 'same as preview' for title, sources, etc.), and the tool description adds no extra meaning about the parameters. Per the baseline for high coverage, a 3 is appropriate—the schema does the heavy lifting, but the descriptions are terse.

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 ('saves') and resource ('user-approved summary') plus destination ('output folder'), making the core purpose clear. It also mentions the required token from preview_save_summary, which indicates its role in the workflow. However, it doesn't explicitly contrast itself with the preview tool, so it's not a perfect 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?

The description gives a clear prerequisite: it requires the token from preview_save_summary, which implies this should be called after preview. But it does not explicitly state when to use this tool versus alternatives like preview_save_summary or apply_organize. No exclusions or alternative routing are provided, so it's adequate but not explicit.

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, but the description adds specific behavioral context: it scans only allowed folders, returns results in recent modification order, and explicitly states it does not read file contents. This goes beyond the annotations by clarifying the operational scope and side-effect-free nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with two clauses, front-loading the action and result. The 'does not read file contents' clarification is efficient and valuable. There is no redundant wording; every part earns its place.

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 presence of a complete output schema, well-described parameters, and annotations, the description is sufficient for an agent to call the tool correctly. It covers the key constraint (allowed folders), ordering, and the non-reading behavior. Minor gaps like explicit pagination details are already handled by the limit parameter.

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 covers all 5 parameters with descriptions (100% coverage), so the baseline is 3. The description adds no parameter-specific semantics, but it also does not need to since the schema is fully self-documenting.

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 (scan), resource (allowed folders), and the result (document list sorted by recent modification). It explicitly clarifies it does not read file contents, distinguishing it from content-reading tools like read_document and search_documents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies its use for metadata-only listing by stating it does not read file contents, but it does not explicitly name alternative tools or provide conditions for when to use this tool over siblings like search_documents or read_document. The guidance is implied but not explicit.

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, openWorldHint=false, destructiveHint=false, covering safety. The description adds that it 'actually opens' document bodies and returns snippets, which hints at a potentially slower operation, but it does not disclose performance implications, pagination, or error behavior. Given the annotation coverage, the added context is modest but sufficient for a 3.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that immediately states the core action and output. There is no filler or redundancy, and the most important information (opening documents and returning snippets) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists (not shown in full) and the input schema fully describes parameters, the description covers the basics. However, it does not mention potential caveats like handling large file sets, behavior when no results are found, or any limitations on folder scope. These gaps are moderate for a search tool, so a 3 is appropriate.

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 has 100% coverage of parameter descriptions, so the schema already documents each parameter (query, kinds, folder, max_files). The description does not add meaning beyond what the schema states, so the baseline score of 3 applies. No additional semantic value is contributed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: it opens the actual body text of documents to search for terms and returns surrounding sentences as evidence snippets. This is specific and distinct from a simple metadata search. However, it does not explicitly differentiate from sibling tools like scan_documents, so it loses a point for lacking sibling differentiation.

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 no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or conditions that would lead an agent to choose this over scan_documents or read_document. The usage context is only implied by the nature of the tool (searching content), but there is no explicit routing.

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 indicate destructiveHint=true. The description adds valuable context: it does not delete copies but moves them to _trash, implying reversibility. This goes beyond the annotation and informs the agent of the non-permanent nature. No contradiction with annotations, and the added detail is meaningful.

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 short, front-loaded sentences. The primary purpose is stated first, followed by a critical behavioral caveat. No extraneous information, making it efficient and 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 tool with one optional parameter and no required inputs, the description fully explains what it does, how the parameter behaves, and the outcome (trash instead of delete). The output schema is provided separately, so no need to explain return values. The agent has all information needed 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?

The only parameter, journal_path, is fully documented in the schema with its default behavior (empty = most recent). Since schema coverage is 100%, the description adds no extra semantic information about the parameter. It only indirectly references '지정한' (specified) without elaborating, so it meets the baseline but adds no value.

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 'reverts the most recent (or specified) organize run' with a specific verb and resource. It distinguishes itself from siblings like apply_organize and preview_organize by indicating it performs the inverse operation. The added detail about moving to _trash rather than deleting further clarifies its 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 makes the use case obvious: to undo an organize operation. It does not explicitly list alternatives or exclusions, but the context is clear from the sibling tool names (organize tools vs. this undo tool). The mention of specifying a journal path gives a usage hint, though it doesn't explain when to use this over other tools.

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