karthink
Model Context Protocol
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
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.
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.
To be clear, I think the issues we're discussing in https://github.com/karthink/gptel/issues/481 and https://github.com/karthink/gptel/issues/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
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.
(disclaimer, i wrote the protocol :p)
Burying the lede there @dsp-ant :smile:
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.
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.
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.
@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:
- Retrieve the project's concise map: Generate an overview of the project's structure, showing the relationships between files and code modules.
- 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.
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.
It seems to take the route of generating elisp itself (without using the available tool), then using the other tool to execute it.
How good is it at doing this? I have found that Claude tends to hallucinate functions in elisp that do not exist sometimes.
I noticed it getting wrong elisp a couple of times, but it has an agentic loop that notices that and tries to correct itself. GPT-4o tends to be the better elisp programmer. Hopefully there will be more MCP clients soon.
On Sat, Apr 5, 2025 at 9:05 PM Lispy @.***> wrote:
It seems to take the route of generating elisp itself (without using the available tool), then using the other tool to execute it.
How good is it at doing this? I have found that Claude tends to hallucinate functions in elisp that do not exist sometimes.
— Reply to this email directly, view it on GitHub https://github.com/karthink/gptel/issues/484#issuecomment-2781207838, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAINWUS3VGH2V5VFJN5MUL2YCRZVAVCNFSM6AAAAABSPL2Y2SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBRGIYDOOBTHA . You are receiving this because you commented.Message ID: @.***> [image: lispy-ai]lispy-ai left a comment (karthink/gptel#484) https://github.com/karthink/gptel/issues/484#issuecomment-2781207838
It seems to take the route of generating elisp itself (without using the available tool), then using the other tool to execute it.
How good is it at doing this? I have found that Claude tends to hallucinate functions in elisp that do not exist sometimes.
— Reply to this email directly, view it on GitHub https://github.com/karthink/gptel/issues/484#issuecomment-2781207838, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAINWUS3VGH2V5VFJN5MUL2YCRZVAVCNFSM6AAAAABSPL2Y2SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBRGIYDOOBTHA . You are receiving this because you commented.Message ID: @.***>
-- Vivek Haldar http://vivekhaldar.com ~ @.***
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.
sounds very interesting. I am having a hard time to catch up with mcp.el and gptel, but in fact ultimately what I do want it to be able to talk to my emacs in natural language. MCP to control emacs is the future. Many people are still overwhelmed by the new things they hope to integrate within their emacs, hoping emacs will resist. Your tool might be the next thing
gptel supports MCP servers via mcp.el, and includes easy ways to add tools from MCP: (require 'gptel-integrations), then
- either use
M-x gptel-mcp-connectandM-x gptel-mcp-disconnect, - or look for these options in gptel's tools menu, which do the same things:
MCP servers will be started and (optionally) shut down as necessary.
Sharing prompts from MCP servers doesn't appear to have taken off, but it can be added if it does.
Converting to a discussion as there are no plans to do anything more re: MCP in gptel for now.