javalens-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.5.0
Disambiguation5/5
Each tool targets a highly specific analysis or refactoring task with clear, distinct purposes. Even similar tools like find_implementations and get_type_hierarchy are differentiated by their detailed descriptions.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (e.g., analyze_control_flow, find_references), making them predictable and easy to parse.
Tool Count2/5
With 63 tools, the server far exceeds the typical range for coherence. While each tool serves a specific purpose, the sheer number overwhelms the interface and increases cognitive load.
Completeness5/5
The tool set covers an extensive range of Java code analysis (complexity, dependencies, bug detection) and refactoring operations (extract, inline, rename), with no obvious missing capabilities for its stated purpose.
Average 4.2/5 across 63 of 63 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 10 of 10 community issues answered or closed in the last 6 months
- 214 commits in the last 12 weeks
- Last stable release on June 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 not explicitly state that the tool is read-only or have side effects, nor does it discuss performance or permissions. The word 'Analyze' implies inspection, but not explicitly.
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 well-structured with a usage line, output summary, and bulleted list of reports. It is concise and front-loaded, though the usage line could be considered redundant.
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 details the output fields (branch count, loop types, etc.) but lacks a formal output schema or return format. It covers input usage and basic output, but misses behavioral transparency and error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds a usage example and notes zero-based indexing, but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes the control flow structure of a method, specifying what it reports (branching, loops, returns, etc.). This distinguishes it from siblings like analyze_data_flow (data flow analysis) and analyze_method (broader analysis).
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?
Provides a usage example and states the prerequisite 'Requires load_project to be called first.' However, it does not explicitly guide when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full transparency burden. It discloses zero-based coordinates and the need for a loaded project, but does not specify error behavior (e.g., if the position is not on a type) or side effects. Output details are partially mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and well-structured with headings (USAGE, OUTPUT, IMPORTANT). It gets to the point quickly, though the OUTPUT section could be integrated into the main sentence for further brevity.
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 lack of output schema, the description usefully lists output fields (kind, modifiers, superclass, interfaces). It covers usage context and prerequisites. However, missing details on error handling and edge cases prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with descriptions for filePath, line, column including 'Zero-based' in the line and column descriptions. The tool description reiterates zero-based coordinates but adds no significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get type information at a specific position.' It positions itself as a position-aware type query tool, distinct from tools like get_type_hierarchy or get_type_members, but does not explicitly differentiate from similar position-based tools like get_field_at_position or get_method_at_position.
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 a usage hint ('Position on a type reference or declaration') and a prerequisite ('Requires load_project to be called first'). However, it lacks guidance on when not to use this tool versus alternatives. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the types of issues detected and the prerequisite, but does not mention side effects, permissions, or performance implications. It implies a read-only operation but doesn't state it explicitly.
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 well-organized with usage examples, output hint, and a bulleted list. It is concise (no filler) and front-loads the purpose. Minor redundancy (repeating 'USAGE') is acceptable for clarity.
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 static analysis tool with no output schema, the description gives a good overview of capabilities and a key prerequisite. It could detail the output format more, but the list of detected issues provides sufficient context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for both parameters (filePath, severity). The description adds the usage example for filePath and clarifies it's optional, but does not elaborate on severity or any format constraints. The schema already does most of the work.
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 finds bugs and code quality issues, listing specific detection types (null pointer risks, resource leaks, etc.). This distinguishes it from sibling tools like 'find_naming_violations' or 'analyze_control_flow' which target different aspects.
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?
It provides usage examples and a prerequisite ('Requires load_project to be called first'). However, it does not explicitly guide when to use this tool over alternatives (e.g., 'analyze_file') or when not to use it. The guidance is minimal but functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions the algorithm (Tarjan's SCC) and output (cycle paths and affected packages), which offers some behavioral insight. However, it does not discuss performance, side effects, or behavior when no cycles exist.
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 relatively concise, but the two usage lines are somewhat redundant. It is well-structured with clear sections for usage and output, though minor trimming could improve efficiency.
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 covers purpose, usage, and a prerequisite. However, with no output schema, the return format is only vaguely described as 'List of circular dependency cycles'. More detail on the output structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions. The description adds value by showing usage examples for 'packageFilter', but does not mention 'maxCycleLength'. Overall, it neither significantly enhances nor harms understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Detect cycles in packages' and provides usage examples. The tool name is self-explanatory, and the description distinguishes it from generic analysis tools like analyze_control_flow.
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 includes the prerequisite 'Requires load_project to be called first' and shows usage patterns. It does not explicitly contrast with siblings, but the tool's specificity makes its use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 use of zero-based coordinates and the load_project prerequisite, but does not detail output format, error handling, or constraints like the default maxResults limit. The output is described as 'all locations' without specifics, which may be slightly misleading given the maxResults parameter.
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 well-structured with sections for usage, output, and important notes. It is concise but includes some generic 'Useful for' bullet points that may not add significant value for an AI agent. Overall, it earns its space with clear organization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what 'locations' contain. It fails to specify the format of output (e.g., file paths, line numbers). It does mention prerequisites and zero-based coordinates, which are helpful, but missing details on error cases and default limits reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds limited value. It reinforces zero-based coordinates already described in the schema but does not elaborate on filePath or maxResults beyond what the schema provides. The description's mention of 'maxResults' is absent, leaving the schema to bear full parameter meaning.
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 finds all method reference expressions (Foo::bar lambda syntax), distinguishing it from the sibling 'find_references' which likely finds all references. It specifies JDT-UNIQUE and not available in LSP, providing precise purpose.
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 usage instruction: 'Position on a method, or provide method details' and emphasizes zero-based coordinates. It also specifies a prerequisite: 'Requires load_project to be called first.' However, it does not explicitly state when not to use this tool or compare with alternatives like 'find_references'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions the JDT-specific nature and prerequisite but does not explicitly state the tool is read-only or explain any side effects or performance implications. The description provides some context but not full transparency.
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 well-structured with sections (JDT-UNIQUE, USAGE, OUTPUT, Useful for, Requires) and front-loaded with the main purpose. It is reasonably concise, though the 'Useful for' list adds minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description only says 'All locations where the type is used as a generic argument', lacking detail on output format (e.g., file paths, line numbers). For a search tool, more specifics about the result structure would be beneficial, but it provides the essential functionality context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (typeName, maxResults). The description reiterates the need for a fully qualified type name but adds no additional semantics beyond the schema. The baseline of 3 is appropriate as description does not enhance parameter understanding.
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 finds all usages of a type as a generic type argument, with examples like List<Foo>. It distinguishes itself as JDT-UNIQUE, unavailable in LSP, making the purpose unambiguous.
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 specifies the prerequisite 'Requires load_project to be called first' and suggests useful scenarios like understanding generic patterns. However, it does not explicitly compare to sibling tools like find_references or find_type_instantiations, missing clear when-to-use vs alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses zero-based coordinates and prerequisite load_project. However, it does not mention side effects, error behavior, or output format beyond 'list of methods'. Adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with 6 lines, front-loaded with purpose. Each sentence adds value (usage, output, coordinate note, prerequisite). Minimal fluff, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description minimally states 'OUTPUT: List of methods that call this method' but lacks details on result structure (e.g., what fields each method entry has). Also misses any ordering or deduplication info. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description does not add additional meaning beyond the schema; it only reiterates zero-based coordinates already in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Find all callers of a method (incoming calls)' with a specific verb and resource. It distinguishes from sibling tool get_call_hierarchy_outgoing by using 'incoming' in both name and description.
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?
Provides explicit usage context: 'USAGE: Position cursor on a method name' and prerequisite 'Requires load_project to be called first.' Does not explicitly mention when not to use or alternatives, but the naming and description differentiate from the outgoing sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the action (remove unused, sort) and output (organized block and changes), but does not fully disclose whether the file is modified directly or if permissions are needed. No annotations are provided to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. It includes a usage example, output description, and prerequisite without redundancy.
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?
Sufficient for a simple tool with one parameter and clear output, but lacks details on error handling or edge cases. No output schema is provided, but the description explains the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'filePath' has a schema description of 'Path to source file', and the description adds no additional semantics. With 100% schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool organizes imports in a Java file by removing unused imports and sorting alphabetically. It distinguishes from sibling tools like 'suggest_imports' by focusing on organization rather than suggestion.
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?
Provides a usage example and explicitly requires 'load_project' to be called first. It does not mention when not to use it or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that coordinates are zero-based and that the tool combines multiple analyses. However, it does not mention whether the tool is read-only, potential performance impact, authorization requirements, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with USAGE, OUTPUT, and a bullet-style list of combined information. It is reasonably concise, though the list of outputs could be slightly more compact. Overall, it is front-loaded with the core 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?
Given the absence of an output schema, the description effectively outlines the expected return values. It includes prerequisites (load_project) and a usage example. While it could mention error conditions or limits, it provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description illustrates usage with filePath, line, and column in an example, and indirectly references maxCallers/maxCallees via the default values in the schema. It adds minimal meaning beyond the schema, achieving the baseline of 3.
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 performs 'comprehensive method analysis', listing specific outputs (method info, parameters, exceptions, callers, callees, override info). It distinguishes itself from sibling tools like get_method_at_position and call hierarchy tools by stating it combines them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool instead of multiple calls to get_method_at_position and call hierarchy tools. It also provides a usage example and notes the prerequisite load_project. However, it does not specify when not to use it or list alternatives beyond the combination hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It discloses zero-based coordinates and that the output includes interface file content and class modification. However, it does not explicitly state that the tool modifies files (creates new interface and edits class), which is important side-effect information.
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 relatively concise and structured with clear sections (USAGE, OUTPUT, IMPORTANT). It is not verbose, though it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, high schema coverage, and no output schema, the description provides necessary context: prerequisite (load_project), coordinate system, usage pattern, and output type. It is fairly complete for an agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning beyond the schema, such as emphasizing zero-based coordinates. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: extract an interface from a class containing selected public methods. It uses specific verbs and resources, and it stands out among sibling tools which are mostly analysis or different refactoring operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage instructions: position on class, provide interface name, optionally specify methods. It also notes the prerequisite of calling load_project. However, it does not explicitly exclude use cases or compare to alternatives like extract_method.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It mentions output is a list of classes with metrics but doesn't disclose if it's read-only or any side effects. Basic information is present but additional behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured, with the main purpose upfront. The usage example and default thresholds are helpful without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes output format and prerequisites. Could mention error handling, but overall complete for a straightforward query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description reiterates defaults and meanings, adding little beyond the schema. Baseline 3 applies as description does not significantly enhance parameter understanding.
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 finds classes exceeding size thresholds, with specific metrics (methods, fields, lines). Among siblings like find_unused_code, this tool stands out for its focus on size metrics.
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?
Provides a usage example with default thresholds and explicitly states 'Requires load_project to be called first.' However, it does not specify when to use this tool over other analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies read-only operation via 'Find' and describes output format. Does not explicitly state absence of side effects or error conditions.
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?
Very concise, front-loads purpose, uses bullet-like structure. Every line adds value, no wasted words.
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?
Covers main purpose, prerequisites, supported frameworks, and output. Lacks details on return format, error handling, or behavior when pattern matches nothing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; parameters are documented in schema. Tool description adds no extra parameter semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it finds test classes and methods, lists supported frameworks (JUnit 4, 5, TestNG). Distinct from sibling tools which focus on different analysis tasks.
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?
Provides a usage example and explicitly states prerequisite (require load_project). No comparison to alternatives, but context is clear enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes output as locations with 'new' calls, but does not explicitly state read-only nature or other behavioral traits. It mentions load_project prerequisite, but could disclose more about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with clear sections: purpose, JDT-UNIQUE, usage, output, useful for, prerequisite. Slight redundancy in stating output after purpose, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with 2 parameters, no output schema, and no annotations, the description is sufficient. Covers purpose, usage, output, and prerequisite. Could mention error handling, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. Description restates 'fully qualified type name' and hints at maxResults default, adding little beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds instantiations of a type (new Foo() calls), with a specific verb and resource. It distinguishes from siblings by noting JDT-UNIQUE fine-grained search not in LSP.
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?
Provides clear usage: provide fully qualified type name, and prerequisite (load_project). Mentions use cases. Does not explicitly state when not to use or list alternatives, but the JDT-UNIQUE note implies uniqueness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It describes output and a prerequisite but does not disclose side effects, errors, or performance implications. Adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear structure: purpose, usage, output, and prerequisite. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return content (source folders, libraries, containers) and a prerequisite. Could specify return format more precisely, but it is complete enough for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds value by mapping parameters to output categories (libraries, source, containers), enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves classpath information and lists output categories (source folders, libraries, containers). It is specific but does not explicitly differentiate from sibling tools like get_project_structure or get_dependency_graph.
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?
Provides a usage statement and a clear prerequisite ('Requires load_project to be called first'). However, no guidance is given on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It describes scanning behavior and return types, and that it doesn't error on non-Spring projects. However, it does not explicitly state it is a read-only, non-destructive operation, though that is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a purpose statement, usage format, output hint, and a bullet list of scanned items. It is front-loaded and clear, though the bullet list adds some length.
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?
With only one optional parameter and no output schema, the description adequately covers the tool's behavior: it lists scanned annotations, handles non-Spring projects gracefully, and states a prerequisite. The return categories are mentioned, though format is not detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter maxResults. The description does not add additional context beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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 as finding all dependency injection registrations, listing specific annotations and injection points. It distinguishes itself from sibling tools, none of which specifically target DI registrations.
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?
Explicitly notes the prerequisite of calling load_project first, and explains behavior on non-Spring projects (returns empty). While no explicit alternatives are mentioned, the context of sibling tools makes this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions zero-based coordinates and prerequisite. Lacks detail on return format or edge cases (e.g., what if position is not inside any element). Could be more transparent.
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?
Very concise: 5 lines with clear sections (USAGE, OUTPUT, IMPORTANT, requirement). Front-loaded with main purpose, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with 3 params and no output schema. Description covers purpose, usage, output type, coordinate system, and prerequisite. Lacks error handling details but still fairly complete for an information retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already documents zero-based coordinates. Description merely repeats this information, adding no new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get the enclosing element at a position' and specifies output as enclosing method, type, and package info. It distinguishes from siblings like get_field_at_position and get_method_at_position by being more generic.
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?
Explicit usage instruction ('Position anywhere in code') and prerequisite ('Requires load_project to be called first'). No comparison with alternatives but sufficient for basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries burden. It mentions zero-based coordinates and prerequisite, adding context. Does not disclose behavior for undocumented symbols or other traits.
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?
Very concise, front-loaded purpose, sections clearly label usage and output. Every sentence is necessary and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains output format, prerequisite, and zero-based coordinate system. No output schema, but output description suffices. Good for a moderate-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions. Description adds critical context that line and column are zero-based, enhancing parameter 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 gets parsed Javadoc for a symbol, which is a specific verb+resource. However, it does not differentiate from siblings like get_hover_info or get_symbol_info.
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?
Provides clear usage: position on documented symbol and prerequisite (load_project). Lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool returns text edits and that the caller must apply them, implying no direct modification. It also mentions zero-based coordinates. However, it lacks details on error handling, permissions, or side effects, which limits transparency.
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 with a clear structure: purpose, return value, usage, important notes, and prerequisite. Every sentence is necessary and informative, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description covers the essential aspects: what it does, how to use it, and what it returns. It could mention error conditions or coordinate validation, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no new parameter meaning beyond what the schema already provides (e.g., zero-based coordinates, constant name convention). It does not compensate for any missing schema details.
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's purpose: 'Extract an expression into a static final constant at class level.' This distinguishes it from sibling tools like extract_variable (local variable) or extract_method (method), making its purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'USAGE: Select expression by providing start and end positions' and notes the prerequisite 'Requires load_project to be called first.' While it doesn't discuss when not to use the tool, it offers sufficient context for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly explains the metrics, risk levels, and the prerequisite of load_project. It implies a read-only behavior by simply getting metrics, and the output is described, providing adequate transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, usage, output, metrics, risk levels, and prerequisite. It is concise, front-loaded, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 3 parameters, the description covers the core functionality, input example, metric details, and a prerequisite. It could be improved by explicitly stating the output format (e.g., JSON structure), but the provided details are sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add new meaning to parameters beyond the schema; it only shows an example usage with filePath. The metrics explanation is helpful but does not clarify granularity or includeDetails.
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 identifies the tool as retrieving cyclomatic complexity, cognitive complexity, and LOC, with a risk assessment. This distinguishes it from sibling analysis tools like analyze_control_flow or analyze_file, which focus on broader or different metrics.
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 includes a usage example and importantly notes that load_project must be called first, which is a key prerequisite. However, it does not explicitly guide when to use this tool over alternatives or when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains return structure (hierarchical list with locations, kinds, modifiers) and dependency on load_project, but omits error scenarios, performance notes, or read-only nature.
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?
Three concise sentences plus a usage block. Every sentence contributes purpose, usage, or output details. No wasted text, well 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 3 parameters with full schema, no output schema, and no annotations, the description covers primary functionality and prerequisites well. Minor gaps: could mention maxResults default and error handling for missing file or unloaded project.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. Description adds little beyond schema: it restates filePath purpose but does not elaborate on includePrivate or maxResults defaults/behavior.
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?
Description clearly states the tool retrieves all symbols in a source file, with specific resource and verb. Distinguishes from siblings like get_symbol_info and search_symbols by focusing on the entire file's symbols.
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?
Explicitly states the prerequisite to call load_project first, which is valuable. Provides usage pattern 'Provide a file path' but lacks explicit exclusions or comparisons to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It explains that the tool returns lists of members with details and mentions options. However, it does not discuss side effects, performance implications, or whether the tool modifies state. The description is adequate but lacks depth.
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 well-structured with clear sections for USAGE, OUTPUT, and Options. Every sentence earns its place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality, includes a prerequisite, and summarizes output. However, it lacks details about the output format (what 'details' are included) and could mention whether the response is paginated or has size limits. Overall, it is fairly complete for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the baseline is 3. The description adds value by explaining the effects of 'includeInherited' and 'memberKind' options and reiterating the prerequisite, providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves members (methods, fields, nested types) of a specific type. It uses a specific verb ('Get') and resource ('members of a specific type'), and the purpose is distinguishable from sibling tools like 'analyze_type'.
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 a prerequisite ('Requires load_project to be called first') and describes options. However, it does not specify when to use this tool versus alternatives like 'analyze_type' or 'get_type_hierarchy', nor does it give guidance on 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses zero-based coordinates and that it returns text edits to be applied by caller. With no annotations, this covers key behaviors adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with three short sentences, front-loaded with purpose. No superfluous content.
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?
Explains return type (text edits) and coordinate system. Lacks error scenarios but sufficient for typical refactoring tool. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description essentially restates schema parameters without adding new meaning beyond usage context.
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?
Description clearly states 'Rename a symbol' with explicit resource types. Differentiates from siblings as no other rename tool exists.
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?
Provides basic usage instructions and prerequisite (load_project), but no guidance on when to use vs alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains output details (variables, read/write/declaration info) and provides extensive behavior for followCalls mode, including null and taint facts, may-analysis, and tracking limitations.
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 well-structured with sections, starts clearly, and is not overly verbose given the complexity of the tool. It could be slightly more concise but effectively covers key points.
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?
No output schema, but description adequately explains output format. It mentions prerequisite (load_project) and covers all parameters. For the complexity of the tool, it is sufficiently 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 coverage is 100%, baseline is 3. The description adds value by showing usage format, clarifying zero-based indexing, and explaining followCalls and maxCallDepth in detail beyond schema descriptions.
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 'Analyze data flow within a method' and provides a usage example. It distinguishes itself from sibling tools like analyze_control_flow or analyze_change_impact by focusing on data flow and variable tracking.
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 mentions it is 'useful for understanding side effects before extracting methods' and that it requires load_project first. However, it does not explicitly state when not to use it or compare to alternatives, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly states the output format (changed flag, label, full rewritten source) and clarifies that the file is NOT written. This goes beyond the input schema. No annotations are provided, but the description is transparent about the non-destructive nature and output.
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 highly concise and well-structured: a clear purpose statement, a usage example, output description, and an organized list of supported cleanups. Every sentence adds value without redundancy.
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?
Covers the tool's purpose, parameters, valid values, output, and prerequisite. Missing output schema is compensated by describing the output. Could mention error handling or effect on project state, but overall sufficient for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions. The description adds significant value by enumerating all valid cleanupId values with explanations for each, enriching the parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies JDT code clean-ups to a file and returns rewritten source. It lists all supported cleanup IDs, distinguishing it from siblings like apply_quick_fix and convert_anonymous_to_lambda. However, it does not explicitly compare to siblings.
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?
Provides a usage example with parameters and a prerequisite ('Requires load_project to be called first'). Does not state when not to use or specify alternatives, but the example and list offer implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It states output is locations of casts, but does not mention format, performance, or error handling. Adequate for basic understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured with labeled sections (JDT-UNIQUE, USAGE, OUTPUT, etc.). Front-loaded with purpose. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, no output schema, and many sibling tools, the description sufficiently covers what the tool does and returns. Could mention output format, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described). Description adds value by specifying typeName must be fully qualified and maxResults default is 100, beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it finds all casts to a given type using JDT-specific fine-grained search. Differentiates from sibling tools (e.g., find_references) by being specific to casting expressions.
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?
Provides clear usage: provide fully qualified type name, requires load_project first. Lists explicit use cases (unsafe downcasts, refactoring). Does not discuss when not to use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is responsible for behavioral disclosure. It explains that the tool searches for catch blocks and returns them, but does not explicitly state that it is a read-only operation or disclose any side effects. The behavioral traits are implied but not fully transparent.
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 well-structured: it starts with the core purpose, then uniqueness, usage, output, use cases, and prerequisite. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately specifies the output ('All catch blocks that handle this exception type'). It covers input, usage context, prerequisites, and use cases, making it complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description adds limited value beyond reinforcing the schema ('Provide fully qualified exception type name'). No additional meaning or nuances are provided, so 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.
Purpose5/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: 'Find all catch blocks for an exception type'. It uses a specific verb and resource, and distinguishes itself from sibling tools like find_references or find_throws_declarations by focusing exclusively on catch blocks.
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 indicates when to use the tool (e.g., understanding exception handling, finding handlers) and mentions prerequisite ('Requires load_project to be called first'). It also notes uniqueness ('JDT-UNIQUE'). It could be improved by explicitly stating when not to use it, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 important behavioral traits: zero-based coordinates and the prerequisite to call load_project. However, it does not mention potential side effects or whether results are limited to maxResults, which is inferred from the parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with sections (USAGE, OUTPUT, IMPORTANT) and avoids repetition. It is front-loaded with the purpose and key details, though the formatting could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a symbol reference tool and no output schema, the description adequately covers prerequisites, coordinate system, and basic usage. It is reasonably complete for an agent to invoke correctly.
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 schema covers 100% of parameters, but the description adds value by emphasizing the 'ZERO-BASED coordinates' for line and column, and implying a default of 100 for maxResults. This clarifies the parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find all references to a symbol across the project' with a specific verb (find) and resource (references). Among sibling tools like find_implementations and find_method_references, this tool is distinguished as the generic reference finder.
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 includes a prerequisite ('Requires load_project to be called first') and a usage hint ('Position on symbol, find all usages'), but does not explicitly differentiate when to use this tool versus siblings like find_method_references or find_implementations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It explains the tool detects specific reflection methods, groups by method type, and that these usages are invisible to static searches and can break on renames. Implicitly read-only, but no explicit statement of non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured with usage, output, and list. Front-loaded with purpose. Minor inconsistency: usage line shows no parameters, but parameter exists, but overall concise and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisite, output format (grouped by method type), and rationale. Missing error handling for missing load_project, but output schema not required. Adequate for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers parameter 'maxResults' with description. Description does not add additional meaning beyond what schema provides. Baseline 3 because schema coverage is 100%.
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 states a specific verb (find) and resource (Java reflection API usage). It lists exact methods detected, making it highly specific and distinguishable from siblings like 'find_references'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description clearly states prerequisite ('Requires load_project to be called first') and why to use it (reflection calls invisible to static reference searches). Does not explicitly mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses the output categories (instantiations, casts, instance of, etc.) and the aggregating nature. It does not mention read-only or performance, but the output description is sufficient for understanding behavior.
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 well-structured with a usage line, output list, and bullet points. It is informative without being excessively long, though the bullet list could be integrated more concisely.
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?
No output schema exists, so the description's enumeration of return categories (instantiations, casts, etc.) is necessary and adequate. It also covers prerequisites, making it fairly complete for a multi-category analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds a usage example but no new meaning beyond the schema's parameter descriptions. The example is helpful but not necessary.
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 aggregates all usage patterns for a type, listing exact categories (instantiations, casts, instanceof, type arguments, annotations). This distinguishes it from sibling tools like find_casts or find_type_instantiations, which are single-purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with 'Use this to understand how a type is used throughout the project' and a prerequisite ('Requires load_project to be called first'). It implies this is the aggregate version over siblings but does not 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Includes safety check (refuses if variable modified after init), zero-based coordinate reminder, and states that edits need to be applied. Discloses key behavioral traits beyond basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three short paragraphs with clear headings. First sentence immediately states primary action. Every sentence adds necessary information with no redundancy.
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?
Covers all critical aspects: prerequisite (load_project), coordinate system, safety condition, and return type (text edits). No output schema, but return type is described. Minor gap: could mention if edits are a list or single, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds value by clarifying that line and column reference cursor position on variable declaration or usage, and reminding of zero-based coordinates. This aids correct parameter population.
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?
Clearly states the tool inlines a local variable by replacing usages with initializer, returning text edits. Distinguished from similar siblings like extract_variable by specifying the action of replacing usages.
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?
Provides explicit usage instructions: position cursor on declaration or usage, requires load_project first, and mentions safety refusal condition. Lacks explicit 'when not to use' but gives sufficient context for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions zero-based coordinates, return format (editsByFile), and JDT warnings. However, it does not explicitly state that the tool modifies files (though it returns edits for manual application) or clarify destructive nature. Adequate but missing important safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with separate sections for usage, output, and important notes. No filler sentences, but the structure is slightly fragmented. Still earns its space.
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 complex refactoring tool with no output schema, the description covers key aspects: what it does, how to invoke (position), output format, important coordinate system, and prerequisite. Reasonably 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 coverage is 100% with descriptions for each parameter. The description adds value by clarifying that line/column are zero-based, column is on method name, and providing default names for className and parameterName. This goes beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool bundles method parameters into a new class and rewrites method and callers. The verb 'bundle' and resource 'parameter-object class' are specific, and the description distinguishes it from sibling refactoring tools like extract_method or change_method_signature.
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?
Provides explicit usage instructions: position on method name, optionally name class/parameter, and requires load_project first. Lacks explicit when-not-to-use or alternative tool references, but context from sibling list helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses actions (applies fix, outputs text edits) and zero-based line numbers. However, ambiguous whether fix is actually applied or just returns edits. Missing error handling or side effects.
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?
Well-structured with summary, usage example, fix format list, and important note. Every sentence adds value, no redundancy.
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?
Covers purpose, parameters, prerequisites, and output. Could clarify whether fix is applied or only computed, but otherwise complete given no output schema.
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 covers all 3 parameters. Description adds value by explaining fix ID patterns and that line is zero-based and required for some fixes, going beyond schema descriptions.
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 'Apply a fix by ID' with a specific verb and resource. It provides fix ID formats and output type, distinguishing it from siblings like get_quick_fixes which only lists fixes.
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?
Includes usage example, fix ID formats, and prerequisite (load_project first). Does not explicitly state when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavioral details: output format (editsByFile, warnings, text), zero-based coordinates, and that edits are returned and must be applied manually. This is comprehensive and avoids surprises.
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 with 5 sentences, each serving a clear purpose: purpose, usage, output, important note, prerequisite. No waste, 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 no output schema, the description adequately explains the output and prerequisite. It covers what the tool does and how to use it, though it could elaborate slightly on what 'direct accesses' entails. Still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema, such as 'optionally name the accessors' correlating to getterName/setterName. No deep parameter semantics added.
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 explicitly states the tool encapsulates a field by generating getter/setter and rewriting direct accesses. It is a specific refactoring verb and resource, distinguishing it from sibling analysis or other refactoring tools.
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 mentions positioning on the field name and optional naming of accessors, but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives. The prerequisite 'Requires load_project to be called first' is useful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains that the tool determines parameters and return type, generates method signature and call site, and emphasizes zero-based coordinates. This sufficiently discloses behavioral traits, though it could mention error handling or side effects.
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 well-structured: a one-line summary, clear USAGE and OUTPUT labels, bullet points for analysis details, and a prominent note about zero-based coordinates. Every sentence serves a purpose, and key information is 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?
For a refactoring tool with 6 required parameters and no output schema, the description covers usage, output format, behavioral analysis, coordinate system, and prerequisites. It lacks details on error conditions or return value structure, but overall it is sufficiently complete for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so baseline is 3. The description adds context by explaining how parameters (e.g., selection range and method name) are used in the analysis and output generation. This goes beyond the schema's bare descriptions, providing deeper semantic meaning.
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 'Extract a code block into a new method,' which is a specific verb+resource combination. It distinguishes from sibling tools like extract_constant or extract_variable by focusing on method extraction. Additional details about analyzing variables and return types reinforce the purpose.
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 a usage line ('Select code range, provide method name') and a prerequisite ('Requires load_project to be called first'). However, it does not offer guidance on when to use this tool vs. alternatives like extract_constant or inline_method, nor does it mention conditions to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It states output as 'All locations where the annotation is applied' and mentions the prerequisite. However, it does not specify the output format (e.g., file paths, line numbers) or error behavior (e.g., if annotation is not found). This leaves some ambiguity for the agent.
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: three sentences plus a bulleted example list. It is front-loaded with purpose, then provides uniqueness, usage, output, examples, and prerequisite in a logical order. No superfluous words. Every sentence adds necessary 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 tool's simplicity (2 parameters, no output schema), the description covers key aspects: purpose, input format, output summary, prerequisite, and examples. It lacks details on default pagination (maxResults default 100) and error handling, but these are minor given the examples and schema. Overall, it is mostly complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing examples of fully qualified annotation names, which clarifies the required format. It also reinforces the parameter usage. Although the schema already describes typeName sufficiently, the examples make it more actionable.
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's purpose: 'Find all usages of an annotation type in the project.' It uses a specific verb+resource (find usages of annotation type) and distinguishes itself from siblings via the 'JDT-UNIQUE' note and by providing examples that show its specialization for annotations. This differentiates it from generic search tools like find_references or find_implementations.
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 usage guidelines: 'Provide fully qualified annotation name as typeName' and 'Requires load_project to be called first.' It implies the tool is for Java projects (JDT) and is unique compared to LSP. However, it does not explicitly tell when to use this tool over alternatives like find_references or find_implementations, which would further improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains important behaviors: zero-based coordinates, output is a list of modification locations, and the prerequisite. Could mention if it searches across files or just current project, but covers key traits.
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?
Concise 7-line description; front-loaded with purpose, then usage, output, coordinate system, sibling distinction, and prerequisite. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, it describes the output (list of locations) and prerequisites. Could be more explicit about scope (e.g., entire project) and performance, but overall complete enough for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds no new parameter meaning beyond the schema. The mention of zero-based coordinates is also in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Find all write accesses (mutations) to a field' with specific verb and resource, and explicitly distinguishes itself from the sibling tool 'find_references' by noting it returns only modification locations.
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?
Provides usage context ('Position cursor on a field declaration or reference'), mentions prerequisite ('Requires load_project to be called first'), and contrasts with 'find_references'. Lacks explicit when-not-to-use but the sibling contrast gives good guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 the search scope (throws declarations in method signatures only), input format, and prerequisite. It also notes the JDT-UNIQUE nature. Could be more comprehensive (e.g., case sensitivity, subclass handling), but overall informative.
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 well-structured: purpose, uniqueness note, usage format, output, use cases, prerequisite. Every sentence adds value with no repetition or fluff. Size is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and no annotations, the description covers purpose, usage, use cases, and prerequisite. It is sufficient for an agent to understand when and how to use it. Minor omission: output format details (e.g., whether fully qualified method names are returned). Still, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description reinforces the schema for typeName but adds no new meaning. For maxResults, no additional semantics are provided. Baseline 3 is appropriate when schema already documents parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and resource 'throws declarations of an exception type in method signatures.' It specifies input (fully qualified exception type) and output (list of methods). The JDT-UNIQUE note distinguishes it from LSP-based siblings, and no sibling tool duplicates this focused search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit usage instructions ('Provide fully qualified exception type name'), lists use cases, and mentions a prerequisite ('Requires load_project to be called first'). However, it does not explicitly state when to avoid this tool in favor of alternatives, though the JDT-UNIQUE note implies its unique value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It describes what it detects and the prerequisite, but does not explicitly state it is read-only (implied by 'find') or mention side effects, performance, or error conditions.
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?
Concise and well-structured: title, usage examples, output description, detection list, prerequisite. Every sentence is informative with no redundancy.
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?
Covers purpose, usage, output format, detection categories, and prerequisite. Lacks error handling details and output schema (since none provided). Adequate for the tool's 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?
Schema coverage is 100%, so baseline is 3. The description adds value by showing usage examples with the optional filePath parameter and default behavior (includeFields/methods default true).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds unused private methods and fields, listing specific detection categories (unused private methods, unused private fields, write-only fields). This distinguishes it from sibling tools like find_references or find_method_references.
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?
Provides two usage examples and explicitly states that load_project must be called first. However, it does not differentiate from sibling tools or give when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists tracked dependency types (import, extends, etc.), explains scope and name parameters, and mentions depth and includeExternal defaults. Does not explicitly state read-only nature but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, well-structured with code block examples and bullet list for dependency types. Every sentence adds value, and key information is 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 4 parameters, no output schema, and no annotations, description covers prerequisites, usage patterns, and tracked dependencies. Does not detail output structure (e.g., 'nodes and edges' is sufficient) but could include example output for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value with usage examples for scope and name, and explains dependency types. For depth and includeExternal, it does not add beyond schema but overall improves clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get package/type dependencies' with usage examples, specifying the verb and resource. It distinguishes from siblings like find_circular_dependencies by focusing on general dependency graph retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions prerequisite 'Requires load_project to be called first' but provides no guidance on when to use this tool over siblings (e.g., find_circular_dependencies) or when not to use it. No alternatives are explicitly suggested.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals the tool is a read operation showing package hierarchy with file counts and requires a prerequisite. Does not mention rate limits or side effects, but behavior is straightforward.
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?
Three sentences, front-loaded with main action. USAGE and OUTPUT sections are efficient. No redundant 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 no output schema, description explains output as 'Source roots with packages and file counts'. Covers prerequisite. Sufficient for a simple tool with only two optional parameters and full schema documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—both parameters have descriptions. The tool description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get project structure showing package hierarchy' and specifies output as 'Source roots with packages and file counts'. It distinguishes from sibling tools like get_type_hierarchy or get_dependency_graph.
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?
States 'USAGE: Call to see the package tree of the loaded project' and explicitly requires 'load_project to be called first'. Provides explicit context but doesn't mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses zero-based line numbers and the prerequisite. It describes the output format. It does not explicitly state that the tool is read-only, which is a minor 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 concise and well-structured: purpose, usage example, output format, list of supported fixes, important note, and prerequisite. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, output, supported fixes, and prerequisite. It lacks details on error handling or behavior when no fixes exist, but given the tool's simplicity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters described. The description adds the usage example but does not provide significant meaning beyond what the schema already provides (e.g., zero-based is already in schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available fixes for a problem at a position, with verb 'list' and resource 'fixes'. It distinguishes from sibling tools like 'apply_quick_fix' which applies a fix, and 'get_diagnostics' which provides problems.
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 a usage example and explicitly states the prerequisite ('Requires load_project to be called first'). It lists supported fix categories, guiding agent on when to use. However, it does not explicitly mention when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Discloses zero-based coordinates and prerequisite, but does not mention error handling (e.g., if symbol not found) or read-only nature.
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?
Very concise, with bullet-like structure. Each sentence adds necessary information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return values (file path, line, column) and includes zero-based hint. Missing error behavior, but overall fairly complete for a simple navigation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions. Description adds value by explaining zero-based context and that filePath can be absolute or relative, which clarifies usage beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Navigate to symbol definition', which is a specific verb and resource. It distinguishes from siblings like 'find_references' by focusing on definition location.
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?
Provides explicit usage: position cursor, returns definition location. Mentions prerequisite 'load_project' and zero-based coordinates. Lacks explicit when-not-to-use, but purpose is narrow enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses output format (editsByFile with warnings), that edits are returned as text (not applied), and the use of zero-based coordinates. It covers prerequisites and behavioral context well.
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 brief yet comprehensive, front-loading purpose, usage, output, and important notes. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains output and prerequisites adequately for a refactoring tool without an output schema. It could mention type hierarchy requirements but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds minimal additional meaning beyond reinforcing zero-based coordinates and the 'member name' context; nothing significantly new is provided.
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 pushes a method or field down into subclasses and removes it from the superclass, using specific verbs and resources. This distinguishes it from siblings like pull_up or extract_superclass.
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 usage instructions ('Position on the member name in the superclass') and a prerequisite ('Requires load_project to be called first'), but does not explicitly compare to alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details search scope (project sources, JDK, libraries) and sorting by relevance, which is good behavioral disclosure.
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?
Concise and well-structured: purpose, example, output description, search details, prerequisite. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param tool with no output schema and no annotations, the description adequately covers purpose, usage, search scope, and sorting. Could optionally note default maxResults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description only adds a usage example for 'typeName' but no additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Find import candidates for unresolved type' and provides a usage example. It is distinct from siblings like 'organize_imports' or 'find_references'.
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?
Explicitly requires 'load_project' to be called first. Usage example is provided, but no explicit when-not-to-use or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the operation (find), output (locations), and prerequisite. Could mention read-only nature, but overall adequate.
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?
Very concise: three sentences plus bullet points. Front-loaded with main purpose. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, description covers essential aspects: purpose, usage, prerequisite, output, and use cases. Complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds minimal extra meaning: specifies fully qualified type name for typeName, but no extra details on maxResults beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Find all instanceof checks for a type (x instanceof Foo)' using a specific verb and resource. The JDT-UNIQUE note distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'Provide fully qualified type name' and prerequisite 'Requires load_project to be called first.' Lists use cases but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavioral details: zero-based coordinates and prerequisite dependency. No annotations are present, so the description carries full burden; it adequately describes usage constraints but could mention read-only nature or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with six sentences; uses clear labels (USAGE, OUTPUT, IMPORTANT). Every sentence adds value, though minor redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers purpose, usage, coordinates, and prerequisite. Lacks detail on error cases or output format, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds value by clarifying the coordinate system is zero-based, which is significant beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool finds methods called by a method (outgoing calls), distinguishing it from incoming call hierarchy. The verb 'Find' and resource 'methods called by a method' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage instructions ('Position cursor on a method name') and a prerequisite ('Requires load_project to be called first'). Does not explicitly exclude alternative tools or compare to siblings, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses prerequisite (load_project), supported frameworks, unsupported annotation forms, default maxResults, and output format. This provides sufficient 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?
Description is well-structured with labeled sections (USAGE, OUTPUT, Supports, Options). It is front-loaded with purpose and efficiently communicates key details without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with no output schema, the description sufficiently explains return format (route->handler entries with details) and limitations (unsupported annotations). It is complete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds minimal value: it restates maxResults parameter with default. Baseline 3 is appropriate as schema already documents the parameter completely.
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 assembles the project's HTTP route table, with specific verb 'Assemble' and resource 'HTTP route table'. It distinguishes from sibling tools by focusing on HTTP endpoints.
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 mentions that load_project must be called first, and notes that projects without supported frameworks return empty. It also lists unsupported Spring annotations, but does not compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: non-static member types gain a field referencing the former enclosing instance, output format (createdFiles, editsByFile), zero-based coordinates, and that nothing is written. This sufficiently informs the agent of side effects and preconditions.
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 well-structured with labeled sections (USAGE, OUTPUT, IMPORTANT) and front-loads the main action. Every sentence adds value, though it could be slightly tighter (e.g., combining coordinate details).
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 refactoring tool with no output schema, the description explains the return fields and behavior (file creation not automatic). It covers prerequisites and coordinate system. Some edge cases (e.g., already top-level type) are not addressed, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds critical context: 'Uses ZERO-BASED coordinates' and 'Position on the nested type's name,' which clarifies how to set 'line' and 'column' beyond the schema's generic descriptions.
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 states clearly 'Move a member (nested) type into its own top-level file.' It uses a specific verb 'Move' and resource 'type', and the context of being a refactoring operation distinguishes it from sibling tools like 'analyze_type' or 'get_type_hierarchy'.
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?
Provides explicit usage instructions: 'Position on the nested type's name' and 'Requires load_project to be called first.' It explains the output structure and the need to manually create files, giving clear context on when and how to use. Does not explicitly state when not to use, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description bears full transparency burden. It describes tool's combined behavior and default for includeDiagnostics, but does not specify default for includeMembers (false) or any side effects. Minor gap, but overall satisfactory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is highly concise with clear sections (USAGE, OUTPUT, combines list, guideline). Every sentence serves a purpose, no wasted words, effectively front-loaded with key 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 complexity (combines multiple analyses) and no output schema, description provides sufficient overview of what is included. Minor missing detail on includeMembers default, but otherwise complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so description adds minimal value beyond illustrating usage (e.g., filePath example). No additional semantics for includeMembers or includeDiagnostics beyond schema, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Comprehensive file analysis in a single call' and lists specific components (file info, imports, types with member counts, diagnostics), differentiating it from sibling tools that provide individual analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite 'Requires load_project to be called first' and recommends using this tool instead of multiple calls to get_document_symbols and get_diagnostics, providing clear context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully covers tool behavior: outputs five categories of analysis. Does not explicitly state read-only nature, but 'analysis' and the listed output categories imply non-destructive behavior.
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?
Concise with clear structure: brief intro, usage example, output list, combined components, recommendation, and prerequisite. No unnecessary sentences; all information earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, description provides a high-level view of outputs and dependencies. Could improve by detailing output structure or error cases, but current description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. Description adds beyond schema by mentioning default values for includeUsages (true) and maxUsages (10), and includes a usage example for typeName.
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's purpose: 'Comprehensive type analysis in a single call,' listing specific outputs (type info, members, hierarchy, usage summary, diagnostics) and differentiating from sibling tools like get_type_members and get_type_hierarchy.
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?
Provides explicit usage example, recommends using this tool instead of multiple separate calls, and states prerequisite ('Requires load_project to be called first'). Does not explicitly list when not to use, but implies it's for combined analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adequately discloses zero-based coordinates and requirement for prior project loading. Could add more about error handling or behavior when not on a type, but sufficient.
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?
Very concise with clear labeled sections (USAGE, OUTPUT, IMPORTANT). No unnecessary words; every sentence provides essential 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?
Covers key aspects: what it does, prerequisites, output type, and coordinate system. No output schema, but output described. Could mention empty result case, but not critical for functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by emphasizing zero-based coordinates for line and column, and mentioning default for maxResults (100).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it finds implementations of interfaces or extensions of classes. Distinguishes from siblings like find_references and get_type_hierarchy by specifying the scope (implementors/subclasses) and usage position on type.
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?
Explicitly states prerequisite (load_project) and usage context (position on a type). Does not mention when to avoid this tool versus alternatives, but the purpose is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description implies a read-only operation by stating 'Get compilation diagnostics'. It adds important behavioral context: the need for prior load_project, and the output as a list of errors/warnings with locations. No mention of side effects or performance, but sufficient for a diagnostic 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 well-structured: a one-line purpose, followed by usage examples, output description, use cases, and a prerequisite. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose, usage, and prerequisites. It lacks details on the exact format of returned diagnostics or pagination, but given the schema provides maxResults and no output schema exists, it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with descriptions. The description adds value by showing example usage patterns and clarifying the optional nature of filePath. The severity and maxResults parameters are not elaborated in the description, but the schema handles them sufficiently.
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 retrieves compilation diagnostics (errors and warnings) for a file or project, using a specific verb and resource. It distinguishes itself from sibling analysis tools by focusing on errors and warnings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage patterns: get_diagnostics() for all files or with a filePath parameter for a specific file. It also mentions the prerequisite of calling load_project first, giving clear context for when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses zero-based coordinates, prerequisite, and output nature (signature, javadoc, quick info). A minor gap: no mention of behavior on invalid positions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with clear headers (USAGE, OUTPUT, IMPORTANT). Every sentence serves a purpose, no redundancy.
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 simple read tool, covers purpose, usage, output, prerequisite. Lacks details on error handling or empty results, but overall complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by explaining coordinates represent a symbol position and that they are zero-based, enhancing semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets hover information (documentation) for a symbol at a position, specifying output as signature, Javadoc, and quick info. It distinguishes from siblings like get_javadoc and get_signature_help by mentioning 'hover' context, and notes zero-based coordinates.
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?
Provides explicit usage guidance: 'Position on any symbol' and prerequisite 'Requires load_project to be called first.' However, it does not explicitly compare to similar position-based tools like get_method_at_position.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses zero-based coordinates and prerequisite. Does not detail side effects or output format, but adequats for a query 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?
Very concise with clear sections (USAGE, OUTPUT, IMPORTANT). No wasted words, essential information 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 no output schema, describes output as 'superclass/interface method'. Lacks specific return structure, but sufficient for a simple query tool among many siblings.
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 has 100% coverage with descriptions. Adds value by stating coordinates are zero-based, clarifying expected input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it finds the super method overridden/implemented by a given method. Differentiates from siblings like 'find_implementations' by specifying the exact relationship.
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?
Explicitly instructs to position on a method that overrides/implements, and mentions prerequisite load_project. Lacks explicit when-not-to-use but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses key behavioral traits: zero-based coordinates, requirement to have loaded project, and output content (superclasses, interfaces, subtypes). Clearly a read operation with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise but complete: two sentences for purpose, followed by structured USAGE, OUTPUT, modes, important note, and prerequisite. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately covers prerequisites, coordinate system, and invocation modes. Could be more specific about the structure of the returned hierarchy, but it's sufficient for an agent to understand the tool's behavior.
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?
Input schema covers all 5 parameters with descriptions. Description adds context: clarifies zero-based coordinates for line/column, default maxDepth=10, and distinguishes position-based vs typeName lookup. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves type hierarchy (supertypes and subtypes) for a Java type, using a specific verb+resource. Distinguishes from siblings like 'get_type_at_position' and 'get_type_members' by focusing on inheritance chain.
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?
Provides explicit usage instructions: two modes (file position or type name), prerequisite (load_project), and coordinate system. However, does not include when-not-to-use guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully describes behavioral aspects: it returns an edit to be applied, uses zero-based coordinates, and lists limitations. This gives the agent a clear understanding of what to expect.
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 well-structured: purpose, usage, output, important note, limitations, prerequisite. Every sentence adds value, and key information is 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?
The description covers purpose, usage, output, limitations, and prerequisites. It lacks details on error handling or edge cases, but for a refactoring tool with no output schema, it is sufficiently 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?
Input schema has 100% coverage, but the description adds valuable context: zero-based coordinates and that column refers to the method name. This goes beyond the schema's field descriptions.
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 inlines a method call by replacing it with the method body, distinguishing it from siblings like inline_variable which handle variables. The verb 'inline' and resource 'method call' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage instructions ('Position cursor on a method call') and prerequisites ('Requires load_project to be called first'). Limitations are stated (same project, simple methods) but alternative tools like inline_variable are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It transparently discloses that it returns text edits, uses zero-based coordinates, and updates all call sites. Could mention potential conflicts or side effects, but overall adequate.
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?
Concise with clear sections for usage, output, parameter operations, and important notes. Front-loaded with purpose. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex refactoring tool, the description covers prerequisites, coordinate system, parameter operations, and output format (text edits). No output schema provided, but explanation suffices. Complete and actionable.
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?
Input schema covers all 6 parameters with descriptions (100% coverage). Description adds extra semantics by explaining parameter operations (add, remove, rename, reorder) and default values, which goes beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'change' and the resource 'method signature', and specifies it updates all call sites. It distinguishes from sibling tools like rename_symbol or extract_method.
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?
Provides clear usage context: 'Position on method declaration, provide changes' and prerequisite 'Requires load_project to be called first.' Lacks explicit when-not-to-use or alternatives among siblings, but gives sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output as a text edit to be applied, zero-based coordinates, and prerequisite. No annotations exist, so description carries the burden and does so well, though could mention side effects.
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?
Structured with clear sections (USAGE, OUTPUT, IMPORTANT, REQUIREMENTS), concise and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage, output type, coordinate system, prerequisites, and requirements. No output schema needed as return type is described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds detail like zero-based coordinates and positioning on 'new' keyword, enhancing meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts an anonymous class to a lambda expression, specifying verb, resource, and result. It distinguishes from sibling refactoring 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?
Provides explicit usage instructions (cursor on 'new' keyword), requirements (functional interface), and prerequisite (load_project). Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of disclosure. It explicitly states that the tool does not write anything ('Nothing is written - create the file and apply the edits yourself'), which is critical for an AI agent to understand the side-effect-free nature of the operation. It also details the output format.
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 extremely concise with only two short paragraphs. The first sentence immediately states the purpose, followed by a usage summary and important notes. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 required parameters, no output schema, no annotations), the description covers all necessary contextual information: purpose, usage, coordinate convention, output format, and prerequisite ('Requires load_project'). The agent has enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for each parameter. The description reinforces the zero-based coordinates but adds no new semantic meaning beyond the schema. Baseline is 3, and the description does not earn a higher score because it restates rather than enriches.
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 ('Extract') and clearly identifies the resource ('new superclass from a class') and the action (moving a member up). It distinguishes from siblings like 'extract_interface', 'extract_method', and 'pull_up' by specifying the creation of a superclass with a member moved up.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage instructions: 'Position on the member to extract; provide the new superclass name.' It also includes important preconditions ('Requires load_project to be called first') and coordinate convention. However, it does not explicitly state when not to use this tool or contrast with similar extraction tools among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 disclosure. It states that the tool returns text edits (not applying them) and uses zero-based coordinates, and requires load_project. It adequately communicates the non-destructive, edit-returning behavior.
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: four sentences covering purpose, output, usage, and prerequisite. Every sentence adds value without redundancy, and the structure is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a refactoring operation and the lack of an output schema, the description adequately explains what it does (extracts to variable), what it returns (text edits), the coordinate system (zero-based), and the prerequisite (load_project). No critical gaps are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage. The description reinforces the use of zero-based coordinates and aligns with parameters (start and end positions). It adds meaning beyond the schema by highlighting the zero-based requirement and the optional variableName parameter.
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 explicitly states the tool's purpose: 'Extract an expression at the given position into a local variable.' It specifies the verb 'Extract' and the resource 'expression into a local variable,' clearly distinguishing it from sibling tools like extract_constant and extract_method.
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 usage guidelines: 'Select expression by providing start and end positions' and 'Requires load_project to be called first.' It implies when to use (extracting to a local variable) but does not explicitly exclude alternatives or mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavior: it checks naming conventions and lists violations. It enumerates the specific conventions checked. There's no mention of destructive actions, as it is a read-only analysis.
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 well-structured with a brief summary, usage pattern, output expectation, list of conventions, and additional notes. Every sentence adds value, and it is concise without being terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description adequately explains output as a list of violations. It covers the conventions checked, parameter behavior, and prerequisites, making it complete for an AI agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. The description adds value beyond the schema by providing a usage example and clarifying that omitting filePath scans all project files, which is not immediately clear from the schema description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Check code against standard Java naming conventions,' with a clear verb and resource. It distinguishes itself from siblings by focusing specifically on naming violations, a unique task among the listed 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 a usage example, explains the optional filePath parameter, and mentions the prerequisite 'Requires load_project to be called first.' It lacks explicit when-not-to-use or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses zero-based coordinates and output contents (type, modifiers, constant value). No annotations exist, so description carries full burden; it covers key behavioral traits without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences organized with clear sections (USAGE, OUTPUT, IMPORTANT), no redundant information, and highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 required parameters and no output schema, the description explains inputs, coordinate system, output, and prerequisite. Fully adequate for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 3 parameters (100% coverage). Description adds value by emphasizing zero-based coordinates and output details, exceeding the baseline of 3.
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 'Get field information at a specific position' and specifies usage on a field reference or declaration. This distinguishes it from sibling tools like get_method_at_position and get_type_at_position.
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?
Provides explicit usage context: 'Position on a field reference or declaration' and prerequisite 'Requires load_project to be called first.' No exclusion criteria, but sufficient for general use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses scanning behavior (Entity, Table, Id, relationships), target resolution method, and empty model for non-JPA projects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with usage, output, scanning details, and prerequisites. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the output (entities with table name, id, relationships, locations). It covers prerequisites, parameter default, and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description already includes the default value. The tool description repeats this info without adding new semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it assembles the JPA entity model, specifies the output includes tables, IDs, and relationships, and distinguishes it from sibling tools by focusing on JPA entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite 'Requires load_project to be called first' and notes behavior when JPA is absent. It lacks explicit comparison to alternatives but the tool is unique enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Emphasizes zero-based coordinates and load_project dependency. Lacks explicit statement about read-only nature, but the purpose implies no side effects.
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?
Well-structured with clear sections, no wasted words, and front-loaded important information (purpose and usage).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes output fields (signature, parameters, etc.) despite no output schema, and covers all necessary context for a simple positional lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by mentioning zero-based coordinates for line and column, which is critical for correct usage.
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?
Specific verb 'Get' and resource 'method information at a specific position', clearly distinguishing from sibling tools like get_field_at_position or get_type_at_position.
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?
States usage on 'method reference or declaration' and prerequisite 'load_project', but does not explicitly exclude cases where other tools (e.g., get_type_at_position) would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description clearly states the output type (method signatures with parameter info) and the zero-based coordinate system, which is a critical behavioral detail for correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a clear structure: line for purpose, bullet for usage, line for output, important note, and prerequisite. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a signature help tool with no output schema, the description adequately covers input context (zero-based coordinates, prerequisite), output expectation (signatures with param info), and usage context. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter clearly documented. The description adds no additional semantic value beyond reiterating zero-based coordinates (already in schema). Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves method signature help at a given position, and specifies it is for method calls or declarations, distinguishing it from sibling tools like get_hover_info or get_method_at_position.
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?
Provides explicit usage context (position on method call/declaration) and a critical prerequisite (load_project). Does not discuss alternatives or when to avoid, but the usage is well-scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals that the tool uses zero-based coordinates and requires load_project. It also summarizes output content ('kind, modifiers, signature, location'), providing insight into behavior beyond a simple fetch.
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 brief yet comprehensive, using clear sections (USAGE, OUTPUT, IMPORTANT) without redundancy. Every sentence adds value, making it easy for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and three parameters, the description covers purpose, usage, output summary, coordinate system, and prerequisite. There are no obvious gaps for an information retrieval 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?
Schema coverage is 100%, but the description adds critical meaning by highlighting that coordinates are zero-based. This is essential for correct parameter usage and goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about any symbol at a position', distinguishing it from similar tools like get_type_at_position or get_method_at_position. It specifies that it works on any symbol (type, method, field, variable).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage instructions: 'Position on any symbol (type, method, field, variable)', notes coordinate system ('Uses ZERO-BASED coordinates'), and states prerequisite 'Requires load_project to be called first'. It does not explicitly compare with siblings but gives sufficient context for correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: output structure (editsByFile covering superclass and subclass), warnings from condition checking, and that edits are returned as text (not automatically applied). Also notes zero-based coordinates, which is important for correct invocation.
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 structured with clear sections (purpose, usage, output, important note) and is front-loaded with the main action. It is concise with only necessary details, though 'USAGE' and 'OUTPUT' could be slightly condensed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, how to use it (positioning), prerequisites (load_project), output format, and the need to manually apply edits. No output schema exists, but the text description suffices for an agent to understand the consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by clarifying the coordinate system ('Uses ZERO-BASED coordinates') and the semantic meaning of line and column ('Position on the member name in the subclass'), which is beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Pull a method or field up into the superclass') and the effect ('remove it from the declaring subclass'). It specifies the resource (superclass) and distinguishes from related tools like 'push_down' implicitly through the naming.
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?
Provides explicit usage instruction: 'Position on the member name in the subclass.' and prerequisite: 'Requires load_project to be called first.' Lacks explicit when-not-to-use or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses glob patterns, pagination, and output (list of symbols with locations). Does not mention performance or limits, but overall sufficient.
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?
Well-structured with clear sections: purpose, glob support, usage line, examples, pagination, prerequisite. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description covers all necessary aspects: search criteria, usage patterns, pagination, and prerequisite. Complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds value with usage examples and specific glob patterns. Goes beyond schema by demonstrating how parameters are used together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search for types, methods, fields by name pattern', specifying the verb (Search) and resource (symbols by name). Distinct from siblings like find_references and get_symbol_info, which serve 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite ('Requires load_project to be called first'), examples, and pagination info. Does not explicitly mention when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses direct and transitive mode behaviors, depth limits, maxResults cap, supported symbol types, and output format changes between modes. This is comprehensive and transparent.
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 well-structured with a purpose statement, usage example, output description, and bulleted options. While slightly lengthy, every section provides necessary information, and the front-loading helps quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema), the description explains output formats and main behaviors. It covers both depth and transitive modes. Minor missing details like error handling or edge cases, but overall adequate for selection and invocation.
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 covers all 6 parameters with 100% description coverage. The tool's description adds significant value beyond the schema by explaining default values, mode behaviors, and the meaning of depth levels, enabling correct parameter usage.
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's purpose: 'Analyze the blast radius of changing a symbol.' It includes a usage example, output description, and detailed options. The tool's name and description differentiate it from siblings like 'find_references' and 'get_call_hierarchy_incoming' by focusing on impact analysis.
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 a usage example, parameter explanations, and the prerequisite 'Requires load_project to be called first.' It lacks explicit guidance on when not to use this tool versus alternatives, but the behavioral details (e.g., transitive vs depth) help infer appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses no semantic analysis and output type (Syntax errors), but lacks details on error format. No annotations provided, so description carries burden; the disclosure is adequate.
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?
Four sentences, front-loaded with purpose, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, prerequisite, and output nature well for a simple tool, but could briefly mention return type or format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds usage examples and optional filename context, adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Quick syntax-only validation' for file or inline code, differentiating from siblings like get_diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for quick syntax checks', contrasts with get_diagnostics for semantic analysis, and notes prerequisite load_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that no changes are written ('NOTHING is written - apply the returned edits yourself'), and explains the output structure (problems, editsByFile) and behavior for files with no fixable diagnostics. No annotations are provided, so the description fully carries the transparency burden.
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 well-structured: a purpose sentence, a usage line, an output description, a crucial note about not writing, and a condition for empty results. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, no output schema, and no annotations, the description fully covers the tool's input, output, behavior, and prerequisites. It explains the output format and the condition for empty results, leaving no significant gaps.
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 single parameter 'filePath' has a minimal schema description. The description adds context: it shows the usage format, confirms the file is a source file, and references the prerequisite that load_project must be called. This adds value beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool diagnoses a file and computes quick-fix edits in one call, specifying the verb (diagnose and fix) and resource (file). It distinguishes from siblings like get_diagnostics and apply_quick_fix by combining both steps.
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?
Provides a usage example and explicitly states the prerequisite 'load_project' must be called first. It also clarifies that the tool does not write edits. However, it does not explicitly contrast with alternatives like get_quick_fixes+apply_quick_fix, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: the caller walk mechanism, inclusion of disabled tests, handling of unreachable symbols, and support for methods, fields, types. It transparently describes what happens in various scenarios.
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 well-structured with clear sections: purpose, usage, output, details, options, prerequisite. It is concise yet comprehensive, using bullet points and plain language effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains the output format, including disabled tests and empty sets. It covers all necessary aspects of the tool's operation, making it complete and useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving baseline 3. The description adds value by providing a usage example, explaining the coordinate parameters, and clarifying the maxResults option. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find the test methods that exercise a symbol, directly or transitively.' It provides a usage example and distinguishes itself from siblings like 'find_tests' by focusing on affected tests, not all tests.
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 includes a prerequisite ('Requires load_project to be called first') and explains the context ('the set of tests to run after changing it'). It does not explicitly state when not to use it, but it provides clear guidance for intended use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: loading process, potential delay, SYNC mode for disk verification, and when reload is needed. Could add more on internal state changes.
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?
Well-structured with sections and bullet points, front-loaded with key info. Slightly verbose but every sentence contributes; could tighten redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a setup tool: describes output format, workflow, SYNC semantics, and when to call. No output schema but description compensates adequately.
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?
Even though schema covers 100%, the description adds value with an example usage, clarifies 'absolute path', and lists supported project types. This goes beyond schema basics.
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 'Load a Java project for analysis' and establishes it as a prerequisite for other tools, distinguishing it from siblings by its unique initialization role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'MUST be called before using other analysis tools' and provides a workflow with steps, when to call (first use, RELOAD_REQUIRED, rebuild), and references alternatives like health_check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses behavior: how reachability is computed (calls, instantiations, field accesses, etc.), what counts as roots (main methods, test methods), and what the output includes (members with visibility and location). It also clarifies that disabled tests still count as entry points.
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 well-structured with clear sections (USAGE, OUTPUT, explanation of roots, IMPORTANT caveats, Options). It is concise yet comprehensive, with every sentence adding necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is complete: it explains the algorithm, the meaning of results, limitations (invisible entry points), and prerequisites. No output schema is provided, but the description sufficiently covers the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining defaults ('default true' for includeTestRoots, 'default 100' for maxResults) and context for the options, which goes beyond the schema's type descriptions.
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's purpose: 'Find code unreachable from any entry point, project-wide.' It distinguishes this from sibling tools like 'find_unused_code' by specifying the project-wide scope and entry point focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage syntax, outlines options, and gives a critical caveat: results indicate unreachability from declared entry points, not safe-to-delete due to reflection and DI. It also notes the prerequisite 'Requires load_project to be called first.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes output (server status, project info, capabilities) and implies read-only health check behavior, which 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences plus a structured workflow list. Purpose is front-loaded, every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check tool with no params and no output schema, the description fully covers purpose, usage, workflow, and expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params, 100% schema coverage), so baseline 4. Description doesn't need to add param info, and it doesn't miss any.
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 'Check server status and project state.' and specifies 'Call on startup to verify server is operational.' This distinguishes it from all sibling tools which focus on code analysis/refactoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly saying 'Call on startup' and providing a workflow (1. health_check, 2. load_project if needed) gives clear when-to-use and next steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![javalens-mcp MCP server](https://glama.ai/mcp/servers/pzalutski-pixel/javalens-mcp/badges/card.svg)](https://glama.ai/mcp/servers/pzalutski-pixel/javalens-mcp)

Score Badge

Copy to your README.md:

[![javalens-mcp MCP server](https://glama.ai/mcp/servers/pzalutski-pixel/javalens-mcp/badges/score.svg)](https://glama.ai/mcp/servers/pzalutski-pixel/javalens-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pzalutski-pixel/javalens-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server