From 4ad517675f68a6d52b1e624bf554c3b790b8af58 Mon Sep 17 00:00:00 2001 From: Phillip Davis Date: Thu, 9 Oct 2025 09:28:21 -0400 Subject: [PATCH] some noodle-y design thoughts --- README | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README b/README index 7827f1a3a1d1a74708472c0b41eb6f25524b5985..604f7c5844ec06dcb3130249340bfe83087428dc 100644 --- a/README +++ b/README @@ -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.