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

The description discloses that it 'only works within allowed directories' and explains path normalization and potential issues with relative paths. The annotations indicate a non-read-only, non-destructive operation, and the description adds useful behavioral context 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 somewhat verbose with multiple paragraphs and code formatting. While it front-loads the purpose, it could be more concise. Some details (e.g., referencing instructions) add length without critical 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?

For a simple tool with one parameter and no output schema, the description adequately covers what the tool does and how to use it. It provides enough context for the agent to succeed, though it could briefly mention expected return values.

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 one parameter 'path' with no description (0% coverage). The description fully compensates by explaining the meaning of the path, when to use absolute vs relative, and normalization 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 action: 'Create a new directory or ensure a directory exists.' It also mentions the capability to create multiple nested directories, which distinguishes it from other file operations like 'write_file' or 'edit_block'.

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

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

Provides explicit guidance on using absolute paths, warns about relative and tilde paths, and mentions path normalization. It also suggests how to reference the command in instructions. However, it does not explicitly contrast with when to use alternative tools.

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 destructive behavior; description adds rich behavioral details per file type, diff display on close matches, path normalization, and default replacement count. 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?

Description is comprehensive but long; structured with headings and examples. Could be more concise by reducing redundancy in uniqueness and expected_replacements explanations. Front-loaded with 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?

Given the tool's complexity (8 params, multiple modes, no output schema), the description covers modes, edge cases, line limits, path advice, and examples. No output schema needed for this 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?

With 0% schema coverage, description explains most parameters (file_path, range, content, old_string, new_string, expected_replacements) with format constraints. However, 'options' and 'origin' parameters are not addressed in the description.

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 edits files surgically and distinguishes between file types (Excel range update, text find/replace, DOCX XML mode). It contrasts with siblings like write_file and read_file by emphasizing focused edits.

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 extensive when-to-use guidance including best practices, format-specific instructions, uniqueness requirement, and line limit warnings. However, it does not explicitly state when not to use this tool versus alternatives like write_file.

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 identifies the tool as destructive, matching annotations, and specifies it targets a 'terminal session'. However, it does not disclose required permissions, potential side effects, or how termination is performed.

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, no redundancy. The second sentence about referencing is marginally useful but still concise.

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?

Lacks explanation of what constitutes a terminal session, how to obtain a PID, and how this tool differs from the similar 'kill_process'. The presence of siblings demands more 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?

The description does not mention the 'pid' parameter or how it identifies the session. With 0% schema coverage, the description fails to clarify the parameter's meaning or format.

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 force terminates a running terminal session, but it does not differentiate from the sibling tool 'kill_process', which likely has similar functionality.

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?

No guidance on when to use this tool versus alternatives like 'kill_process' or 'interact_with_process'. The only additional note is about referencing the command, not usage 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?

Annotations already indicate readOnlyHint=true; description adds value by detailing the config structure (fields) and return format (JSON), enhancing transparency beyond 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 somewhat verbose with a field list but is front-loaded with the main action. The meta instruction about 'DC: ...' adds length without core 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?

For a simple read tool with one optional parameter, the description covers the return value comprehensively by listing all config fields, making it complete enough.

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 'origin' is not described in the description, despite having an enum. Schema coverage is 0%, and the description fails to explain its purpose or values.

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 'Get the complete server configuration as JSON,' specifying a unique verb and resource, and it distinguishes from sibling tools like set_config_value.

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 usage for reading config but lacks explicit when-not or alternative tool guidance. The mention of 'DC: ...' is a weak usage hint.

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 readOnlyHint=true, so it's a safe read operation. The description adds behavioral context such as workspace restrictions and path normalization details. 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?

Well-structured with bullet points for metadata and clear sections. Somewhat lengthy but each sentence adds value. Could be slightly more concise, but overall effective.

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 one-parameter tool with no output schema, the description covers the parameter thoroughly and lists expected return fields. Mentions workspace restrictions but lacks error handling details. Generally complete.

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

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

Schema coverage is 0%, but the description compensates with detailed path usage guidance: absolute vs relative paths, tilde handling, and automatic normalization. This adds significant meaning beyond the schema's parameter name.

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

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

Clearly states it retrieves detailed metadata about a file or directory, listing specific attributes like size, creation time, and type. Distinguishes from sibling tools like list_directory (which lists contents) and read_file (which reads content).

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 clear context on when to use: retrieving file metadata. Includes important path usage guidelines (absolute paths, normalization, tilde handling) and mentions it works only within allowed directories. Does not explicitly exclude alternatives or state when not to 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?

The description details offset behavior (positive/negative), length handling, return content (results + status), and reusability, going well beyond the readOnlyHint annotation. No contradictions 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 well-structured with separate sections for purpose, parameter rules (bulleted), and examples. It is slightly lengthy but every sentence adds value. Could be marginally trimmed.

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 complexity of offset-based pagination and no output schema, the description thoroughly explains usage patterns, return values, and connection to sibling tools, making it self-contained.

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?

With 0% schema description coverage, the description fully compensates by explaining offset and length semantics with examples (e.g., negative offset for tail, length ignored for negative), and implicitly covers sessionId as 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 clearly states 'Get more results from an active search with offset-based pagination,' specifying the verb (get), resource (results), and mechanism (pagination), distinguishing it from siblings like start_search or stop_search.

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 is used after start_search and compares it to read_process_output, providing clear context. It does not list explicit alternatives or when-not-to-use, but the usage scenario is well-defined.

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 annotation declares readOnlyHint: true, but the description states 'retrieve and execute it', implying execution with potential side effects. This is a clear contradiction. No further behavioral details are provided beyond the contradictory execution claim.

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 sections and clear formatting, but it is somewhat verbose. It could be more concise while retaining essential information.

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 usage and parameter values adequately, but lacks details about return values, error handling, and what 'execution begins immediately' means. Given no output schema, the agent might be left uncertain about 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 coverage is 0%, so the description must compensate. It does so by listing all valid prompt IDs mapped to numbers and specifying the action enum value. This adds meaning beyond the schema's bare string 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 description clearly states the tool retrieves and executes a specific Desktop Commander onboarding prompt by ID. It distinguishes from sibling tools by focusing exclusively on onboarding prompts and providing a direct numbered list.

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 mapping from user selections (1-5) to prompt IDs and the action parameter. It effectively tells the agent when to use this tool during onboarding. However, it does not explicitly state when not to use it or mention alternative tools.

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

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

Beyond the readOnlyHint annotation, the description discloses substantial behavioral detail: it does not track its own calls or track_ui_event (self-exclusion), persists to tool-history.jsonl, keeps up to 1000 calls in memory while trimming older on-disk history, and replaces outputs over 4 KiB with an omission marker. This gives an agent accurate expectations about data availability and truncation.

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 efficiently structured: a one-sentence purpose, scannable bullet points for use cases, and a compact 'Note:' block for behavioral caveats. The final line about 'DC: ...' referencing adds minor value for intent recognition. Slightly long, but every sentence carries distinct information.

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 tool with no output schema, the description is nearly complete: it covers return shape (chronological list), persistence location, retention limits, output truncation, and self-exclusion. The only meaningful gap is the undocumented filtering semantics of the since and toolName parameters.

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 0%, so the description must compensate for parameter meaning. It partially does: the 'last 1000 calls' limit maps to maxResults' maximum, and 'recent'/'chronological' hints at ordering relevant to the since filter. However, it never explicitly explains that since filters by timestamp or that toolName filters by tool, leaving two of three parameters under-documented.

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 sentence states a specific verb+resource+scope: 'Get recent local tool call history with arguments and outputs.' This unambiguously distinguishes it from all siblings — no other tool in the list claims tool call history as its subject, and the second sentence clarifies the chronological return shape.

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 'Useful for:' section lists three concrete scenarios: onboarding, recovering context after chat history loss, and debugging tool call sequences. This is clear context for when to invoke it. It stops short of a 5 because it doesn't name explicit alternatives or state when-not-to-use conditions, though no obvious sibling competes for this use case.

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, so description adds value by specifying what is returned (summary, success/failure rates, performance metrics), providing context beyond the structured fields.

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 front-loaded, with two clear sentences about purpose and output. The third sentence about referencing is slightly meta but not wasteful.

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 tool with no params and no output schema, the description sufficiently covers purpose and output details, though the exact scope (real-time vs historical) is not clarified.

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?

No parameters exist, so schema coverage is 100%. Baseline for 0 params is 4; the description does not need to add param info.

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 'Get usage statistics for debugging and analysis' with specific verb and resource, and distinguishes from sibling tools like get_config and get_prompts by focusing on usage metrics.

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 only mentions how to reference the tool in instructions, but does not provide guidance on when to use it versus alternatives (e.g., get_recent_tool_calls) or when not to use 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?

Discloses that the tool opens a browser form without pre-filling except for automatically included usage statistics. Describes what the user will fill manually. Annotations (openWorldHint: true) confirm external action, and the description adds specific behavioral context 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 structured with sections and an example, but is verbose, listing all survey questions which could be omitted. Every sentence serves a purpose, but conciseness could be improved.

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 no parameters and no output schema, the description fully covers what the tool does, how to use it, and the user experience. No missing information given the tool's 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?

No parameters exist; schema coverage is 100%. The description adds value by explicitly stating no parameters are needed, reinforcing ease of use. Baseline for zero parameters is 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?

The description clearly states the tool opens a feedback form in the browser. It uniquely identifies the action (open form) and resource (feedback for Desktop Commander), and is distinct from sibling tools which deal with files, processes, and searches.

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 workflow: call immediately when user agrees to give feedback, no need to collect information. States no parameters needed and gives an example interaction, making usage clear without ambiguity.

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 indicate readOnlyHint=false and destructiveHint=true. Description adds behavioral details beyond annotations: automatic REPL prompt detection, error detection, early exit, clean output formatting, and performance debugging. Does not explicitly state destructive behavior but consistent with sending input to processes.

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?

Description is lengthy but well-structured with clear sections (CRITICAL, FILE ANALYSIS PRIORITY ORDER, REQUIRED WORKFLOW, etc.). Front-loaded with key purpose and critical note. Some repetition (e.g., 'ALWAYS USE FOR' and 'NEVER USE ANALYSIS TOOL') but overall 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?

Given 5 parameters, no output schema, and complexity, the description covers usage, workflows, supported REPLs, performance debugging, and parameter details. Completely addresses the tool's context and provides thorough guidance 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?

Schema description coverage is 0%, so description must compensate. It provides brief but meaningful descriptions for all five parameters (pid, input, timeout_ms, wait_for_prompt, verbose_timing), including defaults and purpose, adding value beyond schema types and requiredness.

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?

Explicitly states 'Send input to a running process and automatically receive the response'. Clearly distinguishes from sibling tools by emphasizing it is the primary tool for local file analysis, contrasting with the analysis tool that fails for local files.

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 when-to-use ('ALWAYS use this instead of the analysis tool'), when-not-to-use (analysis tool will fail), and alternatives (command-line tools). Includes priority order and detailed interactive workflow steps.

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 set destructiveHint=true, so the description's 'forcefully terminate' adds some context but does not disclose additional behaviors like potential data loss or irreversibility. It aligns with annotations but adds little extra.

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?

Three sentences, mostly concise. The third sentence about referencing as 'DC: ...' is tangential and adds length without aiding tool invocation.

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 tool with one parameter and no output schema, the description covers purpose and caution adequately. However, it could include a brief note on prerequisites (e.g., PID must exist) for completeness.

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 has 0% description coverage; the description only mentions 'by PID' without explaining what PID means or how to obtain it. This adds minimal value beyond the parameter name.

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 'Terminate a running process by PID.' This is a specific verb-resource pairing that distinguishes the tool from siblings like 'interact_with_process' or 'force_terminate'.

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?

While the description warns 'Use with caution', it does not specify when to use this tool versus alternatives (e.g., 'interact_with_process' for graceful termination) or when not to use it. No explicit context or exclusions provided.

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 provide readOnlyHint. Description adds significant behavioral details: results with [FILE]/[DIR] prefixes, depth behavior, context overflow warnings, full relative paths, [DENIED]/[NOT_FOUND] for access issues, and absolute path recommendation. 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 with sections: purpose, differentiation, output details, depth parameter, context overflow, path notes. Slightly verbose (e.g., repeated absolute path advice) but front-loaded with core listing 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?

No output schema, but description explains output format with examples, error conditions ([DENIED], [NOT_FOUND]), and allowed directories. Differentiates well from 25 sibling tools. Covers parameters adequately except 'origin'.

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 0% but description explains 'path' (absolute path recommendation) and 'depth' (default, meanings of values, context overflow) in detail. The 'origin' parameter is not explained, but it's an enum likely for internal use. Good compensation for the coverage gap.

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?

Clear verb and resource: 'Get a detailed listing of all files and directories in a specified path.' Explicitly distinguishes from sibling tool 'execute_command' by stating 'Use this instead of...'.

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 guidance to use this tool for directory listings instead of ls/dir commands. Provides depth parameter details and context overflow protection, helping the agent decide when and how to use 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 provide readOnlyHint=true, confirming no side effects. Description adds return format details (PID, CPU, memory), adding value beyond 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?

Three sentences, no fluff, front-loaded with key purpose. Every sentence adds 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?

Tool is simple; description covers purpose and return fields. Could mention lack of filtering, but complete for a list-all 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?

No parameters; baseline for 0 params is 4. Description does not need to elaborate on params.

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 'List all running processes' and specifies returned fields (PID, command name, CPU, memory), distinguishing it from sibling tools like kill_process.

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?

Implied usage for listing processes, but no explicit guidance on when to use vs alternatives or when not to use. Sibling tools like 'kill_process' suggest broader context could be added.

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. Description adds detail about returned fields and runtime, enhancing understanding beyond annotations. 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?

Succinct three-sentence description: main purpose, details, and usage hint. No redundancy, every sentence adds 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?

Adequately covers the tool's functionality for a simple read-only list command, mentioning output fields. Without output schema, description compensates well, though it could briefly note if no results are shown.

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?

Input schema has no parameters, so schema_description_coverage is 100%. Description adds no parameter info, which is expected. Baseline score of 3 is appropriate.

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

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

Clearly states 'list all active searches' with specific fields (IDs, types, patterns, status, runtime). Differentiates from sibling list_sessions by noting similarity, making purpose unambiguous.

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

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

Provides context for managing multiple searches and a comparison to list_sessions, implying when to use this tool. However, lacks explicit exclusions or alternative guidance for related tools like start_search or stop_search.

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 readOnlyHint true. Description adds behavioral details about blocked status meaning waiting for input and implications for stuck processes, 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?

Concise and well-structured with bullet points. Every sentence adds value, and the purpose is immediately clear without extraneous 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 read-only, parameterless tool, the description fully covers what the tool does, what data it returns, and includes relevant debugging context. No output schema is needed.

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?

No parameters exists, so schema coverage is 100%. Baseline score of 4 applies as description does not need to compensate for any missing parameter information.

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

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

Clearly states it lists active terminal sessions and specifies the information shown (PID, Blocked, Runtime). Differentiates from siblings by focusing on terminal sessions rather than general processes.

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 context for debugging REPLs, suggesting use to verify sessions before sending input. Does not explicitly exclude alternative tools but gives practical usage 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 destructiveHint=true, signaling potential deletion or modification. The description adds context about path normalization and allowed directories but does not disclose behavior if destination already exists (e.g., overwrite or error). This is a notable gap for a destructive operation.

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 two short paragraphs. The first sentence immediately states the core purpose. The second paragraph contains essential usage notes. No unnecessary information, and structure is front-loaded effectively.

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 simple two-parameter schema and lack of output schema, the description covers purpose, constraints, and path guidance. It lacks details about return values, error conditions, or behavior on conflict, but overall it provides sufficient context for basic usage.

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 has 0% description coverage for both parameters. The description clarifies that source and destination are paths and recommends absolute paths, adding some guidance. However, it does not explicitly describe each parameter's expected format (e.g., source must be an existing file/directory) or constraints beyond paths.

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

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

The description explicitly states the tool moves or renames files and directories, using specific verbs and resources. It clearly distinguishes from sibling tools like write_file or create_directory by focusing on relocation/renaming rather than creation or content modification.

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 guidance on using absolute paths, warnings about relative and tilde paths, and mentions that source and destination must be within allowed directories. However, it lacks explicit 'when not to use' or comparison to alternatives like copy instead of move.

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 openWorldHint. The description adds significant behavioral details: offset/length semantics, performance optimizations, format-specific output, and path restrictions. 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 verbose and could be more concise. It includes extensive details on format handling and workflows, which are valuable but not all essential for basic use. The structure is clear but front-loads information well.

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 (8 params, multiple formats, no output schema), the description covers most needed context: file types, offset/length, URL support, performance, and restrictions. It lacks some details like return value format for all cases, but overall comprehensive.

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?

With 0% schema description coverage, the description compensates fully. It explains all key parameters (offset, length, range, sheet, isUrl) with examples and edge cases, making their meaning and behavior clear beyond the 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?

The description clearly states 'Read contents from files and URLs' with specific format handling for PDF, Excel, images, DOCX, etc. It distinguishes itself from sibling tools like 'execute_command' by recommending its use for viewing files.

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 guidance: prefer over 'execute_command', use offset/length for partial reading, always use absolute paths, and includes an editing workflow for DOCX. It implicitly advises when not to use it (e.g., for URLs, full content read).

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 indicate readOnlyHint=true (non-destructive). Description adds behavioral details: partial failure (failed reads don't stop operation), image handling as viewable content, and path normalization. No contradictions 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?

Description is moderately sized with clear structure. First sentence captures purpose. Some repetition in path guidance could be condensed, but overall 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?

Given no output schema, description covers essential aspects: file reading behavior, image support, failure handling, directory constraints, and path recommendations. Sufficient for a file-reading 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 has 0% description coverage, so description carries full burden. It explains that content is returned with path references and that images are handled. Adds path advice (absolute paths). Could be more specific about array constraints (e.g., max size) but adds significant value beyond 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?

Description clearly states 'Read the contents of multiple files simultaneously' with specifics on content handling (text and images) and lists recognized image types. Distinguishes from sibling 'read_file' by focusing on multiple files.

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 clear usage context: reads multiple files with partial failure handling and allowed directory constraints. Gives path guidance (absolute paths, normalization). However, it does not explicitly mention when not to use or alternative tools like 'read_file' for single files.

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 provide readOnlyHint=true, and the description elaborates with offset behavior, output protection, smart features, and detection states. No contradiction; adds significant value beyond 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 with sections and examples, but somewhat verbose. Redundant phrases like 'This command can be referenced...' could be removed. Front-loaded purpose, but length could be trimmed without losing clarity.

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 tool purpose, all parameters except verbose_timing fully, output protection, and detection states. No output schema, but describes return format partially with examples. Mostly complete for the tool's 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 0%, so description must compensate. It thoroughly explains offset and length with examples, mentions timeout_ms, but does not explicitly describe pid or verbose_timing. Partial coverage, so score 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?

Clearly states 'Read output from a running process with file-like pagination support.' The verb 'read' and resource 'output from a running process' are specific and unambiguous. Distinguishes from siblings like read_file and interact_with_process.

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 detailed parameter usage with examples, including offset semantics and timeout. Does not explicitly state when not to use, but the context and sibling tools imply alternatives. The description gives clear guidance on how to use the tool 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 set destructiveHint=true, but the description adds critical behavioral context: warns about security risks and specifically explains that setting allowedDirectories to empty array grants full file system access. This goes beyond 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: starts with purpose, includes warning in caps, bullet list of keys, and a note on referencing. No unnecessary words; every sentence adds 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 tool has 3 params and no output schema, the description covers parameter semantics, usage warnings, and behavioral context. It complements the annotations and sibling tools (e.g., get_config) well.

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 0%, but the description lists all config keys with their types (e.g., blockedCommands array, defaultShell string), adding meaning beyond the schema. However, the optional 'origin' parameter is not mentioned, a minor gap.

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 'Set a specific configuration value by key.' It lists specific config keys and their types, distinguishing it from sibling tools like get_config (reading) and file/process 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?

Explicit warning: 'Should be used in a separate chat from file operations and command execution to prevent security issues.' Also notes how to reference the command, providing clear when-to-use 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 are minimal, but the description goes far beyond them: it documents state detection (waiting, finished, running), early-exit behavior, Docker/mounted-directory data-loss warnings, Linux-specific tooling expectations, and verbose_timing performance details. No annotation contradiction exists.

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 sections and bullets, but it is far longer than needed. It includes environment-specific boilerplate such as the container ID and repeated admonitions ('ALWAYS USE FOR', 'NEVER USE ANALYSIS TOOL') that could be trimmed. While the core guidance is front-loaded, the excess length reduces clarity and earning per sentence.

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 process-starting tool with no output schema, the description is exceptionally complete: it covers use cases, step-by-step workflows, binary file handling, interactive REPL priority, state reporting, performance debugging, and absolute-path requirements. An agent has everything needed to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does for the main parameters: command is richly illustrated with patterns (python3 -i, node -i, shell pipelines), shell default is stated as bash, and verbose_timing is explained in detail. However, timeout_ms is only implicit in examples and the origin enum is not mentioned at all, leaving a small but real gap.

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

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

The description opens with a specific verb and resource ('Start a new terminal process') and then clearly establishes this as the primary tool for local file analysis, explicitly distinguishing it from the analysis tool that 'CANNOT access local files'. It is unmistakable what the tool does and how it differs from siblings like read_file or start_search.

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

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

The description gives explicit when-to-use and when-not-to-use guidance: 'For ANY local file work, ALWAYS use this tool + interact_with_process, NEVER use analysis/REPL tool.' It also provides a priority order for Python, Node.js, and shell, names alternatives, and states that the analysis tool is browser-only and will fail. This is exemplary usage 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 declare readOnlyHint=true. Description adds that it returns immediate session ID for background search, uses absolute paths, and handles path normalization. Could mention it does not modify files but readOnlyHint covers that. 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?

Well-organized with headings and bullet points, but very verbose. Multiple repeated points (e.g., pro tip about ambiguous queries appears twice, the path note is at the end). Could be shortened while retaining clarity.

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 all aspects for a complex tool: types of searches, pattern matching modes, parameter details, handling ambiguous requests, path requirements, and integration with related tools. No output schema so no missing return info.

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 0% for property descriptions, so the description must compensate. It explains each parameter's meaning, default values, and usage patterns (e.g., literalSearch for special characters, earlyTermination defaults). Comprehensive 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?

Clearly states that it starts a streaming search returning results progressively. Distinguishes from sibling tools like stop_search and get_more_search_results. Specific verb and resource.

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 decision criteria for searchType, literalSearch, and ambiguous queries. Includes multiple examples and when-not-to-use scenarios. References sibling tools for post-search actions.

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 are neutral (readOnlyHint=false, destructiveHint=false). Description adds gracefulness, background process, and 5-minute cleanup behavior. 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?

Description is mostly concise, but includes extraneous meta-comment about referencing format, which adds little value for tool selection.

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 purpose and behavior well, but lacks parameter guidance. For a simple one-param tool, it is moderately complete.

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

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

Schema coverage is 0% so description bears full burden. The single required parameter 'sessionId' is not mentioned or explained in the description.

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 stops an active search using specific verbs and resource. It distinguishes from sibling 'force_terminate' by describing a graceful stop.

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 says when to use it: when found what you need or search is taking too long, and compares to force_terminate. Lacks explicit when-not-to-use but context 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 indicate destructiveHint and readOnlyHint, and the description adds behavioral details: chunking is standard, files over 50 lines generate performance notes, only works within allowed directories, paths are normalized. 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 lengthy with redundancy (chunking instructions repeated) and includes overly detailed process steps. While front-loaded with purpose, it could be streamlined to improve clarity and reduce verbosity.

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?

Despite no output schema, the description covers all essential aspects: file types, modes, chunking strategy, continuation, path handling, and format specifics for DOCX and Excel. Tailored to the tool's complexity and sibling 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 has 0% description coverage, so the description fully compensates. It explains mode (rewrite vs append), content format (string, with Excel and DOCX specifics), path (absolute recommended), and provides examples. Adds meaning for all key parameters beyond schema enumeration.

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 starts with 'Write or append to file contents', clearly stating the verb and resource. It distinguishes from siblings by explicitly saying not to use for PDFs (write_pdf) and not for editing DOCX (edit_block), and explains when write_file is appropriate for creating DOCX.

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 when-to-use (writing text, creating DOCX, Excel) and when-not-to-use (PDFs, editing DOCX), including alternative tool names. Also details chunking process, continuation handling, and path recommendations, giving comprehensive usage 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?

Beyond the destructiveHint annotation, the description details behavioral traits: file naming rules, modes, operations, page breaks, styling support, path handling (absolute paths recommended, relative may fail), and directory restrictions.

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 purpose and rules, then details modes and operations. While comprehensive, it is lengthy; however, the complexity of the tool justifies the verbosity. Remains well-structured.

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

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

For a tool with two modes, multiple operations, and advanced styling, the description is exceptionally complete. It covers all critical aspects including page breaks, styling, path guidance, and examples, leaving no significant gaps.

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?

With 0% schema description coverage, the description thoroughly explains 'path' (via examples), 'content' (with modes and operation schemas), and 'outputPath' (mandatory for modify). However, 'options' parameter is not explained, slightly reducing completeness.

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 'Create a new PDF file or modify an existing one' and explicitly declares 'THIS IS THE ONLY TOOL FOR CREATING AND MODIFYING PDF FILES,' distinguishing it from sibling 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 when-to-use guidance, including rules for filenames, modes (create vs modify), and contrasts with other tools by declaring exclusivity. Also includes instructions like never overwrite original files.

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