Server Quality Checklist

Tool Scores

• generate_smart_docD
  1.3/5.0
  Behavior1/5

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

  With no annotations provided, the description must disclose behavioral traits, but it only lists two parameter hints ('file_path', 'code_snippet') and does not explain what happens when the tool is invoked—whether it reads files, generates output, mutates state, or what the return format is. This is a significant gap for a tool with no annotation support.

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

  Conciseness2/5

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

  The description is short, but it is under-specified rather than appropriately concise. The phrase 'Universal tool for documentation and audits' is vague filler, and the two parameter hints are too sparse to be useful. It does not front-load the core purpose or provide structured, valuable information.

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

  Completeness1/5

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

  Given the tool has 5 parameters (2 required) and no output schema details, the description is grossly incomplete. It fails to explain the required inputs or any behavioral or output context, making it inadequate for an agent to select and invoke the tool correctly.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must compensate. It only provides minimal meaning for 'file_path' and 'code_snippet', but completely ignores the required parameters 'doc_content' and 'audit_results', as well as 'language'. This leaves the agent without crucial information for invocation.

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

  Purpose2/5

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

  The description 'Universal tool for documentation and audits' is vague and tautological, restating the tool's name without specifying a concrete action. It does not mention what the tool actually does with the provided inputs (e.g., 'doc_content', 'audit_results') and fails to distinguish it from sibling tools like 'scan_project_files' or 'global_security_audit'.

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

  Usage Guidelines1/5

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

  There is no guidance on when to use this tool, what scenarios it is appropriate for, or how it relates to alternatives. The description gives no context for selection, making it impossible to know whether to choose this tool over its siblings.

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

• evaluate_and_refactorC
  2.4/5.0
  Behavior2/5

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

  The description only states that it generates optimized code, with no disclosure of side effects like file modification, reversibility, or required permissions. Since no annotations are provided, the description fails to convey crucial behavioral traits such as whether the tool is read-only or destructive.

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

  Conciseness2/5

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

  The description is a single fragment, under-specified and lacking proper structure. It is too terse to convey necessary information and reads as an incomplete note rather than a concise yet complete description.

  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?

  This is a complex tool with no annotations, and the description provides minimal context. It does not explain what the output contains despite an output schema being present, nor does it clarify its relationship with sibling tools. The agent cannot fully understand the tool's scope, return value, or side effects from this description alone.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not mention either parameter. The purpose of 'custom_rules' is entirely unexplained, and even 'file_path' is only implicitly inferable from the tool's purpose. The description does nothing to compensate for the schema's lack of parameter details.

  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 the tool performs a health audit and generates optimized code, which clearly identifies its primary actions. However, it does not differentiate from sibling tool 'refactor_and_optimize', and the term 'health audit' is somewhat vague without further elaboration.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, exclusions, or comparison with sibling tools such as 'refactor_and_optimize' or 'global_security_audit', leaving the agent without selection context.

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

• refactor_and_optimizeC
  2.6/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It adds the detail about handling case-insensitivity and deep path discovery, but fails to disclose side effects, mutability, permission requirements, or any risks associated with refactoring. As a refactor tool, the potential for modifying code is not explicitly stated.

  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 very short and front-loaded with the main action. However, the second sentence 'Handles case-insensitivity and deep path discovery.' is vague and may not add clear value. It is still concise and appropriately sized for a tool with minimal 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?

  The tool has two parameters, an output schema, and no annotations. The description is far too minimal to provide complete context for an agent to select and invoke it correctly. It lacks information about when to use it, what inputs are expected, and what side effects or outputs to anticipate. The presence of an output schema reduces the need to explain return values, but all other contextual aspects remain under-specified.

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

  Parameters1/5

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

  The schema has 0% description coverage, and the description mentions no parameter names or meanings. It does not explain what 'file_path' should point to or what 'custom_rules' does. The description's mention of 'case-insensitivity and deep path discovery' is tangential and could relate to file_path handling, but it is not explicit enough to compensate for the missing schema descriptions.

  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's primary function: 'Refactors and optimizes code.' This is a specific verb+resource pairing. However, it does not differentiate from the sibling tool 'evaluate_and_refactor', which likely has similar functionality, so it lacks sibling distinction.

  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?

  There is no guidance on when to use this tool versus alternatives like 'evaluate_and_refactor'. The description mentions 'case-insensitivity and deep path discovery' but does not explain the context or prerequisites for use. No exclusions or alternative recommendations are provided.

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

• apply_syncB
  3.4/5.0
  Behavior2/5

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

  With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It implies a mutating operation ('applies code patches') but does not disclose side effects, reversibility, or any requirements such as permissions or safety mechanisms.

  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 concise and front-loaded with a purpose statement followed by a compact parameter list. No unnecessary information is included, and the structure is easy to parse quickly.

  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?

  The description adequately covers the parameters and the overall action, especially given the presence of an output schema. However, it lacks usage context and confusingly overlaps with the sibling 'heal_dependency_calls', and does not mention any prerequisites or project setup, leaving some gaps.

  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?

  The input schema provides zero parameter descriptions, but the description compensates fully with an Args section explaining symbol_name, change_type (with enumerations), and metadata (with expected keys). This goes beyond the schema's bare types and adds significant meaning.

  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 it 'Generates and applies code patches to heal broken call-sites across the project', identifying a specific action and resource. However, it does not explicitly distinguish itself from the sibling tool 'heal_dependency_calls', which likely has overlapping functionality.

  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?

  The description provides no guidance on when to use this tool versus alternatives such as 'heal_dependency_calls' or other refactoring tools. There is no mention of prerequisites, contexts, or situations where another tool might be preferred.

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

• scan_project_filesA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full responsibility. It reveals a read-only behavior and a clear scope, but the meaning of 'documentable' is ambiguous, and there is no mention of edge cases or limitations. This is adequate but not rich.

  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, clear sentence that immediately states the primary purpose. It is concise and front-loaded with the action 'Returns'.

  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?

  With no output schema and no annotations, the description must provide full context. It lacks details about the return format (e.g., file paths vs. names), criteria for 'documentable', and any potential errors. For a simple scan tool, more specificity would be needed for complete understanding.

  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 tool has zero parameters, so the description need not explain parameter behavior. The baseline for no parameters is 4, and the description does not interfere with that.

  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 returns a list of source files, with a specific scope ('current project root') and qualifier ('documentable'). This distinguishes it from sibling tools like generate_smart_doc or refactor_and_optimize, 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.

  Usage Guidelines2/5

  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 versus alternatives. It simply states what it does without mentioning prerequisites, typical use cases, or exclusions.

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

• predict_impactA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the fallback behavior when no symbol is given (analyzes dependencies on the file itself), but it does not state whether the operation is read-only, whether there are side effects, permission requirements, or what constitutes an 'impact'. It adds some context but leaves significant gaps.

  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, front-loaded with the main action and immediately clarifying the optional symbol behavior. Every word contributes meaning, with no redundancy or extraneous information.

  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 presence of an output schema (so return values need not be explained) and the tool's two-mode behavior, the description covers the core functionality adequately. It could be enhanced with explicit safety notes or usage comparisons, but overall it is sufficient for a tool of this complexity.

  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 explains that 'symbol' refers to variables, functions, or classes, and describes the behavior when 'symbol' is absent. Since schema description coverage is 0%, this added context is crucial. It lacks format or syntax examples, but meaningfully maps parameters to behaviors, which is more than the schema alone provides.

  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's purpose: analyzing the impact of changing a symbol or, if omitted, the file. It uses a specific verb ('analyzes') and names the resource types (variable, function, class). However, it does not explicitly contrast with sibling tools like inspect_contract_change, so it is clear but not fully differentiated.

  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 implicit usage context by explaining the dual behavior with and without a symbol, but it does not explicitly state when to prefer this tool over alternatives or any exclusions. It is implied that this is for change-impact analysis, but no comparison to siblings is given.

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

• global_security_auditA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the scope ('ENTIRE project') and focus, but does not state whether the scan is read-only, if it modifies anything, or what it does with findings. The word 'scans' implies non-destructive but it is not explicit, leaving a gap.

  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, front-loaded with the action, and ends with a clear usage trigger. Every word earns its place with no fluff.

  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?

  For a zero-parameter tool with an output schema, the description gives enough to know what it does and when to use it. It does not dwell on limitations or result handling, but this is not critical given the schema. Slight ambiguity with sibling tools prevents a 5.

  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 tool has zero parameters, so the description is not expected to explain parameters. The schema covers all 0 parameters, and the baseline for 0 params 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 a specific action ('Scans the ENTIRE project') and identifies the resource and scope (secrets, keys, vulnerabilities). It is clear but does not explicitly differentiate from sibling tools like guardian_scan or scan_project_files, warranting a 4 rather than a 5.

  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 gives explicit usage guidance: 'Use this before pushing code to GitHub/GitLab.' This is clear context, but it does not mention alternatives or exclusions, so it falls short of a 5.

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

• guardian_scanA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses conditional behavior based on parameters (scan_uncommitted, target_path, default) but does not state whether the operation is read-only, has side effects, or requires certain permissions. This is a gap for a security tool.

  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 concise and front-loaded with 'Versatile security scanner.' The three bullet points each explain a distinct scenario in a single line, with no redundant information.

  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?

  For a tool with 2 optional parameters and an output schema, the description covers the main behavior well. The only missing context is the precedence rule when both parameters are provided, and it does not mention any prerequisites (e.g., Git repo for scan_uncommitted). Overall, it is fairly 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?

  Schema description coverage is 0%, so the description must compensate. It effectively explains both parameters: scan_uncommitted triggers Git diff scanning, target_path scans a specific file/folder, and default scans cwd. However, it does not specify precedence when both parameters are provided, leaving ambiguity.

  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 it is a 'security scanner' and explains its versatile behavior through parameter-based conditions. It distinguishes itself from siblings by showing different scan scopes (uncommitted, specific path, current directory), but does not explicitly name alternative 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 provides clear when-to-use guidance by explaining the behavior for each parameter: 'If scan_uncommitted is True', 'If target_path is provided', and the default. However, it does not mention exclusions or explicitly compare with sibling tools like scan_project_files or global_security_audit.

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

• inspect_contract_changeA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full responsibility. The verb 'Analyzes' suggests a read-only operation, and there is no mention of destructive actions. However, the description does not explicitly state that it makes no modifications, nor does it describe any side effects, prerequisites (e.g., must be in a git repo), or limitations (e.g., only detects certain types of changes). It is adequate but lacks explicit non-mutating assurance or additional behavioral context.

  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 that is front-loaded with the key verb and object, then provides clarifying details in parentheses. It contains no filler or redundancy. Every word contributes to conveying the tool's purpose.

  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 tool has no parameters and an output schema exists, so return values are covered externally. The description provides enough context for a simple inspection tool, but it could be more complete by referencing the sync workflow or sibling tools (e.g., 'run this before apply_sync'). Given the minimal complexity, the description is nearly complete for a standalone inspection tool, though it gains no additional context from annotations.

  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 tool has zero parameters, and the description adds no parameter details (which is appropriate). Per guidelines, a baseline of 4 is given for tools with no parameters. The description focuses on the action and outcome, and since there are no inputs, there is nothing missing.

  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 uses a specific verb 'Analyzes' and identifies a clear resource ('uncommitted changes') with a targeted outcome ('identify modified Contracts that require Sync'). This goes beyond a simple restatement and distinguishes the tool from sibling tools like apply_sync, which likely applies the sync, and scan_project_files, which scans broader project files. The purpose is precisely scoped.

  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 a use case (inspecting before syncing) but does not explicitly state when to use this tool versus alternatives like apply_sync or scan_project_files. It mentions 'require Sync' as context but stops short of saying 'use this to detect changes before running apply_sync' or any exclusion criteria. There is a clear context but no direct guidance on alternative selection.

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

• heal_dependency_callsA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It does disclose a key behavioral trait: it 'proposes' updates rather than applying them, and scopes to 'all files' calling the modified symbol. However, it does not mention potential risks, permissions, or how the proposals are presented.

  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 followed by a well-structured argument list. Every word is useful, and the format is clean and front-loaded.

  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 3-parameter tool with an output schema present, the description sufficiently covers purpose and parameters. It could slightly improve by explaining what the proposed updates look like or how they are returned, but it is not a significant gap.

  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 description coverage is 0%, but the description fully compensates by defining each parameter with specific meaning (symbol_name: modified function/class; file_path: source file; change_type: type of change) and even gives examples for change_type.

  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 'Finds and proposes updates for all files calling a modified symbol,' which is a specific verb+resource+scope. It distinguishes this tool from siblings like 'apply_sync' (which applies changes) and 'predict_impact' (which predicts impact).

  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 a clear use case: when a symbol has been modified, this tool finds and proposes updates for dependent files. However, it does not explicitly mention when not to use it or compare with alternatives like 'apply_sync' for applying the proposed updates.

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