agent-lsp
Related Servers
Alternatives to agent-lsp
No user-submitted related servers found.
Related Servers
- AlicenseAqualityBmaintenanceThe IDE for agents — read by symbol, edit against a revision, validate with your own build, revert. It is a local stdio MCP server for coding agents. It reads code by symbol with tree-sitter and real language servers (Go, Java, Scala, TypeScript, Python, Rust, Ruby), edits against a known revision and returns compiler diagnostics with each edit, runs the repository's own build, test etc.121Apache 2.0
- AlicenseNot gradedqualityBmaintenanceLocal-first code intelligence and safety layer for AI coding agents. MCP server exposes dependency graph, impact analysis, and AST-compressed repo context, backed by typed local memory, patch-scope safety gates, and git-independent transaction rollback.1MIT
- AlicenseAqualityDmaintenanceMCP server that combines Read+Edit file operations into single tool calls. 80-95% fewer tool calls formulti-file refactoring across Claude, Cursor, Windsurf, and more.315 npm3MIT
- AlicenseCqualityBmaintenanceLocal-first MCP runtime for coding agents with bounded workspace access, content-preconditioned writes, AST search, LSP navigation and diagnostics, and Git status/diff. Designed to give coding agents useful repository access without treating unrestricted shell access as the default integration boundary.133MIT
- FlicenseNot gradedqualityBmaintenanceA local-first MCP server that gives AI coding agents durable project memory, dependency graphs, and impact analysis to answer team knowledge and cross-file change questions before editing.9 npm1-
- AlicenseNot gradedqualityBmaintenanceA local MCP server that gives AI coding agents precise, symbol-level context instead of whole-file reads, packing a target symbol with its causal neighborhood (callers, callees, imports, tests) and reporting token savings versus reading the file. It also enables surgical in-place edits of only the target symbol's byte range, impact analysis before signature changes, health review, and project gate execution.MIT
TDQS
Scored across 50 tools
Each tool targets a distinct LSP operation or workflow step. Navigation tools (go_to_definition, go_to_declaration, go_to_implementation, go_to_type_definition, go_to_symbol) are clearly differentiated by which aspect of the symbol they resolve. Simulation tools form a clear pipeline (create, edit, evaluate, commit/discard/destroy) with no overlap. All tools have unique purposes.
Tool names consistently follow a verb_noun pattern (e.g., open_document, get_references, rename_symbol). Some use 'get_' vs 'simulate_' but the pattern is uniform. Even compound names like simulate_edit_atomic follow the same convention. No mixed cases or unrelated verbs.
50 tools is high but justified by the comprehensive coverage of LSP features and additional utilities (simulation, build, test, cross-repo references). A few tools could potentially be merged (e.g., simulate_edit and simulate_edit_atomic) but overall the count reflects the server's ambition and the complexity of code analysis.
The tool set covers the full lifecycle of code interaction: document management, navigation, diagnostics, editing (with simulation), formatting, refactoring, testing, and building. It also includes workspace management, cross-repo references, and server introspection. No obvious gaps for an LSP-based code agent.