LSP MCP demonstrates solid definition quality with well-structured schemas and comprehensive descriptions. All four tools have explicit registrations with descriptions and input schemas visible in src/broker/tools.ts. The execute_lsp tool is particularly well-documented with detailed parameter descriptions addressing positional operations, transaction IDs, and safety requirements. However, some parameter descriptions contain example values (e.g., 'quickfix or source.fixAll'), and output schemas are not formally documented. Tool naming follows verb_noun convention appropriately. The rename_resource tool correctly marks IRREVERSIBLE operations, showing security awareness.

• Document formal output schemas for all tools. Example for list_instances: { type: 'object', properties: { instances: { type: 'array', items: { type: 'object', properties: { id: { type: 'string' }, workspace: { type: 'string' }, ... } } } } }
• Replace example values in descriptions with enum constraints. E.g., for actionKind, use an enum of valid CodeActionKind values instead of 'e.g. quickfix'.
• Add explicit pagination guidance: 'Results are limited to 200 items (configurable). For larger result sets, use path filters (pathPattern) or query constraints to reduce scope.' Reference the maxResults config.
• Document error scenarios with recovery steps: 'If renameId is invalid, call rename_preview again to get a fresh transaction ID.' and 'If operation times out (30s), the workspace may be under load, retry with a smaller scope or check VS Code status.'
• Create a matrix in the tool description mapping each operation enum to its required/optional parameters, or link to detailed operation reference documentation.
• Add a per-tool example showing a successful multi-step workflow (e.g., code_action_preview → code_action_apply with proper ID threading).

Inferred effective spec: <=2025-11-25.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained