agent-lsp

Server Quality Checklist

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

Latest release: v0.18.0
Disambiguation5/5
Each tool targets a distinct LSP operation or workflow step. Navigation tools (go_to_definition, go_to_declaration, go_to_implementation, go_to_type_definition, go_to_symbol) are clearly differentiated by which aspect of the symbol they resolve. Simulation tools form a clear pipeline (create, edit, evaluate, commit/discard/destroy) with no overlap. All tools have unique purposes.
Naming Consistency5/5
Tool names consistently follow a verb_noun pattern (e.g., open_document, get_references, rename_symbol). Some use 'get_' vs 'simulate_' but the pattern is uniform. Even compound names like simulate_edit_atomic follow the same convention. No mixed cases or unrelated verbs.
Tool Count4/5
50 tools is high but justified by the comprehensive coverage of LSP features and additional utilities (simulation, build, test, cross-repo references). A few tools could potentially be merged (e.g., simulate_edit and simulate_edit_atomic) but overall the count reflects the server's ambition and the complexity of code analysis.
Completeness5/5
The tool set covers the full lifecycle of code interaction: document management, navigation, diagnostics, editing (with simulation), formatting, refactoring, testing, and building. It also includes workspace management, cross-repo references, and server introspection. No obvious gaps for an LSP-based code agent.
Average 4/5 across 50 of 50 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 5 of 6 community issues answered or closed in the last 6 months
- 68 commits in the last 12 weeks
- Last stable release on August 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This repository includes a glama.json configuration file.
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?
With no annotations, the description must cover behavioral aspects. It mentions LSP and return values, but omits important details like prerequisites (LSP server), error handling, state changes, and performance implications.
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?
Two sentences, front-loaded with purpose. No redundant words, but the second sentence could be merged or trimmed slightly without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 5 parameters with 0% schema coverage, the description is under-specified. It fails to explain return format details, error conditions, or how parameters interact.
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 0%. The description implicitly explains file_path, line, and column via 'symbol at a specific location', but entirely ignores the optional parameters language_id and position_pattern, leaving their purpose ambiguous.
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 action ('jump to definition'), the resource ('symbol at a specific location'), and the outcome ('returns file path and position'). However, it does not explicitly differentiate from similar sibling tools like go_to_declaration or go_to_implementation, which is a missed opportunity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides broad usefulness ('navigating to type declarations, function implementations, or variable assignments') but no guidance on when NOT to use this tool or which alternative to choose from the many sibling navigation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It mentions retrieving information but does not disclose that it's a read-only operation, any side effects, or auth requirements. Assumes non-destructive behavior without stating it.
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?
Three sentences with clear first sentence stating purpose. Usage guidance in subsequent sentences is helpful but could be slightly more concise. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description is incomplete. It does not specify parameter details or describe the return format (hover content). Insufficient for reliable tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters beyond implying the need for file_path, line, column. No explanation of language_id or position_pattern. Agent cannot infer how to use these parameters correctly.
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?
Description clearly states the tool retrieves hover information (type info, documentation) for a code location. It implicitly distinguishes from sibling tools like get_completions or get_signature_help by focusing on 'hover' context, but does not explicitly differentiate.
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 guidance on when to use (understanding variable types, function signatures, module documentation) but lacks explicit when-not-to-use or alternatives among the many sibling 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 bears full responsibility. It explains the default direction and return types (callers/callees) but does not disclose read-only nature, required LSP state, or behavior on missing positions. The description is adequate but lacks some common behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the core functionality in the first sentence and usage guidance in the second. No extraneous information, perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description should be more comprehensive. It lacks details on how to specify position (line/column format), file path conventions, and the structure of the returned hierarchy. Significant gaps remain for a code navigation 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 0%, meaning no parameter descriptions in the schema. The description explains the 'direction' parameter and its default, but fails to describe 'file_path', 'line', 'column', and 'language_id'. With 5 parameters, this is insufficient compensation.
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 shows call hierarchy for a symbol, distinguishing callers and callees. However, it does not explicitly differentiate from sibling tools like 'type_hierarchy' or 'get_references', though the name 'call_hierarchy' provides some distinction.
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 says 'Use this to understand code flow', providing clear context. It does not mention when not to use it or alternatives, but the instruction is sufficient for basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose all behavioral traits. It mentions freeing resources but omits critical details such as whether unsaved changes are discarded or if confirmation is required.
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, each serving a purpose: action, usage context, and best practice. No redundant information.
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 the basic purpose and usage scenario but lacks parameter details and behavioral transparency. For a simple tool, it is minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the parameter. It does not clarify that 'file_path' should be an absolute path, URI, or any format, leaving the agent uninformed.
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 ('close a file') and the resource ('in the LSP server'), making it distinct from sibling tools like open_document.
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 advises when to use the tool ('when you're done with a file') and provides rationale (free up resources, reduce memory usage), though it does not mention 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. However, it only mentions that completions are context-based and does not explain read-only nature, error handling, or prerequisites like having an open document. The description lacks depth on 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 concise with four sentences, starting with the core purpose and expanding with examples. No irrelevant information is present, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with no schema descriptions, no output schema, and no annotations, the description is incomplete. It does not explain return format, language support, or edge cases, leaving significant gaps for the agent.
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?
The schema has 0% description coverage, meaning parameters like file_path, line, column, and language_id are not explained. The description only refers to location but does not specify formats, constraints, or which parameter is optional (language_id). This is insufficient 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?
The description clearly states the tool retrieves completion suggestions at a specific location, listing examples like variable names and function calls. It distinguishes itself from sibling tools like get_code_actions or get_info_on_location, 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?
The description explains when to use the tool: for code completion options and determining available functions when changing libraries. It does not explicitly state when not to use it, 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 full burden. It discloses the mechanism (LSP) and return value (file path and position), but does not reveal side effects, authentication needs, rate limits, or prerequisites like requiring an open document. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: action/mechanism, family context, usage advice and return value. Front-loaded and to the point with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks parameter explanations and does not specify format (e.g., line/column indexing, language_id values). With no output schema, it mentions return value but is incomplete for a 4-parameter tool with zero schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema), yet the description provides no explanation of parameters (file_path, line, column, language_id). It does not add value beyond parameter names, which is insufficient for correct invocation.
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 ('jump to declaration') and resource ('symbol at a location in a file via LSP'). It also distinguishes itself from siblings by naming the 'go to X' family and specifying languages like C/C++ where declaration differs from definition.
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 when the tool is most useful (languages with separate declaration/definition) and names the related sibling tools for context. However, it does not explicitly state when not to use it or provide direct comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. While it mentions using LSP and navigating to type declaration, it does not explain prerequisites (e.g., document must be open), side effects (e.g., cursor movement), or return value (e.g., location). Critical 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that are front-loaded with the primary action and then provide context. Every sentence adds value; there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, no annotations, and no parameter descriptions in the schema, the description should cover more. It lacks information on how to use the parameters (e.g., coordinate system, optionality of language_id), the expected behavior (e.g., does it open a document?), and whether the LSP server must be initialized. The description is insufficient for comprehensive understanding.
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 description coverage is 0%, meaning the description must compensate. However, it adds no information about parameters beyond their names (file_path, line, column, language_id). The parameter names are self-explanatory to some extent, but the description does not clarify optionality of language_id or expected file path format. Baseline would be 3 for 0% coverage, but the lack of any parameter explanation reduces the score.
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 jumps to the type definition of a symbol via LSP and explicitly distinguishes it from go_to_definition, which goes to where the symbol itself is defined. The verb 'Jump to' combined with 'type definition' and the contrast with the sibling tool provides high clarity.
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 context by noting it is 'Useful for interface types, type aliases, and class definitions when working with instances or variables.' It contrasts with go_to_definition but does not explicitly state when not to use the tool or mention other alternatives beyond that one sibling.
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 key behaviors: adding consumer roots as workspace folders, waiting for indexing, calling get_references, and partitioning results by repo. It also specifies the return structure (library_references, consumer_references, warnings). However, it omits side effects like whether roots are removed after, permissions needed, or potential delays.
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 (three sentences) with the main purpose front-loaded. It includes necessary behavioral details without excessive verbosity. Minor redundancy exists (e.g., 'partitions results by repo' and then listing the partitions), but overall it's well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (cross-repo search, indexing, partitioning) and no output schema, the description provides a basic outline but lacks details such as error handling, limitations (e.g., number of roots), prerequisites (e.g., LSP running), and behavior when consumer_roots is null. The return types are explained, but completeness is only moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% coverage in the description. The description does not explain any parameter's meaning, format, or constraints. For example, it doesn't mention that 'line' and 'column' are 0-based or what 'language_id' refers to. The schema's property names are self-documenting but insufficient for complex tools. The description should compensate but fails.
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 function: 'Find all references to a library symbol across one or more consumer repositories.' This specific verb-resource combination distinguishes it from siblings like get_references, which is limited to a single repo. The description also outlines the process (adding consumer roots, waiting for indexing, partitioning results), reinforcing purpose clarity.
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 context for when to use this tool: 'Use before changing a shared library API to find all downstream callers.' This is helpful, but it does not explicitly state when not to use it or provide alternative tools (e.g., fallback to get_references for single-repo references). The guidance is present but not exhaustive.
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. It states the return format (array of InlayHint objects with position, label, optional kind), includes failure behavior (empty array if server unsupported), and mentions the underlying protocol (LSP). However, it does not explicitly confirm the operation is read-only or side-effect free, which is implied by 'Get' but not made explicit.
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 (4 sentences) and front-loaded with the action and resource. It efficiently covers what inlay hints are, their utility, and return structure. However, the explanatory sentence about inlay hints could be shortened or integrated with the rest.
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?
For a tool with no output schema and 0% parameter coverage, the description covers the return format (array of InlayHint objects) and a failure scenario but lacks detailed parameter semantics. The use case is mentioned, but critical details like coordinate system (0/1-indexed) and the optional language_id are omitted, leaving gaps for accurate invocation.
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 description coverage is 0%, so the description must compensate. It mentions 'range within a document' which broadly relates to start/end line/column parameters but provides no specific explanations or constraints for any of the 6 parameters (e.g., whether lines are 0-indexed, the role of language_id). The description adds minimal meaning beyond the parameter names.
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 verb 'Get', resource 'inlay hints for a range within a document via LSP', and explains the specific LSP method (textDocument/inlayHint). The description distinguishes inlay hints from other LSP features by defining them as inline annotations for type names and parameter labels, which differentiates it from sibling tools like get_completions or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage contexts ('useful in languages with type inference... to see what the compiler knows') but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the tool's behavior (returns overloads, highlights parameter) and mentions it uses LSP. Though no annotations are provided, the description adequately conveys the read-only nature and typical use, 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?
Two sentences with no wasted words. The first sentence states purpose and mechanism; the second provides a usage tip. Perfectly sized for the task.
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 4 parameters, no output schema, and no annotations, the description is functional but incomplete. It lacks parameter details, return value format, and any mention of error conditions. Adequate for a simple LSP tool but with clear gaps.
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 0% with no parameter descriptions. The description implies file_path, line, column but does not explicitly map or describe any of the 4 parameters, including the optional language_id. The description adds minimal value over the raw 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 returns function signature help at a location via LSP, specifying 'returns available overloads and highlights the active parameter'. It distinguishes usage context but does not explicitly differentiate from siblings like get_completions.
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 advises 'Use this when the cursor is inside a function call's argument list', providing clear context. However, no when-not or alternative tools are mentioned, such as suggesting get_completions for general completions.
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 the description carries the burden. It explains text-match tries exact match then whitespace-normalized line match, but lacks details on mutation, error handling, return values, or safety implications.
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?
Three well-structured sentences, front-loaded with purpose and modes. No redundant information, though the third sentence could be slightly tighter.
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 modes and text-match behavior, but given 4 parameters and no annotations or output schema, it lacks details on failure cases, response format, or prerequisites like file existence.
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 0%, so the description must compensate. It clarifies that workspace_edit is used in one mode and file_path + old_text + new_text in the other, but does not fully specify formats or constraints, leaving some ambiguity.
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 applies an edit to a file and distinguishes two specific modes (WorkspaceEdit and Text-match). The description ties each mode to its use case, making it highly clear what the tool does.
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 guidance on when to use each mode: WorkspaceEdit for positional changes from rename_symbol/format_document; Text-match when AI-generated positions are imprecise. Does not list alternatives or exclusions but gives practical context.
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 states 'revert all in-memory changes by restoring baseline content,' which is clear about the core action. However, it does not disclose side effects such as whether the session is permanently removed or if the session ID must be valid, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. Every sentence adds value: the first explains the action, the second gives usage context. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, no output schema, no annotations), the description covers the basic purpose and a usage condition. However, it lacks details about post-discard state (e.g., session reuse), error handling for invalid IDs, or any prerequisites. Slightly incomplete.
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 0% (no parameter descriptions). The description does not elaborate on the session_id parameter beyond its name, so it adds no semantic value. For a tool with a single parameter, the description should clarify what session_id represents or where to obtain it.
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 'discard' and resource 'simulation session', and explains the effect: reverting in-memory changes by restoring baseline content. It also provides a usage condition, distinguishing it from related siblings like commit_session or create_simulation_session.
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 says 'Use when simulation results show the changes would introduce errors,' providing a clear trigger. Does not explicitly mention when not to use or alternatives like commit_session, but the condition is sufficiently specific.
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?
Without annotations, the description carries full burden. It discloses that the tool is read-only (inspection only) and uses LSP, and that edits are returned but not applied. This provides sufficient behavioral context for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with the action and outcome. Every sentence earns its place.
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?
For a tool with 4 parameters and no output schema or annotations, the description omits parameter explanations and return format details beyond TextEdit[]. It is complete for the core purpose but lacks context for correct parameter usage, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description does not explain any of the four parameters (tab_size, file_path, language_id, insert_spaces). The schema is the only source, and the description adds no semantic value beyond the parameter names.
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 formatting edits for an entire document via LSP', specifying the verb (get), resource (formatting edits), and context (document via LSP). It distinguishes from sibling tools like format_range which targets ranges.
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 says 'Use this to see what formatting changes a formatter would make' and notes edits are not applied automatically, guiding the agent to choose this for preview rather than applying edits. However, it does not explicitly mention when not to use or list 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 are provided, so the description must convey behavior. It clarifies the tool retrieves actions without applying them, but does not disclose potential side effects, permissions, 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?
The description is two sentences, front-loaded with the core purpose, and includes useful examples. 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?
Given the lack of annotations and output schema, and 6 parameters with zero coverage, the description provides a basic understanding but leaves gaps about return values and parameter details.
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?
With 0% schema description coverage, the description should explain parameters. It mentions 'specific range in a file' implying line/column and file_path, but ignores language_id and does not specify formats or constraints.
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 code actions for a specific range in a file, with concrete examples like refactorings and quick fixes. It distinguishes itself from sibling tools such as get_completions or execute_command.
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 advises when to use the tool (obtaining refactorings, quick fixes, etc.) and implies the context (a selected code range). However, it does not explicitly state when not to use it or suggest 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?
With no annotations, the description reveals that results include file path and line/column, and implies LSP interaction. It does not mention prerequisites (e.g., active LSP server) or limitations, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: first sentence defines action and method, second describes return, third gives use cases. No wasted words, front-loaded with key information.
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 6 parameters with zero schema descriptions and no output schema, the description covers purpose and usage well but fails to detail parameters. Completeness is adequate for basic understanding but incomplete for full agent autonomy.
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 has 0% description coverage for 6 parameters. The description only implicitly references file_path, line, column but does not explain language_id, position_pattern, or include_declaration. This leaves a significant gap for agent 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 'Find all references to a symbol' with a specific verb and resource, and distinguishes from siblings like get_cross_repo_references and go_to_definition by focusing on LSP-based reference finding across the codebase.
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 use cases: 'determine if a symbol is dead', 'understand call sites before refactoring', 'trace data flow'. It lacks explicit when-not-to-use guidance, but the scenarios are clear and appropriate.
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 full burden. It describes the mechanism ('workspace symbol search') but does not disclose side effects like whether the tool opens a file or changes cursor position. The behavior is partially 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?
Two sentences, no wasted words. The main purpose is front-loaded, and the description is efficient.
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 3 params, no output schema, and many siblings, the description is adequate but could be more complete. It lacks explanation of all parameters and does not describe the return value or behavior.
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 description coverage is 0%, so the description must compensate. It only implicitly explains the format of 'symbol_path' via examples. The 'language' and 'workspace_root' parameters are not mentioned, leaving gaps.
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 ('Navigate to a symbol definition'), specifies the input format (dot-notation), and distinguishes it from siblings by noting it works without file_path or line/column.
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 explains when to use the tool ('when you know the symbol name but not its location') and mentions the method (workspace symbol search). While it doesn't explicitly state when not to use it, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it returns per-step diagnostics and identifies safe-to-apply-through step, and mentions 1-indexed positions. Without annotations, it carries the burden but doesn't state whether it modifies state or other 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?
Two sentences, each essential: first explains function and output, second gives usage guidance and a critical positional detail. No filler.
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?
Explains purpose and outputs, but lacks details on edit format structure and error handling. With no output schema, description should clarify more about return values and edge cases.
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?
Only the 'edits' parameter gets a hint about 1-indexed positions. No description for session_id or timeout_ms, and edits structure is undocumented despite schema having no descriptions. Schema coverage 0% makes the description insufficient.
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 applies a sequence of edits and evaluates after each step, with a specific use case for finding the safest partial application. This distinguishes it from siblings like apply_edit and simulate_edit_atomic.
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 advises using it to find the safest partial application of a multi-step change, implying when to use. However, it doesn't explicitly contrast with alternatives or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description explains direction parameter behavior and default, but no other behavioral details like side effects, prerequisites, or performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant words, front-loaded with the main action. Highly efficient.
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?
No output schema, but description at least mentions return types (supertypes/subtypes). Lacks error scenarios or prerequisites. Adequate but not thorough for a simple 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 description coverage is 0% and description only explains 'direction' parameter. Does not clarify 'file_path', 'language_id', 'line', 'column', which are typical for positional tools but still undocumented.
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 verb 'Show' and resource 'type hierarchy', differentiating from sibling 'call_hierarchy' by specifying inheritance relationships.
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 use case: 'use this to understand class and interface inheritance relationships.' Lacks explicit when-not-to-use or alternatives 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.
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 details. It mentions resource release and terminal states, but lacks information on side effects, permissions, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, concise, and front-loaded with the core purpose. 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 the simple nature of the tool (one parameter, no output schema, no annotations), the description covers the essential context: when to call it and constraints on session states. Missing details about response format or errors are minor.
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?
The input schema has 0% coverage for parameter descriptions. The description does not add any additional meaning for the 'session_id' parameter beyond what the schema provides (name and type).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Destroy' and the resource 'simulation session', and explicitly mentions 'release all resources'. This distinguishes it from sibling tools like commit_session or discard_session.
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 when to call this tool: 'after commit or discard to clean up', and warns that sessions in terminal states cannot be reused. However, it doesn't explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states that 'The file remains open for continued analysis until explicitly closed' and that 'The LSP server starts automatically on MCP launch.' However, it does not mention idempotency, error handling for missing files, or whether reopening a file is allowed. Partial disclosure but not comprehensive.
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 three sentences, approximately 70 words, with the most important information in the first sentence. No redundant or filler content. Each sentence adds value.
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 annotations and no output schema, the description should cover usage, parameters, and behavior. It covers usage and behavior (file stays open) but does not explain the text parameter, return value, or error conditions. Moderately complete but with notable omissions.
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 0%, so the description must compensate. It explains the language_id parameter with examples ('typescript', 'javascript', 'haskell'), which adds meaning. However, it does not describe the text parameter at all, and file_path is self-explanatory. Partial coverage, leaving one parameter unexplained.
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 ('Open') and resource ('a file in the LSP server for analysis'), and distinguishes the tool from siblings by noting it is a prerequisite for diagnostic, hover, and completion operations. The sibling list includes similar tools like close_document, making the differentiation effective.
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 says 'Use this tool before performing operations like getting diagnostics, hover information, or completions for a file.' This provides clear context for when to use it. It does not mention when not to use or specific alternatives, but the usage guidance is sufficiently clear given the sibling tools.
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 return values and edge case (null if server doesn't support prepareRename). No annotations, so description carries full burden; no missing behavioral traits.
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?
Three sentences, no fluff, efficient. Could be slightly more concise, but remains readable and front-loaded.
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 core purpose and return info for a simple validation tool. Missing parameter details (language_id, coordinate system) but overall adequate given no output schema.
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 0% (no param descriptions in JSON schema). Description does not explain any parameter individually (e.g., format of line/column, purpose of language_id).
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 validates rename feasibility before rename_symbol, distinguishing it from the sibling rename_symbol. Describes return values: range, placeholder, or message.
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 says 'Use this before rename_symbol to avoid attempting invalid renames.' Context is clear, but no exclusions or alternatives provided.
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 that the language server will stop indexing the folder, providing a key behavioral consequence. With no annotations, it partially satisfies transparency, though it could mention side effects or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler, front-loading the action and consequence efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core action and a key behavioral outcome, though parameter documentation is missing.
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?
The sole parameter 'path' is not described beyond its name. With 0% schema coverage, the description fails to add details on format, absolute vs relative, or constraints, leaving the agent to infer.
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 that the tool removes a directory from the LSP workspace and stops indexing, distinguishing it from sibling tools like add_workspace_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by indicating what the tool does, but lacks explicit guidance on when to use it versus alternatives like list_workspace_folders or conditions for removal.
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 that adding a folder triggers automatic re-indexing for supported language servers, and implies it is non-destructive. Missing details on whether the folder must be valid or if it can be removed later, but the core behavior is covered.
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, each adding value: purpose, use case with prerequisite, and automatic re-indexing behavior. Front-loaded with the key verb and resource. No unnecessary 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?
The tool has one parameter, no output schema, and no annotations. The description covers purpose, prerequisite, and a key behavioral trait (auto-reindexing). However, it omits edge cases like duplicate folders or invalid paths, and does not describe the return value or success/failure indicators.
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?
The schema has 0% coverage (no parameter descriptions), so the description should compensate. It only mentions 'a directory' with no additional details about the 'path' parameter format (absolute/relative), validation, or consequences of invalid paths. This leaves the agent guessing.
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 ('Add a directory') and the resource ('LSP workspace'), explaining the benefit of enabling cross-repo references. It distinguishes from sibling tools like 'list_workspace_folders' and 'remove_workspace_folder' by focusing on adding and the cross-repo use case.
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 concrete use case ('working across a library and its consumers') with an example ('get_references on a library function returns call sites in both repos'). It also specifies a prerequisite ('Requires start_lsp to have been called first'). No explicit when-not-to-use or alternatives are given, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behavioral traits: it's speculative (no disk commit), returns a session ID, and captures diagnostics lazily. However, it omits details like whether the session is temporary or how to clean up.
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 front-load the core purpose, then add behavioral detail. No redundant words; each sentence delivers unique value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers purpose and behavior for a simple 2-parameter tool with no output schema. However, missing parameter details reduce completeness; the agent must guess valid inputs.
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 description coverage is 0%, and the description does not explain the parameters 'language' or 'workspace_root' beyond their names. The description adds no semantic meaning, leaving the agent to infer acceptable values.
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 creates a session for simulating edits without disk writes, returns a session ID, and mentions lazy diagnostics. It distinguishes from siblings like simulate_edit and commit_session by focusing on what-if scenarios.
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 says 'Use this to explore what-if scenarios before applying changes,' providing clear context. It does not explicitly state when not to use it or name alternatives, but the sibling list implies other tools for direct application.
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 the full burden. It mentions that the tool triggers a server-side operation and returns a server-defined result or null, but it does not disclose potential side effects, destructiveness, authentication requirements, or error behavior. 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 at two sentences, each serving a clear purpose: the first states the action and links to code actions, the second provides usage context and return information. 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?
Given the tool's complexity (2 params, no output schema), the description covers the essential task, source of commands, and return type. It lacks details on error handling or edge cases, but for a command execution tool, the provided information 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 0%, but the description partially compensates by explaining that the 'command' parameter is a server-defined identifier from code actions. The 'arguments' parameter is not elaborated beyond being optional and an array. Some value is added, but full parameter understanding still requires inference.
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 executes a workspace command via LSP, explicitly linking it to code actions (command field of CodeAction). This distinguishes it from siblings like get_code_actions (which retrieves actions) and apply_edit (which applies edits). The verb 'execute' and resource 'workspace command' are specific.
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 advises 'Use this after get_code_actions' and provides concrete examples of when to use it (refactoring, generating code, server-specific action). It also mentions the return type. However, it does not explicitly state when not to use it or mention alternatives among the many sibling 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?
With no annotations, the description carries the full burden. It discloses that return format depends on server support (hierarchical vs flat) and that outline format reduces tokens. Missing details: whether the tool is read-only, triggers LSP communication, or has 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 two sentences, efficiently covering purpose, return format, usage guidance, and optional format behavior. No filler or redundancy. 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 no output schema and 3 parameters, the description covers the core functionality well. It explains the return format variability and optimizes for LLM usage. Missing: description of language_id, expected side effects, or relationship to sibling tools beyond implicit differentiation.
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 0%, so the description must compensate. It explains the 'format' parameter with a concrete value ('outline') and its benefit, and implies file_path as the document. However, language_id is not mentioned at all, leaving its purpose unclear.
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 gets all symbols defined in a document via LSP, listing specific symbol types. It implicitly distinguishes from workspace-level siblings like get_workspace_symbols by focusing on a single file. The mention of hierarchical vs flat output adds precision.
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 guidance: 'Use this to get a structural overview of a file.' It also promotes the outline format for LLM consumption. However, it does not explicitly exclude use cases like workspace-wide searches or navigation, which are covered by sibling tools.
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?
Though no annotations are provided, the description details the tool's behavior: fetching from toolchain, returning doc text, signature, source tag, and graceful fallback on failure. This is sufficient for an agent to understand the tool's 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 front-loaded, with each sentence adding value: purpose, method, scope, return contents, and fallback behavior. No unnecessary 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?
Given 4 parameters, no annotations, and no output schema, the description covers the overall purpose and return structure but lacks explanation for format and file_path parameters, leaving some ambiguity for an agent.
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?
With 0% schema coverage, the description must explain parameters. It implicitly covers symbol and language_id, but does not describe format or file_path, leaving their meaning and purpose unclear.
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 fetches authoritative documentation for a symbol using local toolchain docs, distinguishing it from LSP-based tools. It specifies supported languages (go, pydoc, cargo doc) and notes it works on transitive dependencies not indexed by the language server.
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 explains when to use this tool (without LSP hover, for transitive dependencies) and mentions graceful fallback, but does not explicitly compare to sibling tools like get_symbol_source or get_document_symbols or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it uses LSP and returns file paths and positions, but it does not disclose behavioral details such as whether the file must be open, if an LSP server is required, or how it handles cases with no implementations. With no annotations provided, the description carries the full burden but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no redundant information. The first sentence states the action and mechanism, the second provides a usage scenario. Every sentence serves a 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 complexity (4 parameters, no output schema, no annotations), the description covers the tool's purpose, usage, and output format. It could be more complete by detailing edge cases or output behavior, but it is sufficient for basic understanding and use.
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 4 parameters with 0% description coverage. The description adds context that the tool uses a location (file_path, line, column) to find implementations, but does not explain the optional language_id parameter or provide syntax details. It adds some value but insufficiently compensates for the missing 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 specifies 'Find all implementations of an interface or abstract method at a specific location in a file via LSP', which is a clear verb+resource combination. It distinguishes from sibling tools like go_to_definition or go_to_declaration by explicitly targeting 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 guidance: 'Use this to navigate from an interface declaration or abstract method to the concrete classes that implement it.' However, it does not mention when not to use it or suggest alternatives like get_references or type_hierarchy.
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 covers language-specific dispatch, return format, and a notable behavioral trait (LSP-normalized failure locations). It does not mention all side effects but is sufficient for a test runner.
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 purpose, followed by key details. No wasted words, though it could be slightly 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 no output schema or annotations, the description covers core functionality, return format, and a useful feature. It could address error cases but is largely complete for a test-running 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 0%, but the description only clarifies 'path' (optional path narrows scope). 'language' and 'workspace_dir' are not explained, leaving the agent to infer their roles from 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?
The description clearly states the tool runs the test suite for the detected workspace language, with specific commands per language. This distinguishes it from siblings like run_build and get_tests_for_file.
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 explains that start_lsp is not required and that an optional path narrows scope, but does not explicitly compare to siblings or 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. It discloses the compound operation, return of evaluation result, 1-indexed positions, and meaning of net_delta:0. However, it omits error handling and 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?
Three sentences front-loaded with purpose. Efficient and no wasted words, though could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no annotations, and no output schema, the description should provide detailed parameter explanations and return value format. It only covers positions and net_delta, leaving major gaps for a complex atomic operation.
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 has 11 parameters with 0% description coverage. Description only clarifies that line/column positions are 1-indexed and mentions return field net_delta. No explanation for other parameters like workspace_root, language, scope, timeout_ms, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool performs an atomic operation: create session, apply edit, evaluate, and destroy. It distinguishes from siblings like simulate_edit and simulate_chain by emphasizing lifecycle management and one-shot nature.
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 what-if checks without managing session lifecycle manually' and 'Requires start_lsp to be called first', providing clear when-to-use and prerequisites.
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?
Despite no annotations, the description reveals key behaviors: with apply=true, it writes to disk and notifies LSP servers; with apply=false, it returns a unified diff patch. It also implies this is a finalizing action. However, it does not mention whether the session is destroyed after commit or any potential side effects like notification to servers.
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 three sentences, front-loaded with the core purpose. Every sentence adds value: purpose, mode details, and usage guidance. 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?
Given no annotations, no output schema, and 0% schema parameter coverage, the description provides essential behavior but omits details on the 'target' parameter and return type. It partially compensates by explaining the two modes and usage sequence, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'apply' parameter well, clarifying its effect on behavior. However, it does not describe the 'target' parameter at all, and 'session_id' is only implicitly understood from context. With 0% schema coverage, more parameter guidance is needed.
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 commits a simulation session, with two distinct behaviors based on the apply parameter. This distinguishes it from siblings like evaluate_session (which confirms safety) and create_simulation_session (which creates the session).
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: 'Use after evaluate_session confirms the changes are safe.' This clarifies the workflow sequence. However, it does not explicitly mention when not to use this tool or provide alternative tools for other scenarios, but the context is sufficient.
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 full burden. It discloses that the tool scans the workspace directory, checks PATH for binaries, and returns a structured result. It does not mention side effects (likely none) or edge cases like missing directories, but for a read-only scan tool this 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?
Two sentences, both substantive. The first sentence packs the core functionality and return values; the second provides a clear usage tip. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description sufficiently explains the return value (languages, servers, suggested_config). It does not cover error handling or what happens if the workspace_dir is invalid, but for a setup tool the description covers the typical use case well.
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 0% and the description does not add any details about the single parameter 'workspace_dir' beyond its name. The parameter is self-explanatory, but the description could clarify expected format (e.g., absolute path) or constraints. This adds no value beyond the schema definition.
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 scans a workspace directory for source languages and checks PATH for LSP server binaries. It specifies the return value: detected languages, installed servers, and a suggested_config. This differentiates it from sibling tools like 'restart_lsp_server' or 'get_server_capabilities'.
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 says 'Use this to set up agent-lsp for a new project or verify your configuration.' It provides clear context for when to use the tool, but does not mention when not to use it or name alternative siblings directly.
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 change types and URI scheme requirement, but lacks details on error handling, side effects, or confirmation. Adequate for a simple notification 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?
Three short sentences, front-loaded with purpose, no filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage context, parameter details. No output schema needed. Could mention that changes array items should be objects with 'uri' and 'type' fields, but the description implies that structure.
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 provides minimal information (array of any items). Description adds critical meaning by explaining the change types and URI scheme, which the schema lacks. Without description, agent would have no clue about expected structure.
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's purpose: notifying the language server of file changes on disk. Specifies the LSP method, and the description differentiates it from sibling tools like open_document or close_document.
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 says when to use: after writing files directly to disk. This guides the agent on the appropriate context, though it doesn't mention 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?
No annotations are provided, so the description carries full behavioral burden. It describes return values and confidence levels (high for file scope, eventual for workspace). However, it does not mention side effects, idempotency, or whether it mutates state, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose and output, second gives usage guidance. Extremely concise, front-loaded, and every word adds value.
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 return values adequately given no output schema. However, parameter details are missing, which is a gap for a tool with 3 parameters and no schema description. It is minimally complete but not thorough.
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 has 3 parameters with 0% description coverage in the schema. The description mentions file vs workspace scope in the context of confidence but does not explicitly document the 'scope' parameter or explain 'session_id' or 'timeout_ms'. Parameter semantics are underdeveloped.
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: evaluating a simulation session by comparing diagnostics against baselines. It lists specific outputs (errors introduced, errors resolved, net delta, confidence) which distinguishes it from siblings like simulate_edit or simulate_chain.
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 when to use: 'Use after simulate_edit to assess impact before committing.' This provides clear context and distinguishes from other tools in the session lifecycle.
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 return types, positions, and the dependency on language server capabilities. Read-only nature is implied. 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?
Three sentences, each adding value: action/resource, return details, usage distinction and availability. No redundant information. Well-structured and 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 6 parameters and no output schema or annotations, the description covers core functionality, return data, and constraints. Could include note on error behavior, but overall provides sufficient context for an 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?
With 0% schema description coverage, the description must explain parameters. It implicitly describes the range parameters (start/end line/column, file_path) and mentions 1-based positions. Missing explanation for 'language_id' parameter, leaving a gap.
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 ('Get semantic tokens') and the resource ('for a range in a file'). It specifies what is returned (token type, modifiers, positions) and distinguishes from hover, making tool 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 advises when to use ('understand syntactic role of code elements') and distinguishes from hover. It also notes the availability constraint (language server support). Could be more explicit about alternatives, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Covers action and optional parameter but lacks disclosure of side effects (e.g., loss of state, need to reinitialize).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action, 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?
Sufficient for a simple tool; covers purpose, use cases, and parameter. Could mention post-restart behavior 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 has no description for root_dir; description explains it changes workspace root, adding necessary meaning 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?
Clearly states 'Restart the LSP server process' with specific use cases (unresponsive, after project changes), distinguishing from sibling tools like start_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 explicit when-to-use scenarios (unresponsive server, significant changes) but does not explicitly mention when not to use or compare with alternatives like start_lsp.
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 burden. It discloses that higher verbosity generates more output, which is useful. However, it does not mention reversibility, persistence, or side effects beyond output volume.
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 three sentences, each serving a purpose: purpose, usage context, and available values. No wasted words; front-loaded with the primary action.
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 tool with one parameter and no output schema, the description covers the core function, parameter values, and a caution about output. No missing critical information 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?
The input schema defines 'level' as a string with 0% description coverage and no enum values. The description compensates by listing all eight valid levels from least to most verbose, adding essential meaning 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: 'Set the server logging level' and explains it controls verbosity. It lists all available levels, leaving no ambiguity. No sibling tools overlap with this function.
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 says to use it to control log verbosity and mentions troubleshooting context and potential large output. It lacks explicit when-not-to-use guidance, but the context is clear and adequate.
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 discloses behavioral traits: changes are in-memory only, baseline diagnostics captured on first edit, version tracking, return of new version number, and 1-indexed positions. This covers key aspects without 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 four sentences and 69 words, efficiently front-loading the main purpose. Every sentence adds value: the primary action, in-memory nature, diagnostics and versioning, return value, and indexing convention. No redundant or unnecessary 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 7 required parameters, no output schema, and no annotations, the description explains the core behavior and return value. It does not cover error conditions or session prerequisites, but the sibling tools (create_simulation_session, commit_session) imply the needed context. Adequate for a tool in a larger suite.
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 0%, so the description must compensate. It provides context like 'range edit' and '1-indexed' but does not individually describe each of the 7 parameters (e.g., session_id, file_path, start_line, etc.). The description adds partial meaning but insufficient for complete clarity without 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 verb 'apply' and the resource 'range edit to a file within a simulation session'. It distinguishes from siblings like 'apply_edit' by emphasizing the simulation session context and in-memory nature. The one-indexing detail further clarifies the tool's behavior.
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 implicitly suggests usage within simulation sessions by mentioning in-memory changes and baseline diagnostics, but it does not explicitly state when to use this tool over alternatives like 'simulate_edit_atomic' or 'apply_edit'. No when-not-to-use or exclusion criteria are provided.
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?
The description discloses that the tool returns TextEdit[] and that edits are not applied automatically. It does not mention prerequisites like document openness or side effects, but given no annotations, it covers key behavioral traits adequately. Lacks details on permissions 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?
The description is three sentences, each adding distinct value: purpose, usage guidance, and behavioral note. No unnecessary words. 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 the tool has 8 parameters and no output schema, the description covers core functionality and usage context well. It lacks parameter documentation and prerequisites, but still provides sufficient context for an agent to understand when and how to invoke it.
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 description coverage is 0% and the description provides no detailed explanation of parameters like file_path, start_line, etc. It only alludes to 'selected lines/characters' without mapping to the schema. With 8 parameters and no other documentation, the description fails to add meaning 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 verb 'Get', the resource 'formatting edits for a specific range', and specifies it's via LSP (textDocument/rangeFormatting). It distinguishes from formatting the entire file by mentioning 'specific range' and implicitly from sibling tools like format_document.
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 says 'Use this when you want to format a function, block, or selection rather than the entire file.' It also notes that edits are NOT applied automatically, guiding the user on the expected workflow. This provides clear context for when to choose this tool over 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?
Describes the read-only behavior of returning symbols with name, kind, location, and enrichment via detail_level. Since no annotations are provided, the description carries full burden; it does not explicitly state read-only nature or potential side effects, but the LSP context implies safety.
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 efficient sentences: first states purpose and base return, second details detail_level behavior, third explains pagination with defaults. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately specifies return fields (name, kind, location) and enrichment results (hover info). Covers pagination behavior. Missing mention of result limits or handling of large sets, but overall sufficient for a search tool.
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?
With 0% schema coverage, the description fully explains all four parameters: detail_level (with valid values 'omit', 'basic', 'hover'), limit (default 3), offset (default 0), and query (search term). It clarifies their effects and pagination 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 'Search for symbols across the entire workspace via LSP' with verb and resource. It distinguishes from sibling tools like get_document_symbols (document-scoped) and go_to_symbol (single symbol) by specifying 'entire workspace' scope and returning multiple symbols with details.
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 guidance on when to use different detail_level values ('omit'/'basic' for names/locations, 'hover' for type signature/docs) and how limit/offset control paginated enrichment. However, it does not contrast with other symbol tools like get_document_symbols for document-specific searches.
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 burden. It details what the tool does (enumerate, resolve, partition) and what it returns. However, it does not discuss performance, side effects, or prerequisites (e.g., LSP running).
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 with no wasted words: first defines core action, second lists returns, third provides use case and parameter guidance. Information is front-loaded and relevant.
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 return structure. It covers purpose, parameters, and usage. Missing are prerequisites (e.g., open workspace) but the sibling context implies LSP environment.
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?
With 0% schema coverage, the description adds meaning: it explains changed_files as 'specified files' and include_transitive as 'second-order callers.' This provides useful context beyond the schema definition.
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 enumerates the tool's actions: it lists exported symbols, resolves references, and partitions callers into test/non-test. It also specifies return fields, 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?
Explicitly suggests 'Use before editing a file to understand blast radius.' It explains the include_transitive parameter but does not explicitly mention when not to use or compare with siblings like get_references.
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 discloses that without a file_path, diagnostics for all open files are returned. This is a key behavioral detail, though it does not cover error handling or return 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 two well-structured sentences. The first states the purpose, the second elaborates on usage. No 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, the description adequately explains the tool's purpose and parameter behavior. It could mention the structure of returned diagnostics, but it is sufficient for selection and basic 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?
Schema description coverage is 0%, but the description compensates by explaining the optional file_path parameter's effect: when omitted, diagnostics for all open files are returned. This adds meaning beyond the plain 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 'Get diagnostic messages' and the resource 'for files'. It distinguishes from sibling tools like get_code_actions or get_completions by focusing specifically on errors and warnings from the language server.
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 explains when to use the tool ('to identify problems in code files') and provides context for parameter usage. However, it does not explicitly mention when not to use it or list alternative tools for related tasks.
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 carries burden. It discloses instant, file-scoped, non-workspace behavior. Lacks mention of document-open requirement or LSP server state, but 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?
Two sentences, no wasted words, front-loaded with purpose and key constraints.
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; description explains return ranges and kinds. Missing prerequisites like document must be open, but covers core behavior well.
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 0%; description adds context ('at a position') but does not explain each parameter (especially language_id). Baseline 3 due to coverage gap, but partial explanation.
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 occurrences of the symbol at a position within the same file' and distinguishes from get_references by noting file-scoped vs workspace-wide.
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 'File-scoped and instant—does not trigger a workspace-wide reference search' and recommends use for local usages without overhead of get_references.
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?
Description discloses the algorithm (calls textDocument/documentSymbol, walks symbol tree, slices file at symbol range) and lists return fields (symbol_name, symbol_kind, start_line, end_line, source text). No annotations are provided, so the description carries full behavioral burden. It could mention error handling (e.g., if no symbol found) but otherwise is 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?
Four sentences front-load the main purpose with no redundancy. Every sentence adds value, explaining mechanism, output, and parameter usage efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of LSP symbol resolution, description explains algorithm and output structure. However, it lacks information on error conditions (e.g., no symbol at position) and does not cover language_id parameter. With no output schema, describing return fields helps but is incomplete without error handling.
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 0%, so description must compensate. It adds meaning by describing line, character, and position_pattern usage, including character default. However, language_id is not mentioned, and its purpose remains unclear. Overall, description adds significant value for position parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns source code of the innermost symbol at a cursor position, specifying the resource (symbol source) and verb (return). It distinguishes from siblings like get_document_symbols (returns all symbols) by focusing on a specific position-driven selection.
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 explains how to specify cursor position using line+character or position_pattern and notes character defaults to 1. It does not explicitly state when not to use or recommend alternatives, but the context implies it is for retrieving source code of a symbol at a location, which is distinct from 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, the description covers key behaviors: language dispatch, no shell execution, optional path narrowing, and return structure. However, potential side effects like build artifact creation are not mentioned.
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 pack purpose, behavior, and output format with no redundancy. Front-loaded and 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 simplicity, the description covers main use, parameters, and return type. Lacks details on language parameter interaction and path format, but still sufficient for a build 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 no descriptions (0% coverage). The description adds meaning to workspace_dir (project directory) and path (scope narrow), and implies language auto-detection. The 'language' parameter is not explicitly explained.
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 compiles the project using language-specific build commands (go build, cargo build, tsc, mypy), distinguishing it from sibling tools like run_tests or start_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?
The description explicitly notes no arbitrary shell execution and that start_lsp is not required, but does not contrast with other build-like tools or specify 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. Clearly explains it returns capability map and classification based on initialization. No side effects mentioned but implied read-only. Sufficiently transparent 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?
Three concise sentences, front-loaded with main action, then usage rationale, then prerequisite. No wasted words.
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 parameters, description completely covers what the tool returns, why to use it, and what condition must be met.
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; schema coverage 100%. Description adds no parameter info but none needed. Baseline for no-parameter tool is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Return' and 'classify' with clear resource 'capability map and tool support status'. Distinguishes from sibling tools by being a meta-tool that checks LSP server capabilities.
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 when to use: to check tool support before calling to save round trips. Provides prerequisite 'Requires start_lsp to have been called first'. Lacks explicit when-not-to-use, but usage 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?
Discloses static nature and absence of test execution. Details language-specific patterns. No annotations provided, so description carries full burden. Does not mention error behavior or return format, but covers core behavior 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?
Four sentences, each purposeful. Front-loaded with core purpose, then details. No redundant or irrelevant content. Efficiently communicates all 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?
Covers input and behavior well with language-specific details. Missing explicit return format description (likely list of file paths), but without an output schema, this is a minor gap. 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'file_path' has no schema description (0% coverage). The description defines it as the source file path, fully compensating for schema gap. Adds clear meaning beyond the type-only 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 the tool finds test files for a given source file path. Specifies static lookup with no test execution. Language-specific patterns differentiate it from siblings like run_tests and detect_lsp_servers.
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 start_lsp is not required. Implies use when static test file discovery is needed, but does not explicitly advise against using when test execution or dynamic analysis is required. Lacks explicit when-not 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?
Without annotations, the description carries the full burden. It accurately describes the tool as a read operation that lists 'currently active' folders. No claims of side effects are made, and the description is consistent with a safe, idempotent query. It could be slightly more explicit about being read-only, but the purpose is clear.
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 only two sentences, both of which add value. The first sentence states the core functionality, and the second provides usage context. No filler or 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 simplicity (no parameters, no output schema, no annotations), the description is fully adequate. It explains what the tool does and why to use it. There is no missing information that would hinder an AI agent from selecting or invoking it 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 has zero parameters, so no parameter documentation is needed. The description adds no parameter info, but that's acceptable since there are none. The schema coverage is 100% by default.
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 ('list'), the resource ('workspace folders'), and a distinguishing attribute ('currently active'). It also explains the purpose ('see which roots the language server is indexing'), which differentiates it from sibling tools like add_workspace_folder or remove_workspace_folder.
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 tells when to use this tool ('to see which roots the language server is indexing'). While it doesn't mention when not to use it or provide direct alternatives, the context of sibling tools implies that this is for inspection, not modification. A slight bonus for clear usage context.
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 the burden. It explains that the tool initializes/reinitializes server state, which is a side effect, but doesn't detail error conditions, rate limits, or what happens on repeated calls. Adequate 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?
Concise, front-loaded with purpose, and each sentence adds useful 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 covers purpose, usage, and parameters well. It could mention return value or error handling, but the tool's role as an initializer makes the description reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description fully compensates. It explains root_dir as workspace root with concrete examples (go.mod, etc.) and language_id as optional for multi-server mode with 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?
The description clearly states it initializes or reinitializes the LSP server with a specific root directory. It also lists dependent tools (get_references, get_info_on_location, get_diagnostics), distinguishing it from sibling tools that perform other operations.
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 when to use it: before certain tools when changing projects. Provides guidance on root_dir and language_id, including when to use the latter (mixed-language repos) and the alternative get_server_capabilities if unsure.
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 fully carries burden. Discloses that edit is not applied automatically, dry_run returns workspace_edit+note, and that position_pattern provides reliable targeting. 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?
Description is appropriately sized for a complex tool, front-loaded with core purpose, then methodically covers usage patterns. 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 8 parameters, no output schema, and no annotations, description covers all major aspects: core purpose, two usage paths (dry_run vs apply), position targeting, and exclusion patterns. Sufficient for agent to use tool correctly.
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?
With 0% schema description coverage, description adds meaning for key parameters: dry_run, position_pattern, exclude_globs. Explains purpose of position_pattern vs line/column, and how exclude_globs works. Provides guidance beyond raw 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 returns a WorkspaceEdit for renaming a symbol across the workspace via LSP. Distinguishes from sibling tools like apply_edit and prepare_rename by specifying it returns an edit object that is not automatically applied.
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 explains when to use dry_run to preview, recommends position_pattern with @@ marker instead of line/column, instructs to inspect the edit then call apply_edit to commit, and describes exclude_globs for skipping generated files.
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:

[![agent-lsp MCP server](https://glama.ai/mcp/servers/blackwell-systems/agent-lsp/badges/card.svg)](https://glama.ai/mcp/servers/blackwell-systems/agent-lsp)

Score Badge

Copy to your README.md:

[![agent-lsp MCP server](https://glama.ai/mcp/servers/blackwell-systems/agent-lsp/badges/score.svg)](https://glama.ai/mcp/servers/blackwell-systems/agent-lsp)

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/blackwell-systems/agent-lsp'

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