Exposes Svelte Language Server (LSP) capabilities as MCP tools, enabling symbol navigation, diagnostics, code formatting, refactoring, and IntelliSense for Svelte projects, as well as Svelte-specific utilities like component reference tracking and code compilation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SvelteLS.MCP find all references to the UserProfile component"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that wraps the Svelte Language Server, exposing its LSP capabilities as MCP tools for Claude Code.
Claude Code <--MCP/stdio--> SvelteLS.MCP <--LSP/stdio--> svelteserverRelated MCP server: vscode-mcp
npm install
npm run buildnode dist/index.js [path-to-svelte-project]The project path is optional. If omitted, use the load_project tool at runtime to set it.
{
"mcpServers": {
"svelte-ls": {
"command": "cmd",
"args": ["/c", "node", "F:\\Shared\\SvelteLS.MCP\\dist\\index.js", "F:\\path\\to\\svelte\\project"]
}
}
}{
"mcpServers": {
"svelte-ls": {
"command": "node",
"args": ["/path/to/SvelteLS.MCP/dist/index.js", "/path/to/svelte/project"]
}
}
}find_definition - Go to definition of a symbol
find_references - Find all references to a symbol
get_hover - Get hover documentation and type info
go_to_implementation - Find implementations of an interface/abstract method
go_to_type_definition - Jump to the type definition of a symbol
find_document_symbols - List all symbols in a file
find_workspace_symbols - Search symbols across the workspace
get_diagnostics - Get errors, warnings, and diagnostics for a file
rename_symbol - Rename a symbol across the workspace
format_document - Format a file or line range
get_code_actions - List available quick fixes and refactorings
apply_code_action - Apply a code action by title
get_completion - Get completion suggestions at a position
get_signature_help - Get method signature overloads and parameter info
incoming_calls - Find all callers of a function/method
outgoing_calls - Find all calls from a function/method
load_project - Load a Svelte project by its root directory
restart_lsp - Restart the Svelte language server
get_compiled_code - Get compiled JS/CSS output for a Svelte component
get_component_references - Find all usages of a Svelte component
get_file_references - Find all files that import a given file
SVELTELS_TIMEOUT - LSP request timeout in ms (default: 30000)
SVELTELS_SERVER_PATH - Override path to the svelteserver entry script
Apply a code action (quick fix, refactoring) by its title. Use get_code_actions first to see available actions.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file | |
| startLine | Yes | Start line (1-based) | |
| actionTitle | Yes | Title of the code action to apply (case-insensitive partial match) | |
| endLine | No | End line (1-based) | |
| kind | No | Filter by kind: quickfix, refactor, etc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions applying 'quick fix, refactoring' which implies mutation, but doesn't disclose critical behavioral traits: whether changes are reversible, what permissions are needed, if it modifies files in-place, what happens on failure, or what the response contains. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste. The first sentence states the core purpose, the second provides crucial workflow guidance. Every word earns its place, and information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description should do more. While it provides good purpose clarity and excellent usage guidelines, it lacks behavioral transparency about the mutation effects, error handling, and response format. The 100% schema coverage helps, but for a tool that modifies code, more context about the operation's nature and consequences is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond the schema - it mentions applying by title (implied by actionTitle parameter) and references get_code_actions for discovery. No additional parameter semantics are provided beyond what's in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('apply') and resource ('code action'), specifying it works by title. It distinguishes from get_code_actions by indicating that tool should be used first to see available actions. However, it doesn't explicitly differentiate from other sibling tools like rename_symbol or format_document that might also modify code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use get_code_actions first to see available actions.' This clearly indicates when to use this tool (after discovering actions) and references the alternative tool for discovery. It establishes a clear workflow dependency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the definition of a symbol by name in a file.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file | |
| symbolName | Yes | Name of the symbol to find | |
| symbolKind | No | Kind of symbol: class, method, property, field, interface, enum, function, variable, etc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what the tool does but lacks behavioral details: it doesn't specify if it requires a loaded project, what happens if the symbol isn't found, whether it returns a location or full definition, or any error conditions. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's complexity, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., definition text, location), behavioral traits like error handling, or how it differs from siblings. For a 3-parameter tool in a code analysis context, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description implies parameters (symbol name and file) but adds no meaning beyond the schema, such as format examples or constraints. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'find' and resource 'definition of a symbol by name in a file', making the purpose specific and understandable. It doesn't explicitly differentiate from siblings like 'find_references' or 'find_document_symbols', which would require more detail about scope or output differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'find_references' and 'find_workspace_symbols', it's unclear if this is for local file definitions only or how it differs in context. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all symbols defined in a file.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'List all symbols' but doesn't specify what constitutes a 'symbol' (e.g., functions, variables, classes), the format or structure of the output, whether it's paginated, or any error conditions (e.g., invalid file paths). This leaves significant gaps for a tool that likely interacts with code analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It front-loads the core action ('List all symbols') and resource ('in a file'), making it easy to parse quickly. Every part of the sentence earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of code analysis tools and the lack of annotations or output schema, the description is incomplete. It doesn't explain what 'symbols' include, the output format, or error handling, which are critical for an AI agent to use this tool effectively. The schema covers the input, but behavioral and output details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'filePath' clearly documented as an 'Absolute path to the file'. The description adds no additional meaning beyond this, such as examples of valid paths or file type constraints. This meets the baseline of 3 since the schema adequately covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all symbols defined in a file', which is specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'find_workspace_symbols' (which likely searches across multiple files) or 'find_definition' (which likely finds a specific symbol's definition), leaving some ambiguity about when this exact tool is preferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'find_workspace_symbols' (for broader searches) and 'find_definition' (for specific symbols), the agent must infer usage based on the name alone. No explicit context, 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.
Find all references to a symbol across the workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file | |
| symbolName | Yes | Name of the symbol to find | |
| symbolKind | No | Kind of symbol | |
| includeDeclaration | No | Include the declaration itself |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool finds references but doesn't describe what constitutes a 'reference' (e.g., usage sites, imports), whether it's read-only (implied but not explicit), performance characteristics like speed or workspace scope, or output format. This leaves significant gaps for an agent to understand its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a reference-finding tool with no annotations and no output schema, the description is insufficient. It doesn't explain the return values (e.g., list of locations), behavioral traits like workspace traversal, or how it interacts with sibling tools. This leaves the agent with incomplete context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond implying a search operation, which aligns with the schema. This meets the baseline for high schema coverage, where the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Find all references') and resource ('to a symbol across the workspace'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_file_references' or 'get_component_references', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'find_definition', 'get_file_references', or 'get_component_references'. It lacks context about prerequisites, such as needing a loaded project via 'load_project', or exclusions like not working on unsaved files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for symbols across the entire workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for the symbol name | |
| pathFilter | No | Optional path filter (case-insensitive substring match) | |
| filter | No | Optional regex filter on symbol names | |
| limit | No | Max results to return. Default: 50 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action without details on permissions, rate limits, error handling, or output format. It doesn't clarify what 'symbols' entail (e.g., functions, variables) or how results are structured, which is insufficient for a tool with potential complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, 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.
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, the description is incomplete for a search tool with four parameters. It doesn't explain what 'symbols' are, how results are returned, or any behavioral traits like pagination or error cases, leaving significant gaps for the agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what's already in the schema, which has 100% coverage with clear descriptions for all four parameters. This meets the baseline score of 3, as the schema adequately documents the parameters without needing extra explanation in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search for symbols') and scope ('across the entire workspace'), which is specific and distinguishes it from sibling tools like 'find_document_symbols' that might search within a single document. However, it doesn't explicitly differentiate from other symbol-related tools like 'find_definition' or 'find_references', keeping it from 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.
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 'find_document_symbols' or 'find_definition'. It lacks any mention of prerequisites, exclusions, or specific contexts where this tool is preferred, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Format a file (or a range of lines) using the project's formatting rules.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file | |
| startLine | No | Optional start line (1-based) for range formatting | |
| endLine | No | Optional end line (1-based) for range formatting | |
| tabSize | No | Tab size. Default: 2 | |
| insertSpaces | No | Use spaces instead of tabs. Default: true |
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 states the tool formats using project rules but lacks details on behavioral traits like whether it modifies the file in-place, requires specific permissions, has side effects, or handles errors. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Format a file or a range of lines') and adds necessary context ('using the project's formatting rules'). There is zero waste, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a file formatting tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, how errors are handled, or the implications of using project rules. For a mutation operation, more behavioral context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying formatting applies to a file or line range, which is already covered by the schema. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Format') and resource ('a file or a range of lines'), specifying it uses 'the project's formatting rules.' It distinguishes from siblings like 'apply_code_action' or 'rename_symbol' by focusing on formatting, but doesn't explicitly contrast with them, keeping it at 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing the file to be open or part of a loaded project, or when to choose range formatting over full-file formatting. This leaves the agent without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available code actions (quick fixes, refactorings) for a line or range in a file.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file | |
| startLine | Yes | Start line (1-based) | |
| endLine | No | End line (1-based). Defaults to startLine | |
| kind | No | Filter by kind: quickfix, refactor, refactor.extract, refactor.inline, refactor.rewrite, source, source.organizeImports, source.fixAll |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the action as listing code actions, implying a read-only operation, but doesn't specify whether it requires file access permissions, how results are structured (e.g., pagination), or potential errors (e.g., invalid file paths). For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core purpose and uses parentheses to clarify 'code actions' without redundancy. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 4 parameters and behavioral complexity. It lacks details on return values (e.g., format of listed actions), error handling, or operational constraints (e.g., file system access). This leaves significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (filePath, startLine, endLine, kind) with clear descriptions. The description adds no additional parameter semantics beyond implying a line/range context, which is already covered by the schema. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List available code actions (quick fixes, refactorings) for a line or range in a file.' It specifies the verb ('List'), resource ('code actions'), and scope ('for a line or range in a file'), distinguishing it from siblings like apply_code_action or get_diagnostics. However, it doesn't explicitly differentiate from all siblings (e.g., find_definition), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or compare it to sibling tools like apply_code_action (which applies actions) or get_diagnostics (which might list issues). This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the compiled JavaScript and CSS output for a Svelte component. Useful for debugging compilation issues.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the .svelte file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is 'Useful for debugging compilation issues,' which hints at a read-only, diagnostic purpose, but it doesn't explicitly state whether this is a safe read operation, what permissions are needed, or details about the output format (e.g., structure, potential errors). For a tool with zero annotation coverage, this is insufficient to fully inform an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence clearly states the purpose, and the second sentence adds useful context without redundancy. There is zero waste, making it efficient and easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is partially complete. It covers the purpose and usage context but lacks details on behavioral traits (e.g., safety, output format) and doesn't compensate for the absence of an output schema. This makes it adequate but with clear gaps for an agent to rely on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'filePath' documented as 'Absolute path to the .svelte file.' The description doesn't add any additional meaning beyond this, such as examples or constraints. According to the rules, with high schema coverage (>80%), the baseline score is 3, as the schema already provides adequate parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the compiled JavaScript and CSS output for a Svelte component.' It specifies the verb ('Get'), resource ('compiled JavaScript and CSS output'), and target ('Svelte component'). However, it doesn't explicitly differentiate from sibling tools like 'get_diagnostics' or 'get_completion' which might also relate to Svelte components, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance with 'Useful for debugging compilation issues,' which suggests a context for when to use this tool. However, it doesn't explicitly state when to use it versus alternatives (e.g., 'get_diagnostics' for error checking or 'get_completion' for code suggestions), nor does it mention any prerequisites or exclusions, leaving gaps in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get code completion suggestions at a symbol position. Useful for discovering available members, methods, and types.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file | |
| symbolName | Yes | Name of the symbol to get completions at (positions cursor at the symbol) | |
| symbolKind | No | Kind of symbol | |
| limit | No | Max items to return. Default: 30 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is 'useful for discovering available members, methods, and types,' which gives some context about the output, but it doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or error handling. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with two sentences: the first states the purpose, and the second adds usage context. Every sentence earns its place by providing essential information without redundancy. It's front-loaded with the core functionality, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., read-only vs. destructive), output format, error conditions, and how it integrates with sibling tools. Without annotations or an output schema, the description should do more to compensate, but it only provides basic purpose and usage hints, leaving the agent with insufficient context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the input schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it implies parameters relate to 'symbol position' but doesn't provide additional syntax, format details, or examples. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get code completion suggestions at a symbol position.' It specifies the verb ('Get') and resource ('code completion suggestions'), and mentions the context ('at a symbol position'). However, it doesn't explicitly differentiate from sibling tools like 'get_signature_help' or 'get_hover', which are also related to code assistance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance: 'Useful for discovering available members, methods, and types.' This suggests when to use it (for code completion in development contexts), but it doesn't explicitly state when not to use it or mention alternatives among sibling tools (e.g., 'get_signature_help' for parameter hints). The guidance is helpful but lacks specificity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all files that use/import a Svelte component.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the .svelte component file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool 'finds' files, implying a read-only operation, but lacks details on behavioral traits such as search scope (workspace vs. directory), output format, performance considerations, or error handling. The description is minimal and does not adequately compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It front-loads the core purpose ('Find all files that use/import a Svelte component') without unnecessary elaboration, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is incomplete for a tool with potential complexity (e.g., file searching). It does not address return values, error cases, or operational constraints. While concise, it lacks sufficient context to fully guide an agent in using the tool effectively beyond its basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'filePath' documented as 'Absolute path to the .svelte component file'. The description adds no additional parameter semantics beyond what the schema provides, such as path format examples or validation rules. Baseline score of 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Find all files') and target resource ('that use/import a Svelte component'), distinguishing it from siblings like 'find_references' (general references) or 'get_file_references' (file-level references). It precisely communicates the tool's specialized scope for Svelte component dependencies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (finding component imports in files) but does not explicitly state when to use this tool versus alternatives like 'find_references' or 'get_file_references'. No guidance is provided on prerequisites, exclusions, or specific scenarios where this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get compiler errors, warnings, and diagnostics for a file. Opens the document to trigger computation if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file | |
| minSeverity | No | Minimum severity to include: error, warning, info, hint. Default: warning | |
| waitMs | No | How long to wait for diagnostics (ms). Default: 5000. Increase for large files. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool may open the document to trigger computation, which is useful behavioral context. However, it omits details like whether this is a read-only operation, potential side effects of opening files, error handling, or response format, leaving gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste. The first sentence states the core purpose, and the second adds critical behavioral context. Every word earns its place, and it is front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that performs file operations and returns diagnostics. It lacks details on output structure, error cases, or performance implications. However, it does cover the primary action and a key behavioral trait, making it minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the relationship between parameters or usage nuances. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get compiler errors, warnings, and diagnostics') and resource ('for a file'), distinguishing it from siblings like get_completion or get_hover. It adds operational detail ('Opens the document to trigger computation if needed') that further clarifies its unique behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when diagnostics are needed for a file, but provides no explicit guidance on when to choose this tool over alternatives like get_code_actions or apply_code_action. It mentions opening the document if needed, which hints at a prerequisite, but lacks clear when-not-to-use or comparison statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all files that reference/import the specified file.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool finds references/imports but doesn't cover critical aspects like whether it's read-only, what the output format is, if there are rate limits, or if it requires specific permissions. This leaves significant gaps for a tool that likely interacts with a codebase.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any fluff or redundant information. It's front-loaded and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns complex data (e.g., a list of file references). It doesn't explain what the output looks like, potential errors, or behavioral traits, leaving the agent with insufficient context to use it effectively in a code analysis workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'filePath' clearly documented as an absolute path. The description adds no additional semantic context beyond what the schema provides, such as examples or constraints, so it meets the baseline for adequate but unenriched parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Find') and resource ('files that reference/import the specified file'), making it easy to understand what it does. However, it doesn't explicitly distinguish itself from sibling tools like 'find_references' or 'incoming_calls', which might have overlapping functionality in a code analysis context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'find_references' and 'incoming_calls' present, there's no indication of how this tool differs or when it's the appropriate choice, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get hover documentation and type info for a symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file | |
| symbolName | Yes | Name of the symbol to find | |
| symbolKind | No | Kind of symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but lacks details on permissions, rate limits, error handling, or what the output entails (e.g., format or content of hover info). This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and appropriately sized, making it easy to understand at a glance, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of code analysis tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'hover documentation and type info' entails, how it differs from other symbol-related tools, or any behavioral aspects, leaving gaps that could hinder effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters ('filePath', 'symbolName', 'symbolKind') with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as examples or usage context for the parameters, but meets the baseline since the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('hover documentation and type info for a symbol'), making it understandable. However, it doesn't explicitly differentiate from similar sibling tools like 'get_signature_help' or 'find_definition', which might also provide related information about symbols, leaving some ambiguity about its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to code analysis (e.g., 'find_definition', 'get_signature_help', 'get_completion'), there is no indication of specific contexts, prerequisites, or exclusions for using 'get_hover', which could lead to confusion in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get method signature overloads and parameter info at a symbol position.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file | |
| symbolName | Yes | Name of the symbol (method/function call) to get signatures for | |
| symbolKind | No | Kind of symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but does not describe how it behaves: e.g., whether it requires specific permissions, what happens if the symbol is not found, if there are rate limits, or what the output format looks like. For a tool with no annotations, this is inadequate, as it leaves key behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get method signature overloads and parameter info at a symbol position.' It is front-loaded with the core purpose, has zero waste, and is appropriately sized for the tool's complexity. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavioral traits, usage context, and output expectations. While the schema covers parameters well, the description does not compensate for the absence of annotations or output schema, leaving gaps that could hinder an AI agent's ability to invoke the tool correctly in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any meaning beyond what the input schema provides. The schema has 100% description coverage, with clear descriptions for each parameter (e.g., 'Absolute path to the file', 'Name of the symbol'). The description mentions 'symbol position' but does not elaborate on parameters like 'symbolKind'. Since schema coverage is high, the baseline score of 3 is appropriate, as the schema does the heavy lifting without additional value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get method signature overloads and parameter info at a symbol position.' It specifies the verb ('Get'), resource ('method signature overloads and parameter info'), and context ('at a symbol position'). However, it does not explicitly differentiate from siblings like 'get_hover' or 'get_completion', which might provide related but different information, so it misses the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or specific scenarios for usage. Given the sibling tools include similar code analysis tools (e.g., 'get_hover', 'find_definition'), the lack of differentiation is a significant gap in helping an AI agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find implementations of an interface or abstract method.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file | |
| symbolName | Yes | Name of the symbol to find | |
| symbolKind | No | Kind of symbol | |
| filter | No | Optional regex filter on symbol/file names in results | |
| limit | No | Max results to return. Default: 50 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions what the tool does but lacks details on permissions, rate limits, error handling, or output format. For a tool with 5 parameters and no output schema, this leaves significant gaps in understanding how it behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a code navigation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like what the output looks like, error conditions, or how it integrates with sibling tools, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description doesn't add any semantic details beyond what's in the schema, such as examples or constraints on 'symbolKind'. This meets the baseline for high schema coverage but doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Find') and resource ('implementations of an interface or abstract method'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'find_definition' or 'find_references', which might have overlapping functionality for navigating code structures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'find_definition', 'find_references', and 'go_to_type_definition', there's no indication of the specific context or scenarios where 'go_to_implementation' is preferred, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Jump to the type definition of a symbol (e.g. find the class/interface of a variable).
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file | |
| symbolName | Yes | Name of the symbol to find | |
| symbolKind | No | Kind of symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the action but lacks details on behavioral traits such as error handling, performance implications, or what happens if the symbol isn't found. The example adds some context but is insufficient for a mutation-like operation (navigation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with an inline example that adds value without redundancy. It is front-loaded with the core purpose and uses minimal words to convey the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is minimal but covers the basic purpose. It lacks details on behavior, error cases, or output format, which are important for a navigation tool. However, it's adequate as a starting point, though incomplete for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description does not add meaning beyond the schema, such as explaining parameter interactions or providing usage examples. Baseline score of 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Jump to') and target ('type definition of a symbol'), with an example ('find the class/interface of a variable') that clarifies the intent. It distinguishes from generic 'find_definition' by specifying 'type definition', though not explicitly contrasting with siblings like 'go_to_implementation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'find_definition' or 'go_to_implementation' is provided. The description implies usage for type-related lookups but lacks context on prerequisites, exclusions, or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all functions/methods that call the specified symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file | |
| symbolName | Yes | Name of the symbol to find | |
| symbolKind | No | Kind of symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does without mentioning permissions, rate limits, output format, or error handling. For a tool with no annotations, this is insufficient to inform the agent about operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded and wastes no space, 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.
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, no annotations), the description is minimally adequate. It explains the basic purpose but lacks details on behavior, output, or usage context, which are needed for full completeness in this environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the schema. The description does not add any additional meaning or context beyond what the schema provides, such as examples or usage notes for the parameters, so it meets the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find all functions/methods that call the specified symbol.' It uses specific verbs ('find') and identifies the resource ('functions/methods'), but does not explicitly distinguish it from sibling tools like 'find_references' or 'outgoing_calls', which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools such as 'find_references' or 'outgoing_calls', nor does it specify any prerequisites or exclusions for usage, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a Svelte project by its root directory. Restarts the language server pointed at the new workspace. Call this to switch between projects at runtime.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the Svelte project root directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool restarts the language server and enables project switching, which are important behavioral traits. However, it doesn't mention potential side effects like losing current session state, performance implications, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are tightly focused and front-loaded with the core functionality. Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema and no annotations, the description provides good context about what the tool does and when to use it. However, it could benefit from mentioning what happens after loading (e.g., confirmation of success/failure) since there's no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'path' parameter adequately. The description doesn't add any additional parameter semantics beyond what's in the schema, maintaining the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Load a Svelte project') and the resource ('by its root directory'), with additional context about restarting the language server. It distinguishes from siblings like 'restart_lsp' by specifying project-switching functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it ('to switch between projects at runtime'), but doesn't explicitly mention when NOT to use it or compare it to alternatives like 'restart_lsp' which might handle server restarts differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all functions/methods called by the specified symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file | |
| symbolName | Yes | Name of the symbol to find | |
| symbolKind | No | Kind of symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'finds' items, implying a read-only operation, but doesn't clarify aspects like error handling, performance characteristics, or output format. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of code analysis tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., a list of symbols, their locations), error conditions, or how it interacts with sibling tools. This leaves gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all parameters (filePath, symbolName, symbolKind). The description doesn't add any meaning beyond this, such as explaining relationships between parameters or usage examples. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find all functions/methods called by the specified symbol.' It specifies the verb ('find'), resource ('functions/methods'), and target ('specified symbol'). However, it doesn't explicitly differentiate from sibling tools like 'incoming_calls' (which likely finds callers rather than callees), so it misses the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'find_references' or 'incoming_calls', nor does it specify prerequisites or contexts for usage. This leaves the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a symbol across the workspace. Applies changes to disk.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path to the file | |
| symbolName | Yes | Name of the symbol to rename | |
| newName | Yes | New name for the symbol | |
| symbolKind | No | Kind of symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that changes are applied to disk, indicating a destructive write operation, but lacks details on permissions, error handling (e.g., if symbol not found), side effects (e.g., refactoring across files), or rate limits. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste: the first states the action and scope, the second clarifies the disk impact. It is front-loaded and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context such as return values (e.g., success/failure), error conditions, or behavioral nuances like whether it performs a refactor or simple rename. This leaves gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying workspace-wide renaming, which is already suggested by the tool's purpose. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename a symbol'), the scope ('across the workspace'), and the effect ('Applies changes to disk'), which distinguishes it from read-only sibling tools like find_definition or find_references. It specifies a specific verb and resource with explicit behavioral impact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While it implies a write operation, it doesn't mention prerequisites (e.g., needing edit permissions), exclusions (e.g., not for unsaved files), or direct alternatives among siblings like apply_code_action for broader edits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart the Svelte language server. Use when the server is in a bad state or returning stale results.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies this is a corrective action for server issues but doesn't disclose behavioral details like whether it requires specific permissions, if it interrupts ongoing operations, or what happens after restart. It adds some context about server states but lacks comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose, and the second provides usage guidelines. It's front-loaded and appropriately sized, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple restart operation), no annotations, no output schema, and 0 parameters, the description is somewhat complete but could be improved. It explains when to use it but lacks details on behavioral outcomes or error handling, making it adequate but with gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter semantics, and it doesn't contradict the schema. A baseline of 4 is appropriate since no parameters exist to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Restart') and resource ('Svelte language server'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'load_project' which might also affect server state, keeping it from 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.
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 the tool ('when the server is in a bad state or returning stale results'), which is helpful. It doesn't mention when not to use it or name specific alternatives among siblings, preventing a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0apply_code_actionfind_definitionfind_document_symbolsfind_referencesfind_workspace_symbolsformat_documentget_code_actionsget_compiled_codeget_completionget_component_referencesget_diagnosticsget_file_referencesget_hoverget_signature_helpgo_to_implementationgo_to_type_definitionincoming_callsload_projectoutgoing_callsrename_symbolrestart_lspEach tool has a clearly distinct purpose targeting specific language server operations like definitions, references, completions, diagnostics, and project management. There is no overlap in functionality; for example, find_definition, find_references, and get_completion serve unique roles without ambiguity.
Tool names follow a consistent verb_noun pattern throughout, such as find_definition, get_diagnostics, and rename_symbol. All tools use snake_case with clear action verbs like 'find', 'get', 'apply', and 'load', making the set predictable and readable.
With 21 tools, the count is slightly high but reasonable for a comprehensive language server covering code navigation, refactoring, diagnostics, and project management. It feels heavy but each tool earns its place in the Svelte development domain, avoiding redundancy.
The tool set provides complete coverage for Svelte language server operations, including CRUD-like actions (e.g., rename_symbol, apply_code_action), navigation (e.g., find_definition, go_to_type_definition), diagnostics, completions, and project lifecycle management (e.g., load_project, restart_lsp). No obvious gaps exist for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The official Svelte MCP server providing docs and autofixing tools for Svelte development
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
Lean 4 MCP server: compile, prove theorems, and formalize math with Mathlib.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/adainrivers/SvelteLS.MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
