Model Context Protocol

[metachip]

Apropos Context, MCP looks very interesting:

The Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you're building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need.

Open sourced by Anthropic today it looks like a very appealing solution to some of the problems we've been discussing and some of those we haven't. It's not clear whether this will be widely adopted but its certain that Anthropic will. I've created this feature request simply to notify everyone of this potential opportunity. It's a protocol that's worth a close look for embedding in gptel as a back-end to enable access to what are likely to be a growing number of data resources, from databases, files, services, which using MCP as a client/server protocol, can provide a unified way to surface context from multiple heterogeneous sources.

Check out the Quickstart for how it works. Of course Claude will builds server for you. Haven't tried this in elisp yet :)

[2024-11-26 Tue 13:56] fae3ffb391f4

[karthink]

Yeah, this is all over the tech Internet today. It appears to be a way to formalize tool-use for Anthropic models. I think I'm some distance away from adding support for this, since gptel currently doesn't support tool-use either. I'm currently working on adding a little state machine to gptel to handle multi-step LLM interactions, since doing this directly with nested callbacks created a big mess.

In the time it'll take me to get there, we'll know if this protocol catches on. It may also be worth making a generic mcp.el library instead and plugging into it with gptel. That way other LLM clients for Emacs won't have to reinvent the wheel the way we all did last year when writing the clients.

[karthink]

To be clear, I think the issues we're discussing in #481 and #475 are mostly about the UI and orthogonal to this feature. We would still have the same decisions to make with this protocol supported.

[metachip]

To be clear, I think the issues we're discussing in #481 and #475 are mostly about the UI and orthogonal to this feature.

Agreed.

In the time it'll take me to get there, we'll know if this protocol catches on.

There sure does seem to be a lot of enthusiasm for it - this repo listing implementation appeared yesterday.

https://github.com/appcypher/awesome-mcp-servers

among others

https://github.com/mark3labs/mcp-go

https://sourcegraph.com/blog/cody-supports-anthropic-model-context-protocol

The open question at this point is whether the other frontier and open source models adopt it. Someone has opened a Manifold market on this question:

https://manifold.markets/AlistairRoche/will-openai-reference-anthropics-mo

[dsp-ant]

Yeah, this is all over the tech Internet today. It appears to be a way to formalize tool-use for Anthropic models. I think I'm some distance away from adding support for this, since gptel currently doesn't support tool-use either. I'm currently working on adding a little state machine to gptel to handle multi-step LLM interactions, since doing this directly with nested callbacks created a big mess.

Hey. Just stumbled across this. MCP is actually less about formalizing tool use than just trying to generalize a way of moving any kind of context into an assistant. In this way, I often think about it more as LSP but for assistant panels. It has 'prompts' which for example the Zed editor maps to slash commands that are user invoked, and it has resources which are more like file attachments. Of course it also has tool use, but its quite a bit more than that. (disclaimer, i wrote the protocol :p). Hope that helps. Would be cool to see MCP in Emacs.

[karthink]

(disclaimer, i wrote the protocol :p)

Burying the lede there @dsp-ant 😄

Thanks for the clarification. I am thinking a generic Elisp MCP adapter that all LLM clients for Emacs can use might be the way to go here. I've initiated a discussion with the authors of the (ostensibly) most popular Emacs LLM clients.