It’s the equivalent to calling CLIs in bash, except mlua is a sandboxes runtime while bash is not.

This is the same as a CLI. Bash is nothing but a programming language and you can do the same approach by giving the model JavaScript and have it call MCP tools and compose them. If you do that you can even throw in composing it with CLis as well

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.

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.

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.

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

The gist of it is: you have an llm application such as Claude desktop. You want to have it interact (read or write) with some system you have. MCP solves this.

For example you can give the application the database schema as a “resource”, effectively saying; here is a bunch of text, do whatever you want with it during my chat with the llm. Or you can give the application a tool such as query my database. Now the model itself can decide when it wants to query (usually because you said: hey tell me what’s in the accounts table or something similar).

It’s “bring the things you care about” to any llm application with an mcp client

I can totally see your concern about sandboxed app, particularly for flatpack or similar distribution methods. I see you already opened a discussion https://github.com/modelcontextprotocol/specification/discus..., so let's follow up there. I really appreciate the input.

The best starting point are the respective client parts in the SDK: https://github.com/modelcontextprotocol/typescript-sdk/tree/... and https://github.com/modelcontextprotocol/python-sdk/tree/main..., as well as the official specification documentation at https://spec.modelcontextprotocol.io.

If you run into issues, feel free to open a discussion in the respective SDK repository and we are happy to help.

(I've been fairly successful in taking the spec documentation in markdown, an SDK and giving both to Claude and asking questions, but of course that requires a Claude account, which I don't want to assume)

The Model Context Protocol initial release aims to solve the N-to-M relation of LLM applications (mcp clients) and context providers (mcp servers). The application is free to choose any model they want. We carefully designed the protocol such that it is model independent.