Tools like Claude Code have improved here. They won’t load all tools but instead rely on tool search. Context bloat of MCP servers was a thing if badly written clients but it’s certainly getting better
It has little to do with financing. In addition to the development cost there is now also a membership fee.
What a donation to the Linux foundation offers is ensuring that the trademarks are owned by a neutral entity, that the code for the SDKs and ownership of the organization is now under a neutral entity. For big corporations these are real concerns and that’s what the LF offers.
It would be a crazy antitrust violation for all of these companies to work together on something closed source - e.g. if Facebook/Google/Microsoft all worked on some software project and then kept it for themselves. By hosting it at a neutral party with membership barriers but no technical barriers (you need to pay to sit on the governing board, but you don't need to pay to use the technology), you can have collaboration without FTC concerns. Makes a ton of sense and really is a great way to keep tech open.
All it means that there is a common place and a recommendation that if you care as a client implementor (e.g. postman, chatgpt and others do), there is a spot to look for a generally accepted way of how to do that instead of increasing amount of proprietary extensions on top of MCP.
> there is a spot to look for a generally accepted way of how to do that
I think MCP-UI in it's current state can fill that role very well, and that's not the only lens with which to view a SEP like this.
From what I can tell the main thing that this SEP does is put the official blessing of the MCP project on the existing underlying protocol that MCP-UI is already using. I think the better way would be to let MCP-UI and competing implementations cook for a little bit longer, rather than trying to get an officially sanctioned extension out the door and then iterate on that, which will cause a lot more churn.
For a non-trivial feature like this, I would expect an SEP that highlights more alternative usage scenarios and potentially operates on a more technology agonistic layer (e.g. it's very JS+iframe bound, so what about mobile or terminal UIs?), similar to the main MCP spec. Especially given the backdrop of the main MCP specification, which feels much more well-rounded and throughly considered (though in a few areas still incomplete), this SEP does not seem to meet the same bar.
Reading that from the perspective of someone that builds a LLM Chat UI[0] (and aims to be able to maintain that long-term) that heavily builds on MCP as an interoperability concept, reading what is proposed here and seeing how prescriptive it is in many aspects does not spark a lot of joy.
EDIT: From what I can tell I'm replying to one of the co-creators of MCP. So let me just ask quite directly: Do you think that the risk of proprietary sprawl in terms of MCP-UI alternatives is currently greater than prematurely standardizing a potentially incomplete version?
I appreciate the take. I can certainly see your position.
In my mind what we are doing is building a common place to evolve the pattern. I wouldn’t really call it “standardize”, since in the end in this space adoption matters. (Writing a standard is worth nothing if nobody is using it). I expect MCP apps to evolve and iterate independent from the main spec for a while. You are right, it’s early and premature to say “this is done”. That’s the goal with extensions.
I do believe that I rather have commonalities between a Claude.ai and a ChatGPT as a developer (not sure that’s true if I was mostly looking at it from a product perspective). I also think you will see chat providers iterate on top of it, and mcp apps is more a common core than the full thing one can use on every platform.
I want to also highlight that this is an optional "extension" to MCP, not a required part of specification. If you are a terminal application, only care about tool calling, etc, you are free to skip this. If you want to enable rich clients, then it might be something to consider implementing.
I have followed Makepad since Raph Levien pointed me towards it, while developing Xi. I am so stoked about this. What they have achieved in terms of UI framework is so unique in the rust ecosystem, particularly with the Shader abstractions. I am so eager to build with this. I know there are plenty of shortcomings when you are building your own UI framework without native components, but for creative applications, DAWs, Synths, 2D UI for games, even text editors, I think it will be so cool.
We appreciate the criticism and take it very seriously. We know things are not perfect and there is lots of room for improvement. We are trying to balance the needs of the fast paced AI world, and the careful, time consuming needs of writing a spec. We’d love to improve the spec and the language, and would of course appreciate help here. We also work with an increasingly larger community that help us get this right. The most recent Authorization specification changes are just one example.
Similarly we are working on the SDKs and other parts of MCP to improve the ecosystem. Again, it’s all very early and we appreciate help from the community.
You can use it with any LLM in LibreChat, Cody, Zed, etc. See https://modelcontextprotocol.io/clients. The protocol doesn’t prescribe an LLM, has facilities to sample from the client independent of LLM and brings support to build your own bespoke host in their SDK.
Really appreciate the write up. I am one of the authors of MCP and this helps a great deal giving a good overview of where we need to do better.
I was a bit under the water over the last few weeks with talking to people about MCP and just generally a bit overwhelmed about how well it has been received.
I'll take a look at issue88 this week. Thanks so much
Any feedback on developer experience is always welcomed (preferably in github discussion/issue form). It's the first day in the open. We have a long long way to go and much ground to cover.
reply