Single tool 'lsp' has a detailed description (194 chars) and comprehensive input schema with 5 parameters, all typed and described. However, the schema lacks explicit output documentation, parameter constraints (enums, ranges), and error recovery guidance. The tool bundles multiple LSP operations (diagnostics, definitions, references, renames, code actions) under one 'action' parameter, violating single-responsibility principle. Parameter 'method' and 'parameters' are generic and underspecified for raw LSP requests. No pagination or result-limiting guidance despite MaximumResponseCharacters=32,000 cap. Error handling exists in code but is not surfaced in tool description.

• Split 'lsp' into separate tools: get_diagnostics, get_definition, get_references, get_hover, get_symbols, rename_symbol, apply_code_actions. Each tool should have a verb_noun name and single responsibility.
• Add explicit enum constraint for 'action' parameter with all valid values (Status, Reload, Capabilities, Diagnostics, Symbols, Definition, TypeDefinition, Implementation, References, Hover, Rename, RenameFile, CodeActions, Request).
• Document output schema in tool description: specify fields returned for each action type (e.g., Diagnostics returns array of {range, message, severity}, Definition returns {uri, range}, etc.).
• Add error recovery guidance to description: 'On timeout, retry with a smaller limit. On stale_edit, call Reload first. On lsp_error, check file syntax.' Reference the error codes defined in code.
• Constrain 'limit' parameter with explicit range: 'Integer between 1 and 100 (default: 20). Larger limits may timeout or exceed response size cap of 32,000 characters.'

Inferred effective spec: 2025-06-18+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry