One advantage of MCP being "inspired by" LSP, at least to people like myself who work on LSP tools, is that a decent chunk of existing LSP code can be reused and repurposed. For example, most editors already ship with code for managing local server sidecars over stdio. There are a few annoying differences though like the lack of a header section in MCP.
I wrote this tool to make instrumenting language servers very easy. MCP (both protocol and architecture) seems heavily inspired by LSP which made me curious about what it would take to support it through my telemetry-capturing proxy.
Haven't thought too deeply about how useful an MCP proxy can be but I see it as potentially a general platform for monitoring or debugging MCP servers or clients.
Yup exactly. My tool is supposed to sit between MCP clients and servers. For now only stdio is in scope. Your tool is great. An MCP server for LSPs! I'll be taking it for a spin.
It's very possible I'm just bad at Go but it seems to me that the result of trying to adhere to CSP in my own Go projects is the increasing use of dedicated lifecycle management channels like `shutdownChan`. Time will tell how burdensome this pattern proves to be but it's definitely not trivial to maintain now.
You're not bad at Go, literally everyone I know who has tried to do this has concluded it's a bad idea. Just stop using channels, there's a nice language hidden underneath the CSP cruft.
reply