Proposal: Integrated Basic MCP Client Support

[cairijun]

TL;DR

I’m proposing we integrate a lightweight, basic MCP client directly into CodeCompanion.

I’ve put together a preliminary implementation here. I’ve been dogfooding this for about a week, and it’s been enough to handle my daily workflows. Example config:

require("my.plugins.codecompanion.mcp").setup {
  ddgSearch = {
    cmd = { "uvx", "duckduckgo-mcp-server" },
  },
  sequentialThinking = {
    cmd = { "npx", "-y", "@modelcontextprotocol/server-sequential-thinking" },
  },
  runPython = {
    cmd = { "uvx", "mcp-run-python", "--deps", "numpy,pandas", "stdio" },
    server_instructions = function(orig)
      return orig
        .. "\nThe Python environment has the following packages pre-installed: numpy, pandas."
    end,
    default_tool_opts = {
      require_approval_before = true,
    },
    tool_overrides = {
      run_python_code = {
        output = {
          prompt = function(self)
            local args = self.args
            return string.format(
              "Confirm to execute the following Python code:\n```python\n%s\n```\nGlobal Variables:\n%s",
              args.python_code,
              vim.inspect(args.global_variables)
            )
          end,
        },
      },
    },
  },
}

---

Rationale

1. I think we can all agree that MCP support is rapidly becoming a necessity, not just a "nice-to-have," for any modern AI coding assistant.

2. While mcphub is powerful, it can feel a bit heavy-weight for users who just have simple needs. Sometimes you just want to hook up one or two servers without a complex orchestration layer.

3. Because mcphub and CodeCompanion are developed independently, breaking changes happen. For example, it seems mcphub doesn't currently support CodeCompanion v18. By having a native, built-in client, we can guarantee a baseline level of stability for our users. Even if external plugins break, the core MCP functionality within CodeCompanion remains usable.

4. There are many tools currently built into CodeCompanion—like web_search or fetch_webpage—that don't strictly require deep editor integration. If we delegate these capabilities to the diverse ecosystem of MCP servers, it might lower our maintenance burden. We can then focus our energy on the tools that do require deep integration, such as insert_edit_into_file or LSP-aware tools like list_code_usages.

---

Goals & Non-Goals

I want to be clear about the scope of this proposal:

• Capability over "Solution": This is not intended to be a full replacement for mcphub. The goal is simply to provide the capability to call an MCP server natively. If a user needs to connect a server, we provide the pipe.
• Keep it Lean: We should stick to the necessary, most commonly used features. For instance, supporting only stdio transport is likely sufficient for the vast majority of servers. Users with remote server needs can use mcp-remote or stick with mcphub.
• Extensibility: While simple, the implementation should be extensible enough to handle configuration differences across various users and MCP servers.

I'd love to hear thoughts on this approach and whether this aligns with the project's roadmap.

[olimorris]

Thanks for such a thoughtful post.

This is something that I've been giving some serious thought to myself in recent times. I too, agree, that MCP is becoming a necessity and it appears that interest in developing MCPHub from the creator is potentially waning. Plus, as you state, it is a very heavy-weight implementation.

I am open to work with you ln adding a PR for a basic client once I've released v18.0.0 in the next couple of days. As with any PR, the sticking point for me will be the UX and how it feels for users. Your proposal of @{mcp...} seems entirely sensible and it's very encouraging you have this level of functionality in < 600 LOC.

Feel free to create a PR in the next couple of days and we can tag team on it. If, when you create it, you could share a checklist of what capabilities of the protocol we're supporting and not supporting, that would be very helpful. My ACP implementation is a good reference for how to structure a class and interweave it with the chat buffer.

[cairijun]

Good to hear that! I'll refactor the current implementation to follow the convention and make a PR with tests next week.