@@ -6,3 +6,6 @@ Design goals:
- The simplest solution would obviously be to just create some tools that allow the model to call out to the LSP. But I don't think that would work, because LSP is stateful. In particular, the LSP spec has a lot to say about document synchronization. To be spec-compliant, a client must alert the server when it has opened, closed, or edited a document. Otherwise, the server might report inaccurate diagnostics. Therefore, the agent's basic operations, like "view," "edit," and "grep," must be LSP-aware.
- By re-implementing core tools like these in an MCP, we also solve the first problem, since we know that agents will reliably call tools like this.
- This is, in fact, the approach taken by Crush -- namely, making tool calls LSP aware. See [here](https://github.com/charmbracelet/crush/blob/f1122df71fab7d11f369a936ef636abd40a7dc48/internal/llm/tools/write.go#L196) for example.
+- Another goal: I *do* want it to take LSP seriously. That is, it should support incremenetal operations (synchronization, diagnostics, indexing, etc). This is potentially a lot of work,
+but an MVP is possible I think without making the code brittle against later changes.
+- I think ^^ implies that the server has to support multiple languages, since the standard itself assumes that servers can handle multiple languages.