Add MCP support #3672

Antonin-Deniau · 2025-03-28T21:01:14Z

This is a rough implementation of MCP into Aider.
It currently support adding stdio MCP servers with this configuration in the ~/.aider.conf.yml

mcp: true
mcp-servers:
  - git-server
mcp-server-command:
  - "git-server:uvx mcp-server-git"
mcp-tool-permission:
  - "git-server:git_status=auto"
mcp-server-env:
  - "git-server:GIT_SERVER=server"

Todo:

Add http support for remote MCP servers
Change the way async is implemented in the mcp module ? Currently I used threading and message queue to keep everything else synchronous
Use a better structure for the config file ? I used a format that is easy to write for both the config file and the cli arguments
Delete the command that I used to test mcp tools
Add documentations
Add MCP ressource
Add MCP prompts
Add tests
Add anthropic's mcp dependency, since the feature depend on it. (I dont know how to add it in the requirements.txt properly)

CLAassistant · 2025-03-28T21:01:20Z

All committers have signed the CLA.

bartlomiejwolk · 2025-03-28T23:03:22Z

How to interpret the config in ~/.aider.conf.yml?

Here's what I know from Claude Desktop / Roo Cline:

{
  "mcpServers": {
    "filesystem": {
      "command": "node",
      "args": [
        "c:/Users/<user>/AppData/Roaming/npm/node_modules/@modelcontextprotocol/server-filesystem/dist/index.js",
        "D:/"
      ],
      "disabled": true,
      "alwaysAllow": []
    }
  }
}

Antonin-Deniau · 2025-03-29T11:06:26Z

How to interpret the config in ~/.aider.conf.yml?

Here's what I know from Claude Desktop / Roo Cline:

{
  "mcpServers": {
    "filesystem": {
      "command": "node",
      "args": [
        "c:/Users/<user>/AppData/Roaming/npm/node_modules/@modelcontextprotocol/server-filesystem/dist/index.js",
        "D:/"
      ],
      "disabled": true,
      "alwaysAllow": []
    }
  }
}

For this, the config should be something like:

mcp: true
mcp-servers:
  - filesystem
mcp-server-command:
  - "filesystem:node c:/Users/<user>/AppData/Roaming/npm/node_modules/@modelcontextprotocol/server-filesystem/dist/index.js D:/"

But now you made me realize that I havent checked if it work on Windows...

wladimiiir · 2025-03-30T06:55:20Z

I checked your code, and I have to say - great job implementing this! While I’m not a Python developer and can’t comment on the threading aspect 😁, I do have some feedback.

One suggestion: I’d avoid using the reflection message as the MCP tool’s response. If I’m not mistaken, only three reflections are allowed by default, which could limit the agent’s usability by restricting iterations. Changing max_reflection_count would have broader effects, like impacting incorrect SEARCH/REPLACE blocks.

From a UX perspective, I’d also reconsider how servers are defined in the config file. Something like this might be more intuitive:

mcp: true
mcp-servers:
  git-server:
    command: "uvx mcp-server-git"
    tool-permissions:
      git_status: auto
    env:
      GIT_SERVER: server
  another-server:
    command: "some-command"
    tool-permissions:
      some_tool: auto
    env:
      SOME_ENV: value

bartlomiejwolk · 2025-03-30T07:23:35Z

I like the proposal by @wladimiiir for config formatting (no hypens).

lutzleonhardt

Hi @Antonin-Deniau

General

Thank you for your PR and adding the ability to let aider use MCP :)
I think there is a potential problem with the queues/threading, but besides that (and your mentioned todos) your code looks very clean and nice to me.

Just some additional ideas:

what about adding a new coder /mcp or /agent to only add the tool prompt if I really want tools it in an ongoing conversation. There is always this overhead of adding the toolprompt with each request
is there a way to leverage native tool use via litellm and the OpenAI tool spec? i.e. LiteLLM plans to integrate a MCP Bridge which could maybe used: [Feature] MCP bridge support BerriAI/litellm#7934

lutzleonhardt · 2025-03-30T16:08:01Z

aider/mcp/mcp_manager.py

+        """Sync call to the thread with queues."""
+
+        self.message_queue.put(CallArguments(server_name, function, args))
+        result = self.result_queue.get()


IMO I see a potential problem here.
All server threads read from the same message_queue. Whichever thread calls get() first, gets the message. If the server name does not match, that thread just calls task_done() and discards it.
This means the correct server thread might never see that message—it’s already been consumed by the wrong thread.

lutzleonhardt · 2025-03-30T16:20:15Z

aider/coders/base_coder.py

@@ -1455,6 +1466,14 @@ def send_message(self, inp):
                    self.reflected_message = add_rel_files_message
                return

+            tool_results = self.check_for_tool_calls(content)
+            for tool_result in tool_results:
+                if self.reflected_message:


As told already by others: max_reflections is the limit for consecutive tool calls.

while message: self.reflected_message = None list(self.send_message(message)) if not self.reflected_message: break if self.num_reflections >= self.max_reflections: self.io.tool_warning(f"Only {self.max_reflections} reflections allowed, stopping.") return self.num_reflections += 1 message = self.reflected_message

What should be the correct way to implement that ? Since it behave almost exactly like a diff edit/a file inclusion,
should I implement a reflection limit / reflected_message only for the mcp tools ?

I would say you could have another field self.mcp_tool_result_message = tool_result instead of using self.reflected_message. And then:

while message: self.reflected_message = None list(self.send_message(message)) if not self.reflected_message and not self.mcp_tool_result_message: break if self.num_reflections >= self.max_reflections: self.io.tool_warning(f"Only {self.max_reflections} reflections allowed, stopping.") return if self.num_mcp_iterations >= self.max_mcp_iterations: self.io.tool_warning(f"Only {self.max_mcp_iterations} MCP iterations allowed, stopping.") return if self.reflected_message: self.num_reflections += 1 message = self.reflected_message if self.mcp_tool_result_message: self.num_mcp_iterations += 1 message = self.mcp_tool_result_message

Thanks, it seem to work, maybe I'll all the max_mcp_iterations in the configuration too

lutzleonhardt · 2025-03-30T16:27:47Z

aider/mcp/mcp_manager.py

+
+        for server in self.get_enabled_servers():
+            if server.command:
+                t = threading.Thread(target=self._server_loop, args=(server, loop))


You have one thread per MCP server, but because of the blocking behaviour of the queues the tool calls are made sync because the main thread is blocked. In addition there is the problem that all threads read from one queue (which leads to the problem only one thread can receive it atm).

Alternatives (provided by sonnet):

Single AsyncIO Event Loop in a Background Thread

class AsyncioManager: def __init__(self): self.loop = asyncio.new_event_loop() self.thread = threading.Thread(target=self._run_event_loop, daemon=True) self.thread.start() self.servers = {} def _run_event_loop(self): asyncio.set_event_loop(self.loop) self.loop.run_forever() def call_async(self, coro): future = concurrent.futures.Future() async def wrapper(): try: result = await coro future.set_result(result) except Exception as e: future.set_exception(e) asyncio.run_coroutine_threadsafe(wrapper(), self.loop) return future.result() # This blocks until result is available

Asynchronous API with Callbacks

class AsyncToolManager: def __init__(self): self.loop = asyncio.new_event_loop() self.thread = threading.Thread(target=self._run_event_loop, daemon=True) self.thread.start() def execute_tool(self, server_name, tool_name, arguments, callback): """Non-blocking tool execution with callback""" async def run_tool(): result = await self._async_execute_tool(server_name, tool_name, arguments) # Call the callback in the main thread callback(result) asyncio.run_coroutine_threadsafe(run_tool(), self.loop)

lutzleonhardt · 2025-03-30T16:34:32Z

aider/coders/base_coder.py

@@ -1106,6 +1108,11 @@ def fmt_system_prompt(self, prompt):
            )
        else:
            quad_backtick_reminder = ""
+
+        # Add MCP tools information if MCP is enabled


The 2 sections could be combined to one, right?

prompt = prompt.format( fence=self.fence, quad_backtick_reminder=quad_backtick_reminder, lazy_prompt=lazy_prompt, platform=platform_text, shell_cmd_prompt=shell_cmd_prompt, shell_cmd_reminder=shell_cmd_reminder, language=language, ) if self.main_model.system_prompt_prefix: prompt = self.main_model.system_prompt_prefix + prompt # Add MCP tools information if MCP is enabled if is_mcp_enabled(): mcp_tools_info = self.gpt_prompts.mcp_tools_prefix + "\n\n" + get_available_tools_prompt() prompt += "\n\n" + mcp_tools_info

Remote task_done to avoid deadlock

ishaan-jaff · 2025-04-01T15:19:56Z

hi @lutzleonhardt - I'm the litellm maintainer. We'd love to help aider support MCP. Here's our MCP bridge on the litellm python SDK: https://docs.litellm.ai/docs/mcp#litellm-python-sdk-mcp-bridge

any thoughts on this ? how can we help you ?

Add a mcp file configuration file Remove redundant enable in mcp server class Add num_mcp_iterations & max_mcp_iterations so it wont clash with max_reflections

Antonin-Deniau · 2025-04-02T19:37:20Z

Since the YAML configuration file cannot support a nested configuration structure, I added a mcp-configuration cli argument, that point to a YAML for MCP configuration specifically, eg:
In the regular configuration file:

mcp-configuration: ~/.aider/mcp.yml

In ~/.aider/mcp.yml

servers:
- name: git-server
  command: "python -m mcp_server_git"
  env:
    GIT_SERVER: server
  permissions:
    git_status: auto

I removed redundant enable property in the MCP server class
I added num_mcp_iterations & max_mcp_iterations so it wont clash with max_reflections
I fixed some deadlock in the message queues for now

mark-bradshaw · 2025-04-02T19:45:10Z

Can we have a fall back in the mcp config file names, like happens with a lot of other aider config files? That way there can be mcp config that's specific to a particular repo, but also config that is global. So the final mcp config would be ~/.aider/mcp.yml + ./.aider.mcp.yml

lutzleonhardt · 2025-04-03T07:31:39Z

hi @lutzleonhardt - I'm the litellm maintainer. We'd love to help aider support MCP. Here's our MCP bridge on the litellm python SDK: https://docs.litellm.ai/docs/mcp#litellm-python-sdk-mcp-bridge

any thoughts on this ? how can we help you ?

Hi @ishaan-jaff
thanks for offer to help :)
Aider already uses LiteLLM to access the models. But for the MCP Bridge a dedicated server (the LiteLLM proxy) needs to be run, right? I assume this is not suitable in this case, because aider wants to stay independent of a dedicated server part.

…background, using non blocking message queue on the mcp side Fixed some problems with mcp tools permissions Use thread.join to gracefully stop thread

Antonin-Deniau · 2025-04-07T21:31:42Z

The new commit now aggregate all the session into one async while loop in a background thread.

There is currently a problem I'm trying to debug where when we send a Ctrl-C (To cancel an llm call for example) it is sent to the mcp server too, and make it crash in a subsequent call. it cause issue with this one for example: https://github.com/modelcontextprotocol/servers/tree/main/src/git

jerzydziewierz · 2025-04-10T08:32:56Z

please do not invent a new format of configuring the MCP servers !!!
MCP servers configuration is already well established and changing it from json to yaml will create endless maintenance headaches for all users

jerzydziewierz · 2025-04-10T08:34:29Z

From a UX perspective, I’d also reconsider how servers are defined in the config file. Something like this might be more intuitive:
mcp: true
mcp-servers:
  git-server:
    command: "uvx mcp-server-git"

no, please don't!

again, the way to configure MCP servers is well established, and inventing a new configuration format will create endless headaches of incomplete translatability between classic and this new custom yaml way

Add MCP support

3cb4891

Remove some mistakes

8dc0215

This was referenced Mar 29, 2025

MCP SUPPORT #3314

Open

Please add support for model context protocol from anthropic #2525

Open

lutzleonhardt suggested changes Mar 30, 2025

View reviewed changes

Merge tools/prompt initialisation

6c530bc

Remote task_done to avoid deadlock

paul-gauthier added the priority label Apr 1, 2025

Refactor MCP cli arguments

940b349

Add a mcp file configuration file Remove redundant enable in mcp server class Add num_mcp_iterations & max_mcp_iterations so it wont clash with max_reflections

Antonin-Deniau added 2 commits April 3, 2025 21:45

Refactor the McpManager so one thread with a asyncio loop is used in …

fb6392d

…background, using non blocking message queue on the mcp side Fixed some problems with mcp tools permissions Use thread.join to gracefully stop thread

Try debugging the stdin making git mcp crash because of ctrlC

d46e27e

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add MCP support #3672

Add MCP support #3672

Antonin-Deniau commented Mar 28, 2025 •

edited

Loading

CLAassistant commented Mar 28, 2025 •

edited

Loading

bartlomiejwolk commented Mar 28, 2025

Antonin-Deniau commented Mar 29, 2025

wladimiiir commented Mar 30, 2025 •

edited

Loading

bartlomiejwolk commented Mar 30, 2025 •

edited

Loading

lutzleonhardt left a comment •

edited

Loading

lutzleonhardt Mar 30, 2025

lutzleonhardt Mar 30, 2025 •

edited

Loading

Antonin-Deniau Mar 31, 2025

wladimiiir Mar 31, 2025 •

edited

Loading

Antonin-Deniau Apr 2, 2025

lutzleonhardt Mar 30, 2025 •

edited

Loading

lutzleonhardt Mar 30, 2025

ishaan-jaff commented Apr 1, 2025

Antonin-Deniau commented Apr 2, 2025

mark-bradshaw commented Apr 2, 2025

lutzleonhardt commented Apr 3, 2025

Antonin-Deniau commented Apr 7, 2025

jerzydziewierz commented Apr 10, 2025

jerzydziewierz commented Apr 10, 2025

Add MCP support #3672

Are you sure you want to change the base?

Add MCP support #3672

Conversation

Antonin-Deniau commented Mar 28, 2025 • edited Loading

Todo:

CLAassistant commented Mar 28, 2025 • edited Loading

bartlomiejwolk commented Mar 28, 2025

Antonin-Deniau commented Mar 29, 2025

wladimiiir commented Mar 30, 2025 • edited Loading

bartlomiejwolk commented Mar 30, 2025 • edited Loading

lutzleonhardt left a comment • edited Loading

Choose a reason for hiding this comment

General

Just some additional ideas:

lutzleonhardt Mar 30, 2025

Choose a reason for hiding this comment

lutzleonhardt Mar 30, 2025 • edited Loading

Choose a reason for hiding this comment

Antonin-Deniau Mar 31, 2025

Choose a reason for hiding this comment

wladimiiir Mar 31, 2025 • edited Loading

Choose a reason for hiding this comment

Antonin-Deniau Apr 2, 2025

Choose a reason for hiding this comment

lutzleonhardt Mar 30, 2025 • edited Loading

Choose a reason for hiding this comment

lutzleonhardt Mar 30, 2025

Choose a reason for hiding this comment

ishaan-jaff commented Apr 1, 2025

Antonin-Deniau commented Apr 2, 2025

mark-bradshaw commented Apr 2, 2025

lutzleonhardt commented Apr 3, 2025

Antonin-Deniau commented Apr 7, 2025

jerzydziewierz commented Apr 10, 2025

jerzydziewierz commented Apr 10, 2025

Antonin-Deniau commented Mar 28, 2025 •

edited

Loading

CLAassistant commented Mar 28, 2025 •

edited

Loading

wladimiiir commented Mar 30, 2025 •

edited

Loading

bartlomiejwolk commented Mar 30, 2025 •

edited

Loading

lutzleonhardt left a comment •

edited

Loading

lutzleonhardt Mar 30, 2025 •

edited

Loading

wladimiiir Mar 31, 2025 •

edited

Loading

lutzleonhardt Mar 30, 2025 •

edited

Loading