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.

[lizqwerscott]

I developed a simple Emacs implementation for the MCP interface, which can automatically convert MCP tools into gptel tools.
This is mcp.el

auto convert

This is an exploratory version of a simple implementation that currently supports only calling tools (call tools) and does not fully implement the standard MCP protocol. Through this attempt, I hope to discover a better way to integrate MCP with Emacs.

[ovistoica]

Great initiative with mcp.el @lizqwerscott ! Things are definitely moving in an awesome direction!

Joining this discussion from the perspective of adding more AI features to emacs. Emacs should also implement a server for MCP where the LLM can tell you to open a specific buffer, move to the next position, change text, etc.

Context:
In cursor, for example, for the next completion (if you press subsequent TAB), the LLM will infer your intent and will take you to another position (possibly to another file) and show you a different completion there.

So, while an emacs MCP client will be required, I think we should also look into an emacs MCP server so an AI can execute actions within emacs:

• set reminders/tasks if you have org agenda
• buffer movement and write/read buffers
• grammar check and open popups with suggestions
  etc.

[lizqwerscott]

@ovistoica For implementing grammar checking and code editing features like cursor, I believe the key lies in enabling the model to develop a deeper understanding of the code.
Inspired by aider, we can design and implement an MCP server with the primary function of scanning the code structure of a project or a single file and generating a concise map of the project, which can then be provided as a tool for the frontend.

The following tools can be defined:

1. Retrieve the project's concise map: Generate an overview of the project's structure, showing the relationships between files and code modules.
2. Retrieve a function's implementation: Provide the detailed implementation of a specific function to facilitate navigation and analysis.

When modifying a piece of code in a project, users can select the target region in Emacs and send the modification command along with the selection to the AI. The AI can then decide whether to invoke the defined tools to assist with the modification, achieving a functionality similar to the intelligent code editing features of the Cursor editor.

This approach allows the AI to better understand the project's overall code structure, enhancing both editing accuracy and collaboration efficiency.

[vivekhaldar]

Simple implementation of an Emacs MCP server: https://github.com/vivekhaldar/emacs-mcp-server

This enables Claude to control a running Emacs process and execute elisp within it, via natural language chat/instructions in the Claude desktop UI.

I actually implemented two tools (one to generate elisp, one to execute it), but it almost never uses the former. It seems to take the route of generating elisp itself (without using the available tool), then using the other tool to execute it.