It's not about the interface to make a request to a server, it's about how the client and server can interact.
For example:
When and how should notifications be sent and how should they be handled?
---
It's a lot more like LSP.
Nobody [who knows what they're doing] wants their LLM API layer controlling anything about how their clients and servers interact though.
Not sure I understand your point. If it's your client / server, you are controlling how they interact, by implementing the necessaries according to the protocol.
If you're writing an LSP for a language, you're implementing the necessaries according to the protocol (when to show errors, inlay hints, code fixes, etc.) - it's not deciding on its own.
Even if I could make use of it, I wouldn't, because I don't write proprietary code that only works on one AI Service Provider. I use only LangChain so that all of my code can be used with any LLM.
My app has a simple drop down box where users can pick whatever LLM they want to to use (OpenAI, Perplexity, Gemini, Anthropic, Grok, etc)
However if they've done something worthy of putting into LangChain, then I do hope LangChain steals the idea and incorporates it so that all LLM apps can use it.
It's an open protocol; where did you get the idea that it would only work with Claude? You can implement it for whatever you want - I'm sure langchain folks are already working on something to accommodate it
Once fully adopted by at least 3 other companies I'll consider it a standard, and would consider it yes, if it solved a problem I have, which it does not.
Lots of companies open source some of their internal code, then say it's "officially a protocol now" that anyone can use, and then no one else ever uses it.
If they have new "tools" that's great however, but only as long as they can be used in LangChain independent of any "new protocol".