idea: give claude read access to buffers

[ElleNajt]

I usually have a vterm buffer open, and I'd like Claude to be able to read it. Similarly, when hacking on emacs, it would be useful to give claude access to the messages buffer.

Two potential ways to achieve this:

• file (e.g. repo/.vterm) that Claude knows about, so e.g. a "share buffer with Claude" command that writes the buffer to a file, keeps it fresh with a hook, and sends the location of the file to the Claude buffer.
• An MCP tool that provides read-only access to buffers.

I started a read-only emacs MCP server here: https://github.com/ElleNajt/emacs-introspection-mcp -- maybe that's the way to go, and then I just tell Claude the name of the buffer I want it to look at, and the "share buffer with Claude" just sends the buffer name to it?
(Maybe there's a more developed read-only emacs MCP server out there? When I wrote that the options I saw were much more yolo -- and when I'm fully yoloing just letting Claude run Bash(emacsclient ... ) works, but I don't always want to yolo like that...)

Thoughts?

[ElleNajt]

Similarly, could be useful for Claude to have a view of the agenda.

I just added those things to that MCP server and will try it out -- curious if you have other thoughts about workflow integrations that claude-code.el could have if it also had an emacs MCP server built into it.

[ElleNajt]

It would also be really neat to be able to let it call eglot commands this way, e.g. to look up definitions of symbols or places where symbols are referenced. Is that already built into the IDE integration PR?

[ElleNajt]

This works smoothly

[stevemolitor]

TBH, I use claude-code-send-region (which sends the entire file if no region) or I copy and paste into the Claude buffer.

But yes, MCP would be useful. The ide branch implements Claude Code's "IDE" protocol, an undocumented MCP over WebSockets protocol in which Claude only requests certain predefined tools (like open diff, etc.).

I have moved the guts of ide integration to a new repo: Monet. This feature will be useful even for users who choose to run Claude outside of Emacs.

I'd like to consider implementing an MCP server to add normal MCP support, such as looking up references, etc. However, I'd like it to be implemented in Emacs (ideally using STDIO).

EDIT: When you select text Monet will send the selected text along with the file name and position. It will also support sending explicit @ mentions - once I implement that!

[ElleNajt]

I'd like to consider implementing an MCP server to add normal MCP support, such as looking up references, etc. However, I'd like it to be implemented in Emacs (ideally using STDIO).

How strong is your preference that it be implemented in elisp? There's nice tooling around typescript and python MCP servers already. (Plus I already have a typescript implementation of many of the MCP features I want.)

btw another thing that it's useful to have an emacs MCP server for is for running check-parens on elisp files -- it's pretty common for Claude to miscount parenthesis and run around in circles failing to identify the issue, but check-parens helps identify and fix the bad spot quickly.

Monet looks really exciting! Will check it out. :)

[stevemolitor]

How strong is your preference that it be implemented in elisp?

Not super strong, but I think it's possible. Someone has written a STDIO MCP server in bash and it doesn't look too bad. Claude-code-ide has implemented an MCP server in elisp using an HTTP server. mcp-server-lib.el has implement an MCP server in a combination of elisp and bash.

Either way, I think emacsclient is Emacs' secret weapon here. I'm imagining that users can create new tools just by writing an elisp function and some JSON config (which Emacs could generate), similar to how you made it easy to write a hook function in elisp. (Great stuff btw.)

[ElleNajt]

I'm imagining that users can create new tools just by writing an elisp function and some JSON config

Yeah, I agree that that seems like a nice workflow.
I agree that that seems very doable, the protocol seems straightforward...

We could have a variable mcp_tools, a list of function definitions, and set up the server process so that:
-- tools/list would calls emacsclient to get the names and signatures of the functions in that list
-- tools/call would assemble a function call as a list and emacsclient it to evaluate it

... however, I'm concerned about how to avoid code injection here.

I think this isn't totally solved in the typescript library I'm experimenting with either -- the best I can do is sanitize all the input variables. Perhaps our server could handle tools/call by calling the sanitization on each input string before assembling the list and passing to emacsclient, to add a layer on top of whatever users write.

I wonder if there's a way to avoid calling emacsclient from bash here -- bash adds another layer of sanitization to think about -- maybe there's a way for the process that's run to be a persistent emacs session that connects to the server? (imo this is a nice reason to avoid a typescript server that calls a bash subprocess that then calls emacsclient... --- so much surface area!)

Claude is suggesting having emacs open a TCP connection to the MCP server and just have the MCP server simply pass messages along to emacs via JSON-RPC. Provided Claude isn't hallucinating, this seem straightforward to set up. I like this! Will experiment. Thoughts?

On MCP experimentation -- I've given Claude the ability to change the status of TODOs or archive or make new ones, and this sweet!

[ElleNajt]

Claude is suggesting having emacs open a TCP connection to the MCP server and just have the MCP server simply pass messages along to emacs via JSON-RPC.

Me and Claude made a pass at implementing that -- #79

I'm imagining that users can create new tools just by writing an elisp function ...

This is how it works -- there's a macro that can be used to define functions with metadata that are picked up by the server.

It's working pretty well!