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

With no annotations, the description carries the behavioral burden. It communicates a read-only search and the scope 'all functions/methods', but it does not clarify whether results are direct callers only or transitive, nor describe the response shape. This is adequate but leaves ambiguity.

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

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

One clear sentence with no filler. The core behavior and position constraint are front-loaded, and every word earns its place.

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

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

For a 3-parameter read-only navigation tool with full schema coverage, the description is mostly sufficient. However, without an output schema it does not explicitly state the return format or whether incoming calls are direct or recursive, leaving minor but real ambiguity.

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

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

All three parameters are already described in the schema (file path, 1-indexed line, 1-indexed column), so the description adds little beyond tying them to the target position. Baseline 3 applies because schema description coverage is 100%.

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

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

The description states a specific verb ('Find'), a specific resource ('functions/methods that call the function'), and a position constraint ('given position'). It clearly distinguishes this from call_hierarchy_outgoing by indicating incoming callers.

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

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

The operation is self-describing: an agent needing callers of a function at a position can infer when to use it. However, it does not explicitly name alternatives like find_references or call_hierarchy_outgoing or state exclusions.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It states the basic operation but does not clarify whether calls are direct or transitive, whether the result is returned as a list, or what happens when no function exists at the given position. The description adds little beyond what the tool name already implies.

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

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

A single, front-loaded sentence conveys the full purpose with no filler or repetition. Every word earns its place, and the structure is immediately scannable.

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

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

With no output schema and no annotations, the description should explain what the agent will receive and any relevant limitations. It does not mention return shape, whether the call graph is traversed recursively, or edge-case behavior, leaving a noticeable gap for an agent invoking this tool.

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

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

Schema description coverage is 100%, so the parameters are already fully documented in the input schema. The description does not add extra meaning about how file/line/col are used to locate the function, but per the baseline, this is adequate.

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

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

The description uses a specific verb ('Find') with a clear resource: all functions/methods called by the function at a given position. It implicitly differentiates from the sibling call_hierarchy_incoming by stating the outgoing direction, so an agent can distinguish this tool without opening the schema.

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

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

No guidance is given about when to prefer this tool over alternatives such as call_hierarchy_incoming, find_references, or goto_definition. There are no exclusions, prerequisites, or explicit 'use this when' statements, leaving usage context entirely to inference.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does reveal a useful behavior: diagnostics overlapping the range are passed to the server so quick fixes are included, which goes beyond a plain definition. However, it does not mention whether the operation has side effects, permission requirements, or what kind of response is returned.

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

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

The description is two compact sentences with no filler. It front-loads the core action and then adds the key diagnostic-related detail, making every sentence useful.

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

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

The schema covers parameters well and the description communicates the basic operation plus the diagnostics-passing behavior. However, with no output schema and no annotations, the agent is left without guidance on what the returned code actions look like or when this tool is the right choice among siblings.

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

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

Schema description coverage is 100%, so the schema already explains file, line, col, endLine, and endCol. The description adds only the general notion of 'position' and 'range', which does not materially improve on the schema's own parameter descriptions.

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

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

The description clearly states the tool's purpose: getting available code actions (quick fixes, refactorings) at a position. It is specific enough to separate it from navigation and lookup siblings like goto_definition and hover, though it does not explicitly differentiate itself from other action-oriented tools.

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

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

There is no guidance about when to use this tool versus alternatives, nor any mention of exclusions or fallback tools. The description implies usage through 'Get available code actions' but does not explain contexts where this is preferred over diagnostics or rename_prepare.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the freshness guarantee ('Waits for fresh results after recent edits') and the scoping behavior. It does not explicitly state that the operation is read-only, but 'Get' strongly implies it.

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

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

Two tightly written sentences with no filler, and the most important behavior is front-loaded in the first sentence. Every clause earns its place.

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

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

For a single-optional-parameter read-only tool, the description covers scope, return content, and the freshness behavior. There is no output schema, so a more detailed return structure would be a nice addition, but it is not required to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description largely repeats the schema's optional file path semantics and adds only the 'errors, warnings' context, which is already in the description.

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

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

The description uses a specific verb ('Get') and resource ('current diagnostics (errors, warnings) for a file'), and clarifies the optional all-open-files variant. It is unambiguous and distinct from the sibling navigation and editing tools.

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

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

It states the parameter-dependent behavior: a file argument targets one file, while omitting it returns diagnostics for all open files with issues. There are no diagnostic-gathering siblings, so no alternatives are needed, but it doesn't explicitly state when not to use it.

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

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

No annotations are provided, so the description must carry the behavioral burden. It mentions 'hierarchical tree' as a return format, but lacks details on what specific symbol types are included, whether it includes nested symbols, or error behavior for invalid paths. It does not disclose any side effects, but it is a read operation.

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

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

The description is a single sentence, directly stating the purpose and output format. It is front-loaded with the key action and resource, with no wasted words.

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

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

For a simple 1-parameter tool with no output schema, the description is fairly complete. It conveys the main purpose and output structure. However, it could be improved by noting specific symbol types (e.g., functions, classes) and whether the tree is collapsible, but these are minor given the tool's simplicity.

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

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

The single parameter 'file' has 100% schema description coverage, already stating 'Relative file path from project root'. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves all symbols (functions, classes, variables, etc.) defined in a file as a hierarchical tree. It uses a specific verb 'Get' and resource 'symbols in a file', distinguishing it from sibling tools like goto_definition or find_references, though it doesn't explicitly name them.

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

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

The description implies it is for file-level symbol listing, which contrasts with siblings like workspace_symbols (global search) or goto_definition (location-based). However, it doesn't explicitly state when to use it over these alternatives or provide exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the outcome ('Returns every location where the symbol is used') but does not explicitly mention that the operation is read-only, does not modify anything, or require any preconditions (like an indexed project). It also lacks detail on the output format (e.g., list of file/line/col entries). This is a baseline level of transparency, enough for a simple navigation tool 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.

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

The description is exceptionally concise: two sentences with no unnecessary words. The first sentence states the core purpose, and the second clarifies the result scope. Every word earns its place, and there is no filler or redundancy.

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

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

Given the tool's simplicity and that the schema is well-documented, the description is mostly adequate but leaves some ambiguity. It does not explicitly state whether the definition of the symbol is included among the references, which can affect interpretation. It also does not describe the return format (e.g., array of objects) or any ordering, though no output schema exists. For a find-references tool, this level of detail is minimal but not fully complete.

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

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

Schema description coverage is 100%: each parameter (file, line, col) has a clear description in the JSON schema. The tool description adds no additional information about the parameters, such as how they locate the symbol or whether the position refers to a definition or usage. Since the schema already documents them, a 3 is appropriate as the description does not need to repeat what is in the schema.

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

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

The description clearly states the operation: 'Find all references to a symbol across the project' and further specifies the scope with 'Returns every location where the symbol is used.' This is a specific verb+resource and distinguishes itself from siblings like goto_definition or goto_implementation by focusing on references at all usage sites, not just a single definition or implementation.

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

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

The description gives no explicit guidance on when to use this tool versus alternative navigation tools like goto_definition, goto_type_definition, or call_hierarchy_incoming. It mentions 'across the project' which implies project-wide search, but it does not state conditions such as 'use this when you need all usages, not just the definition' or reference any sibling tools. An agent must infer usage from the tool name and purpose.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the key side effect: writing the formatted result to disk. However, it does not specify whether the existing file is overwritten, what happens if the language server formatter fails, or any permission requirements, leaving meaningful gaps for a mutating operation.

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

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

The description is a single efficient sentence with no filler. It front-loads the core action ('Format a file') and immediately clarifies the important side effect, making it easy for an agent to scan and understand.

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

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

For a relatively simple tool with a fully documented schema, the description covers the essential invocation details and explicitly states the file-modifying behavior. The only notable omissions are usage alternatives and error/overwrite semantics, which prevent a perfect score.

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

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

Schema description coverage is 100%, so all three parameters (file, tabSize, insertSpaces) are already documented in the input schema. The description adds no additional parameter semantics, which aligns with the baseline 3 for complete schema coverage.

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

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

The description uses a specific verb ('Format'), names the exact resource ('a file'), and specifies the mechanism ('the language server's formatter'). It also states the side effect ('write the result to disk'), which clearly separates it from read-only LSP sibling tools like hover or document_symbols.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention related file-modifying siblings such as ts_organize_imports, nor does it state when formatting is appropriate or inappropriate. Usage context is only implied by the tool's name and purpose.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool navigates to declarations and notes C/C++ header relevance, but it does not explain behavior such as what happens when no declaration is found, whether it opens a file, or how it handles multiple declarations.

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

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

The description is a single concise sentence that front-loads the core action and adds a relevant context note. It is appropriately sized, though it could be slightly more informative.

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

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

For a simple navigation tool with fully documented parameters, the description is mostly adequate. However, without annotations or an output schema, it would benefit from stating what the tool returns or does when the declaration is not found, and how it differs from goto_definition.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning beyond the schema, which is acceptable given the high coverage.

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

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

The description states a specific verb ('Go to') and resource ('declaration of a symbol'), and adds a C/C++ context note about header declarations. It is clear enough, though it does not explicitly distinguish itself from the sibling goto_definition, which is a closely related tool.

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

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

The description implies usage for navigating to a symbol's declaration, and the C/C++ note hints at when it is relevant. However, it does not explicitly state when to prefer this over goto_definition or goto_type_definition, nor does it mention any exclusions.

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

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

With no annotations, the description bears the full burden of disclosing behavior. It does state that the tool returns the file and location of the definition, which is meaningful, but it does not specify the return structure, what happens when multiple definitions exist, or whether any navigation side effect occurs.

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

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

Two short sentences state the action and the return value with no filler. The description is concise and front-loaded, making it easy for an agent to process quickly.

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

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

The tool is simple, but with no output schema and no sibling differentiation, the description leaves some gaps: the exact shape of the returned location is not defined, and the boundary against related goto_* tools is implicit. It is adequate for a well-known LSP-style operation, but not complete on its own.

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

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

All three parameters are already fully described in the input schema, so the schema carries the semantic weight. The description only reinforces that the position is needed to locate the symbol, adding no extra meaning beyond what the schema provides.

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

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

The description clearly states the action ('Go to the definition of a symbol at the given position' and what is returned. It is unambiguous about the core purpose, but it does not explicitly differentiate itself from the closely related siblings goto_type_definition, goto_implementation, and goto_declaration.

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

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

No guidance is given on when to use this tool versus alternatives. The presence of many sibling navigation tools means an agent must infer the difference from the name alone, since the description never mentions exclusions or preferred contexts.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that locations are returned, but does not clarify whether the tool also navigates, how multiple locations are represented, what happens when no implementations exist, or whether it is strictly read-only.

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

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

Two short sentences communicate the core purpose with no filler. The key operation and expected result are front-loaded.

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

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

For a simple navigation tool with fully documented parameters, this is minimally viable. However, with no output schema and no annotations, the description should more richly explain the return representation and how this relates to sibling navigation tools.

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

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

Schema coverage is 100%, with clear descriptions for file, line, and col, so the baseline is 3. The description itself adds no parameter-level meaning beyond identifying the target context.

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

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

States a specific operation and target: 'Go to implementations of an interface or abstract method' and clarifies the result as 'concrete implementation locations.' This meaningfully distinguishes it from navigation siblings like goto_definition and goto_type_definition.

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

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

The description clearly implies when to use the tool: when the agent needs implementations of an interface or abstract method. It does not explicitly compare against alternatives or state exclusions, so it stops short of a full 5.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns the location of a type definition and implies a read-only lookup, but it does not mention navigation behavior, error cases, or whether multiple results are possible. Basic transparency is present, but richer behavioral context is missing.

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

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

The description is two sentences with no filler. The core action and result are front-loaded, and every word contributes to understanding the tool's purpose.

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

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

For a simple three-parameter navigation tool, the description is mostly complete: it states what the tool does and what it returns. It lacks an exact response format or edge-case behavior, but the low complexity and full schema coverage make this a minor gap.

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

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

Schema description coverage is 100%, so the schema fully documents file, line, and col. The description adds only the contextual notion of 'the symbol at the given position,' which aligns with the parameters but does not deepen their meaning. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Go to') and a precise resource ('type definition of a symbol'), and clarifies that it returns where the type is defined. This clearly distinguishes it from sibling tools like goto_definition, goto_implementation, and goto_declaration.

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

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

The description implies usage when one wants the type definition at a given position, but it does not explicitly state when to prefer this over goto_definition or goto_declaration, nor does it provide exclusions. Usage is inferable but not explicitly guided.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. It accurately indicates a non-destructive read operation ('Get') and the kind of data returned. It does not mention error cases or reliance on language-server state, but these are minor for a simple hover query.

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

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

The description is a single, front-loaded sentence with no filler. Every part contributes: the action, the returned information, and the positional scope.

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

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

For a straightforward positional read operation, the description plus fully documented schema gives an agent the essentials needed to invoke it. The main missing piece is usage differentiation from siblings, but no output schema or complex return contract is required here.

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

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

Schema description coverage is 100%, with file, line, and col each briefly explained and 1-indexing noted for the numeric parameters. The description adds no extra parameter meaning, so the baseline of 3 applies.

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

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

The description clearly states the verb ('Get'), the resource ('hover information'), and the location ('a symbol at the given position'). It also specifies the content as 'type signature, documentation'. It does not explicitly contrast with sibling tools like signature_help or goto_definition, so it loses the last point.

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

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

No guidance is given about when to prefer hover over signature_help, goto_definition, or document_symbols. There are no exclusions, prerequisites, or alternative routing hints, so an agent must infer usage from the tool name and general LSP knowledge.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly reveals that calling open_file triggers diagnostics and makes the file available for subsequent no-arg diagnostics calls, which is meaningful side-effect information beyond the basic 'open' verb. It does not mention potential errors or idempotency, but the disclosed side effects are relevant and non-obvious.

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

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

Two sentences with no filler. The core action is front-loaded, and the behavioral effect is given in a compact second sentence. Every word earns its place.

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

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

For a one-parameter tool with no output schema and no annotations, the description covers the essential context: what it does, what side effects it has, and how it relates to future diagnostics calls. It doesn't mention error handling or return values, but those are arguably less critical for this simple LSP operation and can be inferred. Minor gap: no explicit statement that the file must exist or that the path is project-relative (though the schema covers that).

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

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

Schema description coverage is 100%: the only parameter, 'file', is already documented as 'Relative file path from project root'. The description adds no further detail about the parameter (e.g., format constraints, whether the file must exist). Baseline of 3 is appropriate since the schema already provides complete parameter semantics.

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

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

The description states a specific verb and resource ('Open a file in the LSP server') and immediately clarifies its role: it triggers diagnostics and enables subsequent no-arg diagnostics calls. This clearly separates it from the many navigation and inspection siblings like goto_definition or hover.

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

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

The description implies when to use the tool: before running no-arg diagnostics, and it explains the consequence of doing so. It does not explicitly name alternatives or state when not to use it, but the context given is clear enough for an agent to infer the appropriate call sequence.

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

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

With no annotations provided, the description must carry the burden of behavioral disclosure. It does disclose key behavior: the tool either returns a workspace edit or applies it to disk depending on the 'apply' flag. It also states the scope ('all affected files'). However, it does not mention potential side effects like file modification when 'apply' is true, nor does it address error handling or conflicts. Still, the dual return/apply behavior is clearly stated, which is a significant disclosure.

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

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

The description is a single, front-loaded sentence that immediately states the primary action and scope, followed by a clear explanation of the apply behavior. There is no redundant information, and every word contributes to clarity. It is highly concise and well-structured.

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

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

Given the tool's complexity (renaming across files) and the absence of an output schema, the description adequately explains the return value behavior (workspace edit vs. disk application). It does not mention prerequisites like ensuring the symbol exists or the file is open, nor does it address error scenarios, but these are not critical for invoking the tool. The description is sufficiently complete for an agent to call it correctly.

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

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

Schema coverage is 100%, so all five parameters (file, line, col, newName, apply) are already documented in the input schema. The description adds no additional parameter-specific meaning; it only restates the apply behavior that is already in the schema. Since the schema covers all parameters, a baseline score of 3 is appropriate.

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

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

The description clearly states the action (rename), the resource (a symbol across all affected files), and the scope (multiple files). It differentiates from sibling tools like rename_prepare (which likely only prepares the rename) and ts_rename_file (which renames a file) by focusing on symbol renaming. The phrase 'across all affected files' is specific and unambiguous.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives like rename_prepare or ts_rename_file. It does not mention conditions under which the tool should be preferred, nor does it exclude scenarios. The 'apply' flag is described, but the tool itself is positioned as a general symbol rename, leaving the agent to infer when to use it.

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

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

No annotations are provided, so the description carries the burden. It transparently indicates this is a non-mutating check ('Check if... can be renamed') and that it retrieves the current name. However, it does not disclose what happens when renaming is not possible, the exact return format, or whether any side effects occur.

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

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

The description is a single, focused sentence with no filler. The core action ('Check if') is front-loaded, and every word contributes to understanding the tool's purpose.

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

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

The description covers the input parameters and the main purpose, but with no output schema and no annotations, it leaves out the return shape or result semantics (e.g., whether it returns a boolean, a name, or an error when renaming is impossible). It is adequate for a simple check tool but has clear gaps.

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

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

The input schema covers 100% of the parameters, so the baseline is 3. The description adds minimal parameter meaning beyond 'position' and 'current name', but the schema already documents file, line, and column with clear 1-indexed descriptions.

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

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

The description uses a specific verb ('Check if') and resource ('symbol at the given position'), and clearly states the two outcomes: whether the symbol can be renamed and its current name. This distinguishes it from the sibling tool 'rename', which actually performs the rename.

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

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

Usage is implied by the description and name: it is a pre-rename check. However, there is no explicit guidance on when to use it versus 'rename' or 'ts_rename_file', and no alternatives or exclusions are mentioned.

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

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

No annotations are provided, so the description carries the full disclosure burden. 'Get' communicates a read-only lookup and 'at the given position' scopes the operation, but the description does not mention what happens at non-function-call positions, whether multiple signatures are returned, or what an empty/unavailable result looks like.

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

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

The description is a single, front-loaded sentence with no filler or redundant phrasing. Every word contributes to the basic purpose and target of the tool.

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

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

For a simple tool with fully described parameters, the description is minimally adequate: it states the operation and where to apply it. However, with no output schema and no usage guidance, an agent is left to infer return shape, exact positioning semantics, and when this tool should be preferred over siblings.

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

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

The input schema fully documents all three parameters with clear descriptions (file path, 1-indexed line, 1-indexed column), so the schema already handles parameter meaning. The description adds only the notion of a function-call position, which is context rather than additional parameter-level detail.

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

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

The description uses a specific verb ('Get') and specific resource ('parameter information for a function call at the given position'), so the core purpose is clear. It does not explicitly distinguish itself from related sibling tools like hover or document_symbols, but the function-call parameter focus is a meaningful differentiation.

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

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

The description gives no guidance about when to use this tool versus alternatives such as hover or find_references. It does not state that this is useful for inspecting call-site arguments or that it should not be used for other inspection needs.

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

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

No annotations are provided, so the description carries the full transparency burden. It discloses the main behavioral trait — resolving to the implementation rather than the .d.ts declaration — which is useful. But it says nothing about failure behavior, what happens when no source definition exists, or how the navigation result is returned, so transparency is only partial.

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

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

The description is a single sentence with no filler. The verb is front-loaded, the target is clear, and the important qualifier about .d.ts declarations comes immediately, making it easy to scan.

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

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

For a simple navigation tool with fully documented parameters, this is mostly adequate. However, with no output schema and no annotations, an agent might still be uncertain about return behavior or edge cases such as positions that aren't on a symbol. The absence of explicit sibling differentiation also leaves some contextual ambiguity.

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

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

The input schema already documents all three parameters (file, line, col) with 100% coverage, including that line and column are 1-indexed. The description adds no parameter-level detail beyond the tool's overall purpose, so the baseline of 3 applies.

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

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

The description uses a concrete verb and target — 'Go to the source definition' — and adds a key clarifying qualifier: 'the implementation, not the .d.ts declaration.' This clearly differentiates it from goto_declaration, but it does not fully distinguish it from sibling tools like goto_implementation, which could plausibly resolve to the same target.

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

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

The parenthetical 'the implementation, not the .d.ts declaration' gives the agent a selection criterion: use this when the desired result is the actual implementation rather than a declaration file. However, it never names alternatives or states explicit when-to-use vs. when-not-to-use guidance, leaving the routing among goto_definition, goto_implementation, and goto_declaration mostly implied.

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

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

Explicitly discloses that changes are applied to disk, a critical side effect, and states that unused imports are removed. With no annotations, this is meaningful behavioral disclosure, though it omits details like reversibility or safety precautions.

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

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

Two sentences with no filler, front-loading the core purpose and then the key side effect. Every word earns its place.

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

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

For a simple two-parameter mutation tool with a complete schema, the description covers the essential operation and its disk-writing behavior. It would benefit from routing guidance versus siblings, but nothing critical is missing.

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

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

The schema already describes both parameters at 100% coverage, including the meaning of skipDestructiveCodeActions. The description adds no additional parameter-level detail, so the baseline of 3 applies.

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

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

States a specific verb and resource: sorts and removes unused imports in a TypeScript/JavaScript file. The operation is clearly distinct from siblings like format or code_actions, though it does not explicitly name an alternative.

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

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

The use-case is implied by the purpose, but there is no explicit guidance on when to choose this tool over format or generic code_actions. No exclusions or alternative conditions are provided.

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

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

The description discloses that the tool 'Applies the changes to disk', which is a behavioral trait indicating it performs a write operation. However, no annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't mention whether the operation is reversible, whether it requires a prior rename_prepare call, or what happens if the oldPath no longer exists. The statement 'Applies the changes to disk' is useful but minimal; it doesn't disclose potential side effects like modifying many files or requiring a save.

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

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

The description is three sentences, each earning its place. The first sentence states the core purpose, the second gives the required precondition, and the third discloses the disk-write behavior. It is front-loaded with the primary action and contains no filler or redundant information.

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

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

For a tool with only two parameters and no output schema, the description covers the essential context: what it does, when to call it, and that it writes to disk. It doesn't explain the return value, but since there is no output schema, that's less critical. It also doesn't mention whether the tool requires a prior rename_prepare call, which could be relevant given the sibling tool rename_prepare exists. However, the description is largely complete for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so both parameters (oldPath and newPath) are already described in the schema as 'Previous relative file path' and 'New relative file path'. The description adds context by explaining that oldPath is the file's path before the move and newPath is after, but it doesn't add significant detail beyond the schema. The baseline of 3 is appropriate since the schema already documents the parameters adequately.

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

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

The description clearly states the tool's purpose: updating all imports that reference a file after it has been moved or renamed on disk. It specifies the verb 'update', the resource 'imports that reference a file', and the context 'after it has been moved or renamed on disk'. This distinguishes it from sibling tools like rename_prepare and rename, which handle the rename operation itself, and from ts_organize_imports, which organizes imports rather than updating paths.

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

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

The description provides clear usage context: 'Move the file first, then call this.' This tells the agent the required sequence of operations. It doesn't explicitly state when not to use this tool or name alternatives, but the sibling list includes rename_prepare and rename, and the description's focus on post-move import updates makes the usage context clear. The instruction 'Move the file first' is a strong usage guideline, though it doesn't explicitly exclude cases where the file hasn't been moved.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action (get hierarchy) without mentioning potential side effects, error behavior, or what happens if the position does not correspond to a type. There is no explicit indication that this is a read-only operation, nor any detail about the return structure.

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

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

The description is a single, concise sentence that front-loads the verb and resource. There is no extraneous wording, and every word contributes to conveying the tool's purpose. It is well-structured and efficient.

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

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

For a tool with no output schema and no annotations, the description is too terse. It does not explain what the returned hierarchy consists of (e.g., a list of type names, supertypes vs. subtypes separately) nor how to interpret the result. It also omits edge cases such as what happens if the position does not point to a type, leaving the agent with insufficient information to correctly use the tool's output.

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

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

The input schema already provides full descriptions for all three parameters (file, line, col) with 100% coverage. The tool description adds no additional semantic information about these parameters, so it relies entirely on the schema. Given the high schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly specifies the verb 'Get' and the resource 'type hierarchy (supertypes and subtypes)', and identifies the input as 'the type at the given position'. It is distinct from sibling tools like call_hierarchy_incoming/outgoing because it focuses on type relationships rather than call relationships. No ambiguity remains about the core purpose.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or reference sibling tools such as goto_type_definition or call hierarchy tools. An agent receives no context about when this tool is the appropriate choice.

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

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

No annotations are provided, so the description carries the full burden. It discloses fuzzy matching, a useful behavioral trait. However, it does not mention result format, behavior on no matches, or any edge cases. For a read-only search tool this is acceptable but not rich, so a mid-range score is appropriate.

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

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

Two sentences with no filler. The primary action and scope are front-loaded, and the fuzzy-matching detail is added in a second compact sentence. Every word earns its place.

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

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

For a simple single-parameter search tool, the description covers the key aspects: what is searched, the scope, and matching behavior. The lack of output schema means return details are not specified, but this is not critical for a search operation. Sibling context is adequately handled by the scope phrase.

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

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

Schema coverage is 100% and the query parameter is simply described as 'Symbol name to search for'. The description adds meaning by noting that fuzzy matching is supported, which clarifies how the query will be interpreted beyond the literal schema. This goes beyond the baseline.

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

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

States a specific verb ('Search'), a clear resource ('symbols across the entire project'), and a key differentiator ('by name'). The phrase 'across the entire project' distinguishes it from sibling document_symbols, which likely operates on the current file. This is precise and unambiguous.

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

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

The description implies when to use this tool: when searching project-wide rather than in a single file. It does not explicitly name alternatives or exclusions, but 'across the entire project' provides clear context that differentiates it from file-scoped siblings. A slight deduction for not explicitly mentioning when not to use it.

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