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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about checking cloud sync filter blocking, but doesn't disclose what the output indicates (e.g., boolean result, error handling) or any side effects beyond what annotations cover.

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 two sentences, each adding value: the action and the Windows-only caveat. No wasted words, front-loaded with the key action.

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 read-only tool, the description is mostly adequate. It covers purpose and platform constraint. However, lack of output schema means the return value is not described, which would help agents interpret results. Still, the tool is straightforward enough that this is a minor gap.

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

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

The single parameter 'path' has 100% schema description coverage ('Path to check'). The description adds no additional meaning beyond the schema, so 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?

Description clearly states the verb 'Prüft' (checks), the resource 'path for cloud sync filter blocking', and scope 'nur auf Windows relevant'. This distinguishes it from sibling tools like fc_list_processes or fc_kill_process, which have different purposes.

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 mentions Windows relevance, implying when to use (on Windows systems when cloud sync issues are suspected), but doesn't explicitly state when not to use or suggest alternative tools among siblings.

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 idempotentHint=true and destructiveHint=false, so the tool is safe non-destructive and idempotent. The description adds that it modifies files by cleaning problems, but doesn't elaborate on behavior like what happens on dry run or whether modifications are in-place. Given the annotations cover safety, this is adequate but not exceptional.

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

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

The description is well-structured with a clear first sentence, a parameter list, and a summary. It is not overly verbose, but could be slightly more concise by omitting redundant parameter details already present in the schema.

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 8 parameters and no output schema, the description fails to explain the return value or behavior after execution (e.g., what is returned, whether files are modified in-place, error handling). This leaves usability gaps for an AI agent.

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

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

Schema coverage is 100% with clear descriptions. The description lists all parameters with types and defaults, and adds a summary of what is cleaned. However, it mostly reiterates schema info without adding deeper semantics or examples. 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's purpose: cleaning up common file problems like BOM, NUL bytes, trailing whitespace, and line endings. It uses a specific verb ('cleans up') and identifies the resource ('files'). However, it doesn't explicitly differentiate from sibling tools like fc_fix_encoding or fc_validate_json, which may have overlapping 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 is given on when to use this tool versus alternatives, or when not to use it. The description is purely functional and lacks context about prerequisites, edge cases, or preferred use cases.

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 (destructiveHint=true) and idempotent (idempotentHint=true). The description adds that the session is 'removed from the list', which is beyond annotations. No contradiction.

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

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

The description is short and front-loaded. The Args section is clear. Slightly redundant with schema, but acceptable.

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

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

Given the simple tool (2 params, no output schema), the description is adequate. It covers behavior and parameters, though could mention return value or side effects more explicitly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal detail beyond the schema: it mentions 'Session ID' and 'Force termination' which are redundant with schema. No additional semantics.

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

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

The description clearly states the tool terminates a running session and removes it. The verb 'Terminates' and resource 'running session' are specific, and the sibling fc_start_session confirms this tool is its inverse, providing 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 implies use when a session needs to be ended. The sibling fc_start_session indicates the alternative for starting sessions. No explicit when-not-to-use or prerequisites, but the 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 declare destructiveHint=false and readOnlyHint=false, consistent with a copy operation (not destructive, not read-only). However, the description does not disclose behavior like overwriting behavior, permission requirements, or symlink handling, which are important 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 concise but repeats parameter definitions already in the schema. Could be more efficient by focusing on behavioral context rather than listing parameters.

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 and a moderately complex tool (file system mutation), the description omits important details like overwrite behavior, permissions, and symlink handling. It is not fully 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%, so parameters are already well documented. The description adds minimal value beyond restating the schema; a 3 is appropriate as baseline.

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

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

The description clearly states the tool copies a file or directory, with specific verb 'copies' and resource 'file or directory'. It distinguishes from sibling tools like fc_move (move vs copy) and fc_delete_file (delete vs copy), though not explicitly.

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 copy versus alternatives like fc_move, fc_archive, or fc_safe_delete. Does not mention that copy leaves the original intact, which is the key differentiator.

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 idempotentHint=true (repeated calls are safe), destructiveHint=false (non-destructive), and readOnlyHint=false (modification). The description adds that parent directories are created if missing, which is useful beyond annotations. No contradictions, but more behavioral context (e.g., error behavior) would be helpful.

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?

Extremely concise: two lines of description plus structured Args/Returns. Front-loaded key information. 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?

Given the simplicity (1 param, no output schema), the description covers the essential: creation with parent directories. However, could mention what happens on conflict (e.g., existing directory) or return value format. Still adequate for a straightforward 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 coverage is 100%, so the description adds little beyond what the schema provides. The description mentions 'path' but no extra details on formatting or allowed characters. 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 'Creates a new directory (including parent directories)'. The verb 'Creates' and resource 'directory' are specific. It distinguishes from siblings like 'fc_delete_directory' and 'fc_list_directory' by its creation purpose.

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 explicit guidance on when to use this tool versus alternatives. While it's clear for basic creation, the description doesn't mention prerequisites (e.g., permissions, existing parent) or warn against misuse. No mention of 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?

Description adds critical behavioral context beyond annotations: confirms destructiveHint=true and specifies that with recursive=true, ALL contents are irreversibly deleted. Annotations already indicate destructive and idempotent, but description reinforces the irreversible consequence.

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 extremely concise: three sentences with no wasted words. The warning is front-loaded after the basic description, and the Args section clearly maps to parameters.

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 destructive, idempotent tool with two simple parameters and no output schema, the description covers all necessary context: action, arguments, and critical warning about irreversible deletion. No gaps remain.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. Description repeats parameter names and types but adds a critical warning about recursive behavior, which adds value beyond schema alone.

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 (delete a directory) and distinguishes it from sibling tools like fc_delete_file (file-level deletion) and fc_safe_delete (safe delete with trash). The verb 'deletes' and resource 'directory' are specific and unambiguous.

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

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

The description explicitly warns about the irreversible nature when recursive=true, guiding the agent to use this tool only when intentional. It implies not to use for safe deletion (use fc_safe_delete instead) and provides clear condition for non-empty directories.

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. Description reinforces that deletion is irreversible with 'no recycle bin', adding important behavioral context 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?

Extremely concise, two key pieces of info (action, warning) in few words. Front-loaded with purpose. No wasted sentences.

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

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

Given simple single-parameter tool with no output schema and strong annotations, description is sufficient. Could add a note about return value or behavior on failure, but not essential.

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%. Description adds no extra meaning beyond what's in the schema; 'path' is clear. Baseline 3 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 it deletes a file. No ambiguity; verb 'deletes' + resource 'file' is specific. Distinguishes from sibling 'fc_safe_delete' by not mentioning safety features.

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?

Warns about irreversibility, implying caution. Does not explicitly state when to use this vs. alternatives like fc_safe_delete, but the warning suggests avoiding unless certain.

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, so description reinforces this with operation details. It adds clarity on line-based nature and required parameters, but doesn't disclose edge cases (e.g., behavior if file doesn't exist, or what happens with invalid line numbers).

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 concise with a clear header line and structured Args/Examples sections. Every sentence adds value, and examples are highly informative.

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 explains the effect but not the return value (e.g., success message). Annotations cover destructive behavior. For a line-editing tool with 5 parameters, the description is nearly complete, lacking only return details.

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

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

Schema coverage is 100%, but description adds value by explaining the relationships between parameters (e.g., end_line optional for insert) and providing examples. However, some nuance about line ranges could be clearer.

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 a file line-based with three specific operations (replace, insert, delete), and differentiates it from siblings like fc_write_file (overwrites whole file) and fc_str_replace (string-based replace).

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?

Description includes examples showing when to use each operation, but does not explicitly state when not to use this tool (e.g., for whole-file edits or string substitutions) or reference alternatives among siblings.

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 not read-only but idempotent and non-destructive. The description adds value by explaining it repairs specific mojibake patterns and mentions dry-run and backup creation, which clarify safety. 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 relatively concise at 81 words, but includes an 'Args' section that largely duplicates the schema. It could be streamlined while retaining the helpful mojibake examples. No front-loading issue.

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 exists, but the description fails to explain what the tool returns (e.g., list of issues in dry-run, modified file path, or success status). It also omits details like supported encodings or behavior if no errors found. For a file-modifying tool, this is a significant gap.

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

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

Schema coverage is 100%, so the description adds minimal new meaning. It repeats parameter names with slightly different wording ('Only show problems', 'Create backup'), which provides marginal clarity over the schema's existing descriptions.

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 detects and repairs encoding errors (mojibake, double UTF-8). It provides specific examples of patterns, making the purpose unambiguous. Among sibling tools, none address encoding issues, so it is well-distinguished.

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 use when encoding errors are present but gives no explicit guidance on when to use vs. alternatives, prerequisites, or exclusions. The sibling list includes no similar tools, but the description could still be clearer about 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 (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already indicate safe read behavior. The description goes beyond by detailing what changes are detected and where snapshots are saved (%TEMP%/.fc_snapshots/), but could add more about snapshot persistence or cleanup.

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 two sentences plus bullet points, front-loaded with purpose, and provides essential info with no wasted words.

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 lack of output schema and complex detection logic, the description explains what it detects and where snapshots are stored. However, it doesn't detail return format or behavior when no snapshot exists.

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

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

Schema coverage is 100% but descriptions are minimal ('Save snapshot', 'Filter extensions'). The description adds context: 'Filter file extensions' and explains extensions usage indirectly, but could be clearer about format (e.g., comma-separated). Higher than baseline 3 due to added detail.

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 'Compares the current state of a directory with a saved snapshot' and lists detected changes (new, modified, deleted files). This verb+resource is specific and distinct from sibling tools like fc_list_directory or fc_checksum.

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 context on when to use (comparing directory state) and hints at saving snapshots, but does not explicitly tell when not to use or compare with alternatives like fc_detect_duplicates or fc_file_info.

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, destructiveHint false, idempotentHint true, so safety is clear. The description adds return value format (formatted list with icons) but no additional behavioral traits like path validation or error handling.

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 at 3 sentences plus args list. Front-loaded with action; could combine the returns line for efficiency, but overall 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?

Given no output schema, the description mentions return format. With 3 simple params fully covered by schema and annotations, it is adequate but lacks edge case behavior like symbolic links or permission errors.

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

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

Schema coverage is 100%, so baseline is 3. The description slightly adds context for depth (recursive listing) and show_hidden, but mostly repeats schema parameters.

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

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

The description clearly states the tool lists files and subdirectories, with a specific verb and resource. It distinguishes from file operations like fc_read_file and directory creation/deletion tools among 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 does not explicitly state when to use this tool vs alternatives like fc_search_files or fc_file_info. It provides basic usage context but no exclusions or scenarios.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description only needs to add context. It adds cross-platform detail and return format, which is sufficient beyond the safety profile.

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 extremely concise: a one-sentence main action, followed by clear args and returns sections, and a note. No wasted words; information is efficiently 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?

For a simple list tool with one optional parameter, the description covers the core behavior and return format. It lacks error handling or rate limit details, but given the simplicity and annotations, it is mostly 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 100% with the parameter description 'Filter by process name' matching the description's args. Thus the description adds no new meaning beyond what the schema already provides.

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

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

The description clearly states the tool lists running system processes, and the title 'List Processes' reinforces this. It distinguishes from siblings like fc_kill_process by focusing on listing rather than modifying 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?

No explicit guidance on when to use this tool versus alternatives. While it mentions OS-specific commands, it doesn't provide usage context or exclude alternatives like fc_kill_process for process management.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so description mainly needs to clarify scope (active and ended). It adds that sessions have a 'status' field, which is useful but not detailed.

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, no wasted words. Front-loaded with 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?

Minimally complete: no output schema, so description doesn't detail the return format (e.g., columns, pagination). It mentions 'Table' and 'status' but lacks specifics like session IDs or timestamps.

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 description does not need to add param info. Schema coverage is 100% (no params), baseline 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 states it lists all active and ended sessions, which is clear and specific. However, it does not differentiate from sibling tools like fc_list_searches or fc_list_directory, though the resource (sessions) is distinct.

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 versus alternatives like fc_start_session or fc_close_session. The agent might benefit from knowing this is for viewing session history, not modifying.

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 show destructiveHint=true (destructive operation) and readOnlyHint=false. The description adds that it modifies file system by moving/renaming, which aligns. No contradiction. For a file move tool, this is sufficient given annotations.

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

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

The description is concise with two paragraphs: first line stating purpose, then structured args and examples. The examples are front-loaded and helpful. Slightly verbose due to docstring formatting 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 the simple operation (move/rename) with annotations covering destructive nature and no output schema needed, the description sufficiently covers key aspects. Could be more complete with notes on overwrite behavior or cross-drive moves.

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

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

Schema coverage is 100% with minLength=1 and descriptions 'Source path' and 'Destination path'. The description adds slightly more by showing examples with concrete paths, but doesn't add significant meaning beyond schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool moves or renames a file/directory with a specific verb and resource. It distinguishes from siblings like fc_copy or fc_archive by explicitly using 'move/rename' and showing different name/directory examples.

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 basic usage via examples but lacks guidance on when to use this over alternatives like fc_copy (which copies) or fc_batch_rename (for batch). No explicit when-not or prerequisites are mentioned.

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, destructiveHint=false, and idempotentHint=true, setting clear safety expectations. Description adds behavioral context: supports text and binary files (Base64 return), handles encoding, and line limits, which 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?

Description is concise and structured with Args, Returns, and Examples sections. Front-loaded with primary action. Slightly redundant with schema but clear.

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 schema covers parameters fully and annotations provide safety profile, the description adequately covers behavior and return. However, missing explicit info on possible errors (file not found, permission) and output schema details (since no output schema exists, description could elaborate on return structure).

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

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

Schema coverage is 100%, so the schema already documents parameters. Description repeats path, encoding, and max_lines but adds examples and default value clarification. No additional semantic detail 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?

The description clearly states the tool reads file content, with specific verb and resource. It distinguishes from write tools and editing tools, but not from multiple file read (fc_read_multiple_files) which exists among 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?

Description implies use for reading file content but does not provide guidance on when to use vs alternatives like fc_read_multiple_files or fc_file_info. No explicit when-not-to-use or prerequisites.

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, indicating no side effects. The description adds that it returns contents with separators, which is consistent but not extensive (e.g., no mention of file size limits beyond the 20-item array constraint from schema).

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 succinct, front-loaded with the main action, and includes structured sections for args and an example. 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 simple tool with clear annotations and a complete schema, the description is sufficient. It does not need an output schema since it returns file contents with separators. It covers key aspects 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 coverage is 100% with descriptions for both parameters. The description repeats parameter info but adds an example and a comment about max_lines_per_file, providing slight additional 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 'Reads multiple files at once and returns their contents', specifying the action (read) and resource (multiple files). It is well differentiated from its sibling 'fc_read_file' which reads a single file.

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 multiple files, but does not explicitly state when to use this tool versus alternatives like 'fc_read_file'. It lacks guidance on file path formats or error handling.

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 non-readonly and non-destructive. The description adds context about the newline parameter and provides examples showing behavior for different languages. There is no contradiction with annotations.

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

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

The description is concise: a single line for purpose, a clear args list, and helpful examples. No wasted words, information is front-loaded 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 simple input-sending tool with 3 parameters and no output schema, the description covers all necessary information: how to use, parameter details, and example use cases.

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 covers 100% of parameters with descriptions. The description adds value by providing examples for the input parameter (Python vs Shell) and clarifying the default for newline, exceeding schema 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?

The description states 'Sends input to a running session,' which is a specific verb-resource pair. It clearly distinguishes from sibling tools like fc_start_session (starts a session) and fc_list_processes (lists 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?

The description implies usage when you have a running session and need to send input, but does not explicitly contrast with alternatives or state prerequisites. The context is clear enough for this simple tool.

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

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

No annotations are provided, so the description carries the full burden. It fails to disclose behavioral traits such as whether the setting is persistent, affects all subsequent calls, or requires any prior state. Essential context is missing.

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, front-loaded with the key verb and resource, and contains no unnecessary words.

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?

As a simple setter tool with no output schema, the description is too brief. It lacks context on scope (e.g., session duration) and side effects, which is needed for an agent to use it properly.

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

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

Schema coverage is 100%, and the parameter is fully defined by the enum. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the verb (Set) and resource (output language for FileCommander tools). It distinguishes from sibling tools which deal with processes, input, validation, etc.

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 is provided on when to use this tool vs alternatives or what prerequisites exist. The description only states what it does, missing context on when it should or should not be invoked.

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=false indicating this is a mutation tool. The description adds critical behavioral context: it redirects deletions (fc_delete_file, fc_delete_directory) to trash. 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?

The description is a single, efficient sentence with clear action and effect. No wasted words.

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 simplicity (single boolean parameter, no output schema), the description is complete enough. It explains the effect on two sibling tools, which aids contextual understanding.

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 provides full description for the only parameter 'enabled' (boolean). The description does not add additional parameter semantics beyond the schema's, so 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 toggles safe mode, and explicitly explains that when enabled, delete operations are redirected to trash. This is specific and differentiates it from other file operation tools.

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

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

The description implies when to use: when you want delete operations to go to trash instead of permanent deletion. However, it does not explicitly mention alternatives or when not to use, but the 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?

Beyond annotations (destructiveHint=true), discloses that an error is returned for non-unique occurrences, and that empty new_str deletes the old_str. This is critical behavioral context not captured by 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?

Highly concise: a brief one-sentence summary then clear args, returns, important note, and examples. Every sentence is essential and 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?

Tool has 3 params with 100% schema coverage, no output schema, but description fully explains behavior, constraints, and return. No gaps exist for correct use.

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

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

Schema coverage is 100%, so baseline is 3. But the description adds exceptional value: explains uniqueness constraint for old_str, shows new_str can be empty (delete), and includes realistic examples that clarify parameter usage. This elevates above baseline.

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

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

The description clearly states it replaces a unique string in a file with another, using specific verbs and resources. It distinguishes from siblings like fc_edit_file and fc_batch_rename by emphasizing uniqueness constraint.

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

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

Explicitly states that old_str must occur exactly once, and warns about errors for 0 or >1 occurrences. Provides three practical examples showing when to use it (rename, add import, delete line), which implicitly guides against alternatives.

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

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

Annotations already provide readOnlyHint, idempotentHint, etc. The description adds that it is a read-only network tool and that private targets are blocked by default with allow_private override. 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 sentences, concise and front-loaded with the main action. Every sentence earns its place, summarizing modes and constraints efficiently.

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, the description explains what is returned based on mode but does not specify output format (e.g., JSON, raw text) or error handling. Overall adequate for a simple fetch 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 baseline is 3. The description adds a summary of modes and notes the allow_private override, providing some additional context 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 it fetches a webpage and returns content based on mode (extract, raw, links, forms, headers). It distinguishes from sibling tools which are mostly file/process 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 implies usage for web fetching and mentions it is read-only with default blocking of private targets. It does not explicitly state when not to use or provide alternatives, but context with sibling tools makes it clear.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, which the description reinforces with the overwrite warning. The description adds specific behavioral traits: creates directories if missing and the overwrite warning. However, it doesn't detail behavior on failure (e.g., partial writes) or concurrency issues. With annotations present, this is adequate but not exceptional.

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 clear sections for args, returns, and warnings. It front-loads the core purpose. A minor improvement: the warning could be more prominent (e.g., bold). Still, it's efficient and 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?

Given the tool's complexity (4 params, no output schema, destructive nature), the description covers the key aspects: purpose, required vs. optional params, and the overwrite risk. It could mention that the return value includes file size or error details, but omission is acceptable. No output schema reduces the need for return value details.

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

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

Schema coverage is 100% with each parameter having a description. The description mirrors the schema without adding new semantic context. For example, it repeats 'append' and 'create_dirs' descriptions but doesn't explain when to use append vs. overwrite or the implications of create_dirs=true (e.g., risk of creating unintended directories). 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 verb 'writes content to a file' and specifies 'creates the file if it does not exist'. This distinguishes it from siblings like fc_edit_file (modifies) and fc_delete_file (removes).

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 warnings about overwriting and optional parameters. However, it doesn't specify when to use this vs. sibling tools like fc_edit_file or fc_copy. The warning implies careful use, but alternatives are not named.

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