somnium_sn

Yes use MCP elicitations

One of my favorite parks and much lesser knows is Westpark in Munich. Similarly built around usage and still unique since it was originally built for a national garden exhibition it features a rich set of small little areas from around the world, a Japanese party, a Chinese part, French areas, English areas. It has outdoor theaters, playgrounds, a lake, a communial area and much more . It’s worth a visit when you are in Munich

The Java SDK is currently a Tier 2 SDK.. As a Tier 2 SDK they have up to 6 months to implement it. I know they are actively working towards support for the specification.

Best to join our community discord [1] and ask the maintainers !

[1] https://modelcontextprotocol.io/community/communication

Hey I am the one Lead maintainer of the MCP protocol.

I agree and hear you that file uploads are a pain. As the core maintainer group we have deferred the work on this for this release and hope to pick it up soon.

Now is the moment to engage with the respective working group to make your case heard so we can ensure it’s on the roadmap.

It is fine to have corners of the internet that run in a particular way.

My issue however, is that this is changing the rules on people. Codeberg initially was a FLOSS alternative to big company Github. Now it's more narrow, an alternative to Github and only for people who don't want to use AI. What's the next step? This is the problem, you either a platform and be, within legal reasons, agnostic, or you are trying to be a specific community. It is unclear to me if the specific community that Codeberg wants to be today will be the one it wants to be in a year from now, because clearly it's changing.

I cannot rely on a service provider that does change that quickly.

I am still a bit surprised that this is not more widely used. Normal inference + tool calls is effectively composition via serialized natural language, whereas Code Mode / Programmatic Tool Calling is using purpose built languages (aka programming languages) for composition and concurrency. It somewhat feels obvious to me that the latter is way more token and latency efficient.

Little historic sidenote: Zed was the first MCP client next to Claude Desktop

Give the model an interpreter like mlua and let it write code to compose MCP calls together. This is a well established method.

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

Give the model a REPL and let it compose MCP calls either by using tool calls structured output, doing string processing or piping it to a fast cheap model to provide structured output.

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

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.

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.

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.

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.

Literally hand written. Maybe I just sound like an AI. Who knows

Hey, I am one of the MCP authors.

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

Thank you. That’s good feedback.

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

At the moment only Claude Desktop supports MCP. Claude.ai itself does not.

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.

Having broader support for SSE in the servers repository would be great. Maybe I can encourage you to open a PR or at least an issue.

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.

I would probably more think of it as LSP for LLM applications. It is enabling data integrations, but the current implementations are all local.

We are still a bit light on documentation on how to integrate MCP into an application.

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)

Note that both Sourcegraph's Cody and the Zed editor support MCP now. They offer other models besides Claude in their respective application.

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.

Both Python and Typescript SDK can be used to build a client. https://github.com/modelcontextprotocol/typescript-sdk/tree/... and https://github.com/modelcontextprotocol/python-sdk/tree/main.... The TypeScript client is widely used, while the Python side is more experimental.

In addition, I recommend looking at the specification documentation at https://spec.modelcontextprotocol.io. This should give you a good overview of how to implement a client. If you are looking to see an implemented open source client, Zed implements an MCP client: https://github.com/zed-industries/zed/tree/main/crates/conte...

If you have specific questions, please feel free to start a discussion on the respective https://github.com/modelcontextprotocol discussion, and we are happy to help you with integrating MCP.

A few common use cases that I've been using is connecting a development database in a local docker container to Claude Desktop or any other MCP Client (e.g. an IDE assistant panel). I visualized the database layout in Claude Desktop and then create a Django ORM layer in my editor (which has MCP integration).

Internally we have seen people experiment with a wide variety of different integrations from reading data files to managing their Github repositories through Claude using MCP. Alex's post https://x.com/alexalbert__/status/1861079762506252723 has some good examples. Alternatively please take a look at https://github.com/modelcontextprotocol/servers for a set of servers we found useful.

@jspahrsummers and I have been working on this for the last few months at Anthropic. I am happy to answer any questions people might have.

Thank you Bryan! That’s a gem! I’ll incorporate it into one of the next blog posts!