Server has 5 tools with complete input schemas and descriptions present in the code. Naming follows verb-noun convention (rename_file, move_function, extract_function, find_references, rename_symbol). However, several critical gaps reduce quality: (1) No output schemas documented, LLMs cannot reason about what fields to expect from responses; (2) Parameter descriptions lack format constraints (e.g., 'line' and 'character' are numbers but lack min/max bounds); (3) No error handling guidance visible, tools don't indicate what errors are retryable or how to recover; (4) Security: tools accept 'language' as free-form string with default 'typescript' but no enum constraint, inviting invalid values; (5) Tool descriptions are minimal (34-74 chars) and lack context on when to use each tool vs alternatives; (6) No mention of prerequisites (e.g., does the language server need to be running?) or what the tools actually return. Descriptions meet the 10-1024 char baseline but land on the short end, providing minimal signal for LLM selection.
Tools (5)
extract_functionwritesource verified63/100
Extract selected code into a new function
find_referencesread onlysource verified65/100
Find all references to a symbol using LSP
move_functionwritesource verified63/100
Move a function to a different file using LSP refactoring
rename_filewritesource verified67/100
Rename a file or folder using LSP rename capabilities
rename_symbolwritesource verified68/100
Rename a symbol (variable, function, class, etc.) across all files
No output schemas documented. LLMs cannot reason about response structure, field names, or what to extract for downstream tool chains. Tools only show input schemas; output must be documented.
Parameter descriptions lack actionable constraints. 'line' and 'character' are numbers with no min/max stated. 'language' is free-form string with default 'typescript' but no enum values enumerated, inviting invalid inputs like 'lang' or 'ts'.
No error handling guidance. Tools do not indicate what errors are recoverable, what conditions cause failures, or how agents should respond. Missing 'recovery-guide' pattern.
Document output schemas for all 5 tools. Example: rename_file should return {success: boolean, oldPath: string, newPath: string, message?: string}. Include field descriptions so LLMs can extract and chain results.
Add enum constraint for 'language' parameter: enum: [typescript, javascript, python, java, c, csharp, go, rust, ruby, php]. This prevents hallucinated language names and makes the tool self-documenting.
Add min/max bounds to numeric parameters. Example: 'line' → 'Line number (1-based, minimum 1)', 'character' → 'Character position in line (0-based, 0 - 1000)'. This constrains invalid inputs.
Expand tool descriptions from 34 - 74 chars to 100 - 200 chars. Include: (1) What the tool does; (2) When to use it instead of similar tools; (3) What it returns; (4) Any prerequisites (LSP server running, project language set). Example: 'Rename a symbol (variable, function, class, interface) across all files in the LSP project. The LSP server must be running and the project language set. Returns the list of files modified and the new symbol name on success, or an error with the old/new names that caused the conflict.'
Add error handling guidance. Example in rename_file: 'On error, returns error code (LSP_SERVER_NOT_RUNNING, FILE_NOT_FOUND, PERMISSION_DENIED, PARSE_ERROR) with a message. If LSP_SERVER_NOT_RUNNING, ensure the language server is started. If FILE_NOT_FOUND, check oldPath. If PERMISSION_DENIED, verify write access to the file.'
For destructive tools (rename_file, move_function, extract_function, rename_symbol), add note: 'This operation modifies files. Consider running with LSP preview/refactor dry-run first to validate changes before committing.' Or add a dry_run boolean parameter if supported by LSP.
Tool descriptions are too brief (34-74 chars, below median 194 chars). No context on when to use each tool vs alternatives, what prerequisites exist (e.g., LSP server running?), or what fields the response includes. Descriptions do not help LLMs select the right tool.
No idempotency guarantees stated. Destructive tools like rename_file and move_function do not indicate if retries are safe or if repeated calls with same args will duplicate results or fail. Missing 'idempotent-operation' pattern.
Parameter 'language' lacks enum constraint. Described as '(typescript, javascript, python, etc.)' but not formalized. LLMs may pass 'ts', 'node', 'py', or made-up values. Enums are self-documenting and prevent hallucination.
No confirmation or dry-run pattern for destructive operations. Tools like rename_file, move_function, rename_symbol modify code without reversibility hints or undo paths. Missing 'confirmation-request' pattern.
Parameter 'character' in multiple tools has default=0 but description lacks clarity on what position 0 means (start of line? start of symbol?). Ambiguous defaults can cause tools to target wrong locations.
Clarify 'character' default=0: state whether it means the start of the line (column 0) or auto-detect the symbol start. Example: 'Character position where the symbol starts (0-based). If 0, the server auto-detects the symbol position at the given line.'
Add parameter dependency documentation. Example in extract_function: 'startLine and endLine define a range to extract. startLine must be < endLine. startCharacter and endCharacter default to 0 and line end respectively; if you want a precise range, provide both.'
Document what file paths are expected (absolute? relative to workspace?). Example: 'File path relative to the LSP workspace root, e.g., src/utils.ts (not /home/user/project/src/utils.ts).'
Add permission/scope declarations: 'Requires: read:workspace, write:code. Verify the LSP client has permissions to read and modify the target files.'
Include examples for ambiguous parameters. Example in rename_symbol: 'The line and character identify a symbol position. To rename function foo() on line 5, pass line: 5, character: 0 (where 'function' keyword starts) or character: 9 (where 'foo' starts). The server resolves the symbol at that position.'
Add rate limiting guidance if LSP operations are expensive: 'Each call triggers LSP refactor requests, which may be slow on large codebases. Batch related operations or use move_function for multiple items instead of sequential rename_symbol calls.'