Server Quality Checklist

Tool Scores

• fc_copyC
  2.8/5.0
  Behavior2/5

  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.

  Conciseness3/5

  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.

  Completeness2/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines2/5

  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.

• fc_set_languageB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden. It states the tool sets the output language, but does not disclose whether the change is persistent, applies globally or per-session, or requires any permissions. For a mutation tool, this is insufficient behavioral detail.

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

  Conciseness5/5

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

  The description is a single sentence with no superfluous information. It is front-loaded and efficient, earning its place without waste.

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

  Completeness3/5

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

  Given the tool's simplicity (one parameter, no output schema), the description is fairly complete. However, it lacks information on scope and persistence of the language setting. For a simple setter, this is adequate but not exemplary.

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

  Parameters3/5

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

  Schema coverage is 100% and the parameter 'language' has a description 'Language code' with enum values. The tool's description adds 'Set the output language' but does not elaborate on the meaning of each code or how it affects output. Baseline 3 is appropriate as the schema already provides the necessary detail.

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

  Purpose4/5

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

  The description clearly states the verb 'Set' and the resource 'output language for FileCommander tools'. It distinguishes itself from sibling tools which are file operations, as this is a configuration tool. However, it could be more specific about what 'output language' entails (e.g., UI language or error messages).

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

  Usage Guidelines2/5

  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. It does not specify prerequisites, typical use case, or that it should be called before other FileCommander tools. The description lacks any context for appropriate usage.

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

• fc_list_sessionsB
  3.4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters4/5

  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.

  Purpose4/5

  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.

  Usage Guidelines2/5

  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.

• fc_create_directoryA
  3.6/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines2/5

  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.

• fc_list_directoryA
  3.6/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• fc_read_fileA
  3.6/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• fc_list_processesA
  3.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the tool is safe and idempotent. The description adds value by noting platform-specific commands (tasklist/ps) and the return structure (PID, name, memory), which are not captured in annotations.

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

  Conciseness4/5

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

  The description is concise, using bullet-style sections for args and returns. It is front-loaded with the main purpose. The note about platform commands is useful, though the Args/Returns formatting could be slightly more streamlined.

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

  Completeness4/5

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

  Given the simplicity of the tool (1 optional param, no output schema, clear annotations), the description is reasonably complete. It covers purpose, usage, return format, and platform specifics. There is no output schema, so the returns section is helpful.

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

  Parameters3/5

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

  Schema coverage for the single parameter is 100%, and the description adds the same description as in the schema. The description does not explain the format of the filter string (e.g., wildcards, exact match), so it does not add significant meaning beyond the schema.

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

  Purpose4/5

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

  The description clearly states that the tool 'lists running system processes', which is a specific verb-resource combination. It also mentions the optional filter and cross-platform behavior. However, it does not differentiate itself directly from sibling tools like 'fc_kill_process' or 'fc_start_process', though the use case is distinct enough.

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

  Usage Guidelines3/5

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

  The description implies usage for listing processes, but does not explicitly state when to use this versus alternatives (e.g., for detailed info). The 'Returns' section hints at what to expect, but no when-not-to-use guidance is provided.

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

• fc_read_multiple_filesA
  3.8/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• fc_send_inputA
  3.9/5.0
  Behavior3/5

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

  Annotations indicate non-destructive (destructiveHint=false) and non-idempotent (idempotentHint=false) behavior. The description adds the detail that a newline is appended by default, but does not disclose other behavioral traits like error handling or character encoding, which would be useful given no output schema.

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

  Conciseness4/5

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

  The description is concise with 4 lines plus examples, no fluff. The examples are helpful and placed after the parameter list, though could be slightly more streamlined.

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

  Completeness4/5

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

  Given the tool's moderate complexity (3 parameters, no output schema), the description covers the essential details (what, how, examples). It lacks return value information but is sufficient for correct invocation.

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

  Parameters4/5

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

  The input schema has 100% coverage, so baseline is 3. The description adds value by showing examples for each input string format (Python code, shell command) and clarifies the newline default behavior, earning a 4.

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

  Purpose5/5

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

  The description clearly states it sends input to a running session, using specific verb+resource structure. It also distinguishes from sibling tools like 'fc_start_session', 'fc_read_output', and 'fc_close_session' by focusing on input delivery to an active session.

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

  Usage Guidelines3/5

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

  The description provides clear context (sending input to a running session) and examples for Python and Shell, but does not explicitly state when not to use this tool (e.g., for starting a session or reading output) or recommend alternatives.

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

• fc_write_fileA
  3.9/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• fc_close_sessionA
  4.1/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• fc_moveA
  4.1/5.0
  Behavior5/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• fc_check_cloud_lockA
  4.2/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is a safe, read-only operation. The description adds valuable context about the cloud sync filter domain, complementing the annotations without contradiction.

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

  Conciseness5/5

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

  The description consists of two concise sentences with no unnecessary words, front-loading the core purpose. It is appropriately sized for the tool's simplicity.

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

  Completeness4/5

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

  The description covers the tool's purpose, relevant OS, and the type of blocking. However, it omits expected return values or behavior (e.g., boolean or error), which would be helpful given no output schema. Still, for a one-parameter check, it is largely complete.

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

  Parameters3/5

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

  The input schema has 100% coverage with one parameter described as 'Path to check.' The description does not add further details about the parameter beyond what the schema already provides, so it meets the baseline without enhancement.

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

  Purpose5/5

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

  The description clearly states the tool checks if a path might be blocked by a cloud sync filter (cldflt.sys). The verb 'prüft ob' and specific resource ('Pfad') uniquely identify its purpose, and it is distinct from siblings as no other tool mentions cloud lock.

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

  Usage Guidelines4/5

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

  The description explicitly notes 'Nur auf Windows relevant,' providing clear context for when to use the tool. However, it does not mention when not to use it or suggest alternatives, though no direct sibling alternative exists for this specific check.

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

• fc_set_safe_modeA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• fc_fix_encodingA
  4.3/5.0
  Behavior4/5

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

  The description discloses that the tool repairs common mojibake patterns and explains the dry_run and create_backup params. Annotations indicate idempotentHint=true (repairs are safe to reapply) and destructiveHint=false (no destructive side effects), which aligns with the description. The only minor gap is not explicitly stating that the file is modified in place.

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

  Conciseness4/5

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

  The description is efficient with two paragraphs: first defining the purpose and listing arguments, then giving specific repair examples. It front-loads the core action (detect and repair encoding errors). Minor improvement possible by moving examples lower.

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

  Completeness4/5

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

  Given no output schema, the description could mention return values (e.g., count of fixes), but the examples and parameter descriptions provide enough for basic use. The tool's complexity is low, so the description is mostly complete.

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

  Parameters4/5

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

  The description adds value beyond the schema by listing the three arguments (path, dry_run, create_backup) with slightly more context (e.g., 'Show only problems' vs schema's 'Preview only'). Since schema description coverage is 100%, the baseline is 3, but the explicit listing and examples add extra clarity.

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

  Purpose5/5

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

  The description clearly states that the tool detects and repairs encoding errors, with specific examples like mojibake and double UTF-8. It also distinguishes itself from sibling tools like fc_fix_json and fc_str_replace by focusing on encoding issues.

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

  Usage Guidelines4/5

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

  The description implies use for files with encoding errors, but does not explicitly state when to use this tool vs alternatives like fc_cleanup_file or fc_str_replace. However, the specific examples of German umlauts and euro sign repairs provide clear context for typical use cases.

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

• fc_delete_fileA
  4.4/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• fc_edit_fileA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• fc_folder_diffA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• fc_web_fetchA
  4.4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• fc_cleanup_fileA
  4.5/5.0
  Behavior5/5

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

  Explicitly lists what it removes (BOM, NUL bytes, trailing whitespace, line endings) and mentions dry_run for preview. Annotations already indicate readOnlyHint=false (modifies), destructiveHint=false (safe but destructive?), idempotentHint=true (safe to re-run). Description adds context about what gets modified, which complements annotations.

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

  Conciseness4/5

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

  Clear structure with arg list and summary. At 16 lines it's somewhat lengthy but each line is informative. Could potentially combine some lines, but overall efficient.

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

  Completeness4/5

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

  Given 8 parameters, 100% schema coverage, and no output schema, the description adequately covers what the tool does and each parameter. It lacks information about return values (e.g., summary of changes), but since no output schema, a basic listing of what it cleans suffices.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. Description adds semantic groupings (lists types of cleanup, explains dry_run), provides option values for normalize_line_endings, and clarifies extensions filter format. However, it doesn't explain default behavior when specific cleanups are enabled/disabled beyond the defaults in schema.

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

  Purpose5/5

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

  Clearly states it cleans up files from common problems (BOM, NUL bytes, trailing whitespace, line endings). The verb 'cleans up' and resource 'file' are specific, and the description distinguishes it from siblings like fc_fix_encoding or fc_fix_json.

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

  Usage Guidelines4/5

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

  The description lists the problems it cleans, implying when to use it (files with those issues). No explicit when-not to use or alternatives, but among siblings like fc_fix_encoding (presumably fixes encoding specifically), this tool's generic cleanup is clear.

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

• fc_delete_directoryA
  4.7/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• fc_str_replaceA
  5/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters5/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.