lsp-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes targeting specific LSP operations like definitions, references, or completions. However, lsp_smart_search overlaps with multiple individual tools (definition, references, implementations, type info, call hierarchy), which could cause confusion about when to use it versus the specialized tools. The descriptions help clarify, but the redundancy creates some ambiguity.
Naming Consistency5/5
All tools follow a consistent 'lsp_' prefix with snake_case naming, using clear verbs like 'get', 'find', 'goto', 'rename', etc. The pattern is predictable throughout, making it easy to understand each tool's function at a glance without stylistic deviations.
Tool Count4/5
With 19 tools, the count is on the higher side but reasonable for a comprehensive LSP server covering diagnostics, navigation, refactoring, and server management. It might feel slightly heavy, but each tool serves a distinct LSP feature, justifying its inclusion for a broad domain like language server protocol operations.
Completeness5/5
The tool set provides complete coverage for LSP interactions, including core operations (definition, references, completions, hover), advanced features (call/type hierarchy, implementations), refactoring (rename, code actions), diagnostics, formatting, and server management (start/stop/status). There are no obvious gaps, enabling agents to handle typical code analysis and editing workflows effectively.
Average 3.9/5 across 19 of 19 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 3 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe operation), openWorldHint=false (requires specific parameters), and idempotentHint=true (repeatable). The description adds minimal behavioral context beyond this - it implies this is a query operation but doesn't mention what kind of suggestions are returned, whether they're filtered by context, or any rate limits. No contradiction with annotations exists.
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 perfectly concise - a single sentence that states exactly what the tool does without any wasted words. It's front-loaded with the core purpose and doesn't include unnecessary elaboration or examples that would dilute the message.
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 annotations provide good safety/behavioral information and the schema has 100% coverage, the description is minimally adequate. However, without an output schema, the description doesn't explain what 'suggestions' actually look like (completion items with labels/types/details), leaving the agent uncertain about the return format. For a tool with 4 parameters and no output schema, more context about the response would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, all parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema - it doesn't explain how the position parameters interact, what 'suggestions' actually contain, or how the limit parameter affects results. The baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('Get code completion suggestions') and the resource ('at the given position'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'lsp_signature_help' or 'lsp_hover' which also provide language intelligence at positions, leaving some ambiguity about when to choose completions over other LSP features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With 16 sibling LSP tools available, there's no mention of when completions are appropriate (e.g., during typing) versus when to use 'lsp_goto_definition' or 'lsp_find_references', nor any prerequisites like requiring the server to be started first.
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?
Annotations already cover key behavioral traits: readOnlyHint=true (safe read), openWorldHint=false (limited scope), and idempotentHint=true (repeatable). The description adds minimal context by implying it returns all symbols from a single document, but doesn't disclose details like response format, pagination, or error handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and every part contributes to understanding what the tool does.
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 moderate complexity (LSP-based symbol retrieval), annotations provide good safety and idempotency info, but there's no output schema. The description is minimal and doesn't explain return values or error cases, leaving gaps for an agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'file_path' well-documented in the schema. The description doesn't add any meaning beyond the schema, such as file format requirements or path validation rules, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'all symbols (functions, classes, variables, etc.) defined in a document', which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'lsp_workspace_symbols' (which likely searches across multiple files), leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'lsp_workspace_symbols' for broader searches or 'lsp_goto_definition' for specific symbol navigation, nor does it specify prerequisites such as requiring an active LSP server.
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?
Annotations provide readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds no behavioral context beyond this, such as performance characteristics, rate limits, or what 'implementations' entails (e.g., across workspace or project). It does not contradict annotations, but offers minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (code analysis with positional parameters) and lack of output schema, the description is minimal but adequate with annotations covering key behavioral traits. However, it could benefit from more context on usage scenarios or result format to better guide an agent without output schema information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for all parameters (file_path, line, column, limit). The description does not add meaning beyond the schema, such as explaining how the tool uses the position parameters to identify the interface/method or default behavior for limit. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Find all implementations of an interface or abstract method,' which is a specific verb+resource combination. However, it does not explicitly differentiate from siblings like 'lsp_goto_definition' or 'lsp_find_references,' which may have overlapping functionality in code navigation contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context about prerequisites (e.g., requiring an active LSP server) or comparisons to sibling tools like 'lsp_type_hierarchy' or 'lsp_call_hierarchy,' which might serve similar purposes in different scenarios.
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?
Annotations already indicate read-only, non-open-world, and idempotent behavior. The description adds that it searches 'by name' and implies fuzzy matching (via the schema), but doesn't disclose additional traits like performance characteristics, error handling, or result format. It doesn't contradict annotations, so it meets the lower bar with some added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Search for symbols') and key scope ('across the entire workspace'). There is no wasted verbiage, and every word contributes to understanding the tool's function.
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 moderate complexity (search with filtering), rich annotations (safety and behavior hints), and full schema coverage, the description is adequate but minimal. It lacks output details (no schema provided) and doesn't explain result structure or usage scenarios, making it complete enough for basic use but with gaps for optimal agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters like 'query' (fuzzy matching), 'kinds' (filtering), and 'limit' (default 50). The description adds no extra parameter semantics beyond implying a name-based search, aligning with the baseline for high schema coverage.
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 action ('Search for symbols') and scope ('across the entire workspace by name'), which distinguishes it from sibling tools like lsp_document_symbols (likely limited to a single document). However, it doesn't explicitly contrast with all siblings (e.g., lsp_smart_search might also search symbols), making it very good but not perfect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like lsp_document_symbols or lsp_smart_search. It mentions the scope ('entire workspace') but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer context from tool names alone.
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?
Annotations provide readOnlyHint=false, idempotentHint=true, and openWorldHint=false, indicating this is a mutating but safe operation. The description adds valuable context about respecting project-specific formatting settings, which isn't covered by annotations. It doesn't contradict annotations, as 'format' implies mutation consistent with readOnlyHint=false.
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 concise sentences with zero wasted words. The first sentence states the core purpose, and the second adds important behavioral context. It's appropriately sized and front-loaded with essential 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 the tool's moderate complexity (formatting with project settings), rich annotations, and full schema coverage, the description is adequate but has gaps. It lacks output information (no schema provided), doesn't explain error conditions, and doesn't detail how 'apply' parameter affects behavior beyond the schema's basic description.
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 100% schema description coverage, the input schema fully documents all parameters. The description adds no additional parameter semantics beyond what's in the schema, such as explaining how 'project-specific formatting settings' interact with parameters like tab_size. This meets the baseline score of 3 for high schema coverage.
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 action ('Format a document') and mechanism ('using the language server's formatting capabilities'), distinguishing it from other LSP tools that perform different operations like completions or diagnostics. However, it doesn't explicitly differentiate from hypothetical formatting alternatives beyond mentioning 'project-specific formatting settings.'
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 context through 'Respects project-specific formatting settings,' suggesting this tool should be used when consistent project formatting is desired. However, it provides no explicit guidance on when to choose this tool versus other LSP tools or when not to use it (e.g., for non-source files).
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?
Annotations already provide readOnlyHint=true, openWorldHint=false, and idempotentHint=true, indicating a safe, deterministic read operation. The description adds value by specifying the type of information returned ('type info, documentation'), which isn't covered by annotations, but doesn't detail rate limits, auth needs, or output format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose ('Get hover information') and includes key details without waste. Every word contributes to understanding the tool's function.
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 moderate complexity (3 parameters, no output schema), the description is adequate but lacks details on return values, error handling, or dependencies on server status. Annotations cover safety, but without output schema, the description could better explain what 'hover information' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for file_path, line, and column. The description adds minimal semantic context by linking parameters to 'given position' but doesn't provide additional details beyond what the schema already covers, such as format specifics or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'hover information' with specific content types ('type info, documentation') and target ('symbol at the given position'). It distinguishes from siblings like lsp_goto_definition or lsp_find_references by focusing on hover details rather than navigation or references, though it doesn't explicitly name alternatives.
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 when hover information is needed for a symbol at a position, but it doesn't explicitly state when to use this tool versus alternatives like lsp_signature_help or lsp_completions, nor does it provide exclusions or prerequisites. Context is clear but lacks explicit 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?
Annotations provide idempotentHint=true and readOnlyHint=false, indicating a non-destructive, repeatable operation. The description adds value by specifying 'Manually start,' which implies user-initiated action rather than automatic, and clarifies the target ('language server for a specific workspace'), enhancing context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and target. It wastes no words and is appropriately sized for the tool's complexity, earning full marks for conciseness.
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 moderate complexity (2 required parameters, no output schema), the description is adequate but minimal. It covers the basic purpose but lacks details on outcomes (e.g., what happens after starting, error conditions) or integration with siblings, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for both parameters. The description doesn't add any additional meaning or examples beyond what the schema provides, such as explaining typical server IDs or workspace root formats, so it meets the baseline for high schema coverage.
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 action ('Manually start') and resource ('a language server for a specific workspace'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'lsp_server_status' or 'lsp_stop_server', which prevents a perfect score.
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 when manual server initiation is needed, but lacks explicit guidance on when to use this tool versus alternatives (e.g., 'lsp_server_status' for checking status or 'lsp_stop_server' for stopping). No exclusions or prerequisites are mentioned, leaving usage context somewhat vague.
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?
Annotations already provide readOnlyHint=true, openWorldHint=false, and idempotentHint=true, indicating a safe, deterministic read operation. The description adds value by explaining the tool's purpose (navigating to type definitions) and use case, but does not disclose additional behavioral traits like error handling, performance, or specific constraints beyond what annotations cover.
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 action and followed by a useful context sentence. Every word earns its place without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (navigation with three parameters), rich annotations (read-only, deterministic), and no output schema, the description is mostly complete. It explains the tool's purpose and use case but could benefit from more explicit usage guidelines or behavioral details to fully compensate for the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for file_path, line, and column. The description does not add meaning beyond the schema, as it focuses on tool purpose rather than parameter details. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Navigate to the type definition') and resource ('of a symbol'), distinguishing it from siblings like lsp_goto_definition (general definition) and lsp_find_implementations (implementations). It adds context about finding 'the class/interface that defines a variable's type,' making the purpose explicit and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('Useful for finding the class/interface that defines a variable's type') but does not explicitly state when to use this tool versus alternatives like lsp_goto_definition or lsp_find_implementations. It provides some context but lacks clear exclusions or named 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?
Annotations provide readOnlyHint=false, openWorldHint=false, and idempotentHint=false, indicating this is a mutable, non-idempotent operation. The description adds useful context about what types of actions are available (refactorings, quick fixes) and their purposes, but doesn't elaborate on behavioral aspects like side effects, error conditions, or performance characteristics beyond what annotations already convey.
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 zero waste. The first sentence states the purpose and core functionality, the second provides usage context. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no output schema, and annotations covering basic behavioral hints, the description provides good context about what code actions are and when to use them. However, it doesn't explain what the return format looks like or how to interpret the results, which would be helpful given the lack of output schema.
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 100% schema description coverage, the input schema already documents all 8 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage.
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 specific verb 'Get' and resource 'available code actions' with explicit examples like 'refactorings, quick fixes'. It distinguishes from siblings by focusing on code actions rather than completions, diagnostics, or other LSP operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('for automated fixes, imports organization, and refactoring operations'), but doesn't explicitly state when NOT to use it or name specific alternatives among 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?
Annotations provide readOnlyHint=true, openWorldHint=false, and idempotentHint=true, indicating safe, deterministic reads. The description adds valuable context beyond this: it specifies that diagnostics are 'cached' (implying they may not be real-time) and come from 'language server notifications' (clarifying the source). This enhances transparency without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by clarifying context. Every word earns its place, with no redundancy or unnecessary elaboration, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema), annotations cover safety and determinism, and the description adds caching and source context. However, it lacks details on return format (e.g., structure of diagnostics) or error handling, leaving minor gaps for a tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter documentation. The description adds minimal semantics beyond the schema, mentioning 'errors, warnings' which aligns with severity_filter but doesn't provide additional details like format or examples. Baseline 3 is appropriate since the schema already fully describes parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get cached diagnostics') and resource ('for a file'), specifying that diagnostics include errors and warnings from language server notifications. It distinguishes from siblings like lsp_code_actions or lsp_format_document by focusing on diagnostic retrieval rather than code fixes or formatting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for accessing diagnostics but doesn't explicitly state when to use this tool versus alternatives like lsp_hover or lsp_completions. It mentions diagnostics come from language server notifications, suggesting it's for post-analysis retrieval, but lacks clear exclusions or comparative guidance with 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?
Annotations already provide readOnlyHint=true, openWorldHint=false, and idempotentHint=true. The description adds valuable context about workspace-wide scope and position-based targeting, which isn't covered by annotations. It doesn't contradict annotations (read-only operation aligns with 'find'), but could mention performance implications or result 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?
Single sentence, front-loaded with core purpose, zero wasted words. Every element ('find all references', 'to the symbol', 'at the given position', 'across the workspace') contributes essential information 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 read-only query tool with good annotations and full schema coverage, the description provides adequate context about what it does and scope. However, without an output schema, it doesn't describe result format (e.g., list of locations with metadata), which could help the agent interpret returns. Sibling context is partially addressed through 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 description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides (e.g., it doesn't explain how position parameters interact or clarify workspace boundaries). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'find' and the resource 'references to the symbol', specifying the scope 'across the workspace' and the location constraint 'at the given position'. It distinguishes from siblings like lsp_goto_definition (single definition) and lsp_workspace_symbols (symbol search without position).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing all references to a specific symbol, but doesn't explicitly state when to use alternatives like lsp_find_implementations (for interfaces) or lsp_smart_search (broader search). No exclusions or prerequisites are mentioned, leaving some ambiguity about tool selection.
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?
Annotations already indicate readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds value by specifying the return format ('file path, line, and column of the definition'), which is not covered by annotations, though it lacks details on error handling or server requirements.
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 concise sentences with zero waste: the first states the purpose, and the second specifies the return values, making it front-loaded and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations (readOnlyHint, idempotentHint), and full schema coverage, the description is mostly complete. However, it lacks output schema details (e.g., exact return structure) and does not address potential errors or server dependencies, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the parameters (file_path, line, column). The description does not add any additional meaning beyond what the schema provides, such as clarifying the symbol selection logic or position validation.
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 specific action ('Navigate to the definition') and resource ('symbol at the given position'), distinguishing it from siblings like lsp_goto_type_definition or lsp_find_references by focusing on symbol definitions rather than type definitions or references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for navigating to symbol definitions, but does not explicitly state when to use this tool versus alternatives like lsp_goto_type_definition or lsp_find_references, nor does it mention prerequisites such as needing an active LSP server.
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?
Annotations already provide readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds context about checking 'running' servers, which implies it may not work if servers are stopped, but it does not disclose additional behavioral traits like error handling, rate limits, or response format. With annotations covering key aspects, a 3 is appropriate as the description adds some value 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 a single, efficient sentence that front-loads the core purpose ('Get status of running language servers') with zero wasted words. It is appropriately sized for the tool's simplicity and earns its place by clearly stating the action and target.
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 low complexity (1 optional parameter, no output schema) and rich annotations (readOnlyHint, idempotentHint), the description is mostly complete. It covers the purpose and implies scope ('running servers'), but could benefit from slight elaboration on output or error cases. However, with annotations handling safety and idempotency, it is sufficient for effective 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?
Schema description coverage is 100%, with the parameter 'server_id' fully documented in the schema. The description does not add any parameter-specific details beyond what the schema provides, such as examples or usage nuances. Baseline 3 is correct when the schema handles all parameter documentation.
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 specific action ('Get status') and target resource ('running language servers'), distinguishing it from sibling tools that perform language server operations like completions, diagnostics, or server control (start/stop). It precisely communicates what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking server status, which is clear in context, but it does not explicitly state when to use this tool versus alternatives (e.g., when to check status vs. using other LSP tools). It provides basic guidance but lacks explicit exclusions or named alternatives, keeping it at a 4.
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?
Annotations already provide key behavioral hints: readOnlyHint=true (safe read operation), openWorldHint=false (limited scope), and idempotentHint=true (repeatable). The description adds context about the tool's purpose (inheritance analysis) and use cases (refactoring planning), but does not disclose additional behavioral traits like performance characteristics, error conditions, or data format of the hierarchy output. With annotations covering safety and idempotency, the description adds moderate value.
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 appropriately sized and front-loaded: the first sentence states the core purpose, and the second sentence adds usage context. Every sentence earns its place with no redundant or vague language, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (inheritance analysis), rich annotations (readOnlyHint, idempotentHint), and full schema coverage, the description is mostly complete. It covers purpose and usage well but lacks details on output format (no output schema provided) and potential limitations (e.g., language-specific constraints). This minor gap prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents all parameters (file_path, line, column, direction). The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining how the hierarchy is derived from the source location or format details. Baseline 3 is appropriate when the schema does the heavy lifting.
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 with specific verbs ('Get the type hierarchy') and resources ('class/interface'), distinguishing it from siblings like lsp_find_implementations or lsp_goto_type_definition by focusing on inheritance relationships rather than single-direction lookups or definitions. It explicitly mentions what the hierarchy includes: 'supertypes (parents, interfaces) and subtypes (children, 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 context for when to use the tool: 'for understanding inheritance and planning refactoring that affects class hierarchies.' However, it does not explicitly state when not to use it or name specific alternatives among siblings (e.g., lsp_find_implementations for subtypes only), which prevents a perfect score.
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?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds valuable context beyond this by explaining the tool's purpose for 'code flow and impact analysis before refactoring,' which helps the agent understand its behavioral use case, though it doesn't detail rate limits or specific output formats.
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 appropriately sized and front-loaded, with two sentences that efficiently convey purpose and usage without waste. Every sentence adds value: the first defines the tool's function, and the second explains its importance, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, rich annotations, and 100% schema coverage, the description is mostly complete. It lacks details on output format or pagination, which is a minor gap since there's no output schema, but it sufficiently covers purpose and context for effective use by 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?
Schema description coverage is 100%, with clear documentation for all parameters including file_path, line, column, and direction with enum values. The description does not add any additional meaning beyond what the schema provides, such as explaining parameter interactions or edge cases, so it meets the baseline for high schema coverage.
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 with specific verbs ('Get the call hierarchy') and resources ('function/method'), distinguishing it from siblings like lsp_find_references or lsp_type_hierarchy by focusing on call relationships rather than references or type hierarchies. It explicitly mentions both incoming and outgoing directions.
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 for usage ('Essential for understanding code flow and impact analysis before refactoring'), indicating when this tool is valuable. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as lsp_find_references for different analysis needs.
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?
Annotations indicate readOnlyHint=false (mutation), idempotentHint=true (safe to retry), and destructiveHint=false (non-destructive). The description adds valuable context beyond this: it explains the dry-run default behavior (preview vs. apply changes), which isn't captured in annotations. It doesn't contradict annotations, as 'rename' aligns with readOnlyHint=false.
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 followed by a key behavioral detail (dry-run default). Every word earns its place, with no redundancy or fluff, making it highly efficient and easy to parse.
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 (mutation with workspace-wide impact), annotations cover safety aspects (idempotent, non-destructive), and the description adds crucial behavioral context (dry-run default). However, without an output schema, it doesn't describe return values (e.g., preview changes format), leaving a minor gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the input schema. The description adds minimal semantics beyond the schema, only implying that parameters like file_path, line, and column identify the symbol to rename. Since the schema does the heavy lifting, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('rename') and resource ('a symbol across the workspace'), specifying the scope of the operation. It distinguishes from siblings like lsp_find_references (which finds but doesn't rename) and lsp_document_symbols (which lists symbols).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by mentioning 'across the workspace' and the dry-run default behavior, which helps understand when to use it. However, it doesn't explicitly state when to choose this over alternatives like lsp_code_actions (which might include rename) or when not to use it (e.g., for local vs. global renames).
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 adds valuable behavioral context beyond annotations: it specifies the tool stops a 'running' server, implying it only works on active instances. Annotations provide idempotentHint=true (safe to retry) and readOnlyHint=false (mutating), but the description clarifies the precondition and scope of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately understandable without unnecessary elaboration.
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 mutating tool with no output schema, the description adequately covers the purpose and basic behavior. However, it could benefit from mentioning potential side effects (e.g., stopping server terminates ongoing operations) or error conditions, though annotations help with idempotency context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents both parameters. The description doesn't add any parameter-specific details beyond what's in the schema, so it meets the baseline expectation without enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Stop') and target ('a running language server'), distinguishing it from all sibling tools which perform various LSP operations but not server lifecycle management. It precisely communicates the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when a server is running), but doesn't explicitly state when to use it versus alternatives like lsp_server_status for checking status or lsp_start_server for starting. It provides clear operational intent but lacks explicit comparison with 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?
Annotations already provide readOnlyHint=true, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds valuable context by specifying that it retrieves signature information specifically for call expressions, which is not captured in annotations. However, it doesn't mention potential limitations like server availability or response format 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 a single, efficient sentence that front-loads the core purpose ('Get function/method signature information') and immediately specifies the usage context. There is no wasted verbiage, and every word contributes directly to understanding the tool's function.
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 annotations cover safety and idempotency, and the schema fully documents parameters, the description provides adequate context for a read-only diagnostic tool. However, without an output schema, it doesn't detail the return format (e.g., structured signature data), leaving a minor gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for file_path, line, and column parameters. The description doesn't add any additional semantic information beyond what the schema provides, such as explaining how these parameters pinpoint the call expression location. This meets the baseline for high schema coverage.
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 specific action ('Get function/method signature information') and the precise context ('when inside a call expression'), distinguishing it from siblings like lsp_hover (general documentation) or lsp_completions (code suggestions). It uses concrete verbs and specifies the exact resource being retrieved.
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 states when to use this tool: 'when inside a call expression.' This provides clear context for invocation and implicitly excludes usage in other scenarios (e.g., for general documentation or code navigation), helping differentiate it from alternatives like lsp_hover or lsp_goto_definition.
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 adds valuable behavioral context beyond annotations. While annotations indicate read-only, non-open-world, and idempotent operations, the description explains this is a 'comprehensive symbol search combining multiple LSP operations in one call' and that it's 'more efficient than calling multiple individual tools.' This provides important context about performance characteristics and composite behavior that annotations don't cover.
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 perfectly concise with two sentences that each earn their place. The first sentence defines the tool's comprehensive nature and lists specific operations. The second sentence provides crucial usage guidance about efficiency compared to alternatives. No wasted words, front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (combining multiple LSP operations), rich annotations, and 100% schema coverage, the description provides good contextual completeness. It explains the composite nature and efficiency benefits. The main gap is lack of output schema documentation, but the description compensates somewhat by listing what information will be returned (definition, references, implementations, etc.).
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 100% schema description coverage, the baseline is 3. The description doesn't add specific parameter semantics beyond what's already documented in the schema. It mentions the tool combines multiple LSP operations, which aligns with the 'include' parameter's enum values, but doesn't provide additional guidance about parameter usage or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'comprehensive symbol search combining multiple LSP operations' and lists specific operations (definition, references, implementations, type info, call hierarchy). It explicitly distinguishes from siblings by stating it's 'more efficient than calling multiple individual tools' and names specific sibling operations it replaces.
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 provides explicit guidance on when to use this tool versus alternatives: 'More efficient than calling multiple individual tools' indicates this should be used when needing multiple LSP operations simultaneously rather than calling separate tools like lsp_goto_definition, lsp_find_references, etc. This directly addresses when to choose this tool over its many siblings.
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:

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

Score Badge

Copy to your README.md:

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

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/ProfessioneIT/lsp-mcp-server'

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