mcp-companion

[georgeharker]

A possible replacement for mcp-hub (which seems to be dead)

https://github.com/georgeharker/mcp-companion/

integrates with code-companion and loads standard mcpservers.json files (with some optional additions for ephemeral server management).

• https servers
• oauth 2.1 support
• ability to share servers between neovim instances (and manage their lifetimes)
• load a standard mcpServers.json file

Uses fastmcp for the mcp integration (which is a mature codebase).

This project itself is super new - it's working for me, but please lmk if you try it and find issues

[georgeharker]

I've done some work on ironing out issues here and its stability is improving. Tool registration to http servers got some fixes and a bunch more

[augustocdias]

That's great to see. I know codecompanion is implementing MCP native support but I have no idea when it will get feature parity with mcp-hub or yours. @olimorris do you have a plan on when MCP support will be evolved or is this not a prio at the moment?

[augustocdias]

I see... That's a pity... It would be nice to support http/remote as well. I'm all in favor of support and encouraging extensions, but the reality right now is that codecompanion makes a breaking change and many extensions break automatically. In that sense I'd prefer to use as much as possible only from codecompanion and rely less on extensions.

[olimorris]

On both occasions I've contacted the owners of the extension plugins and was willing to wait to release the breaking change so they could update. That will always be my commitment to the ecosystem. Unfortunately, we're exposing the fragility of Neovim plugins 😞.

I see... That's a pity... It would be nice to support http/remote as well

It would be but it's additional burden on myself to maintain. Whilst it's amazing that so many people contribute to CodeCompanion, I'm the one that ultimately has to maintain and support everything. So I balance every feature request on the basis of effort to implement versus benefit to users.

To be candid, I also evaluate my roadmap against where I think things are going. Right now, I think the direction is very much towards that of ACP and agents in the CLI. And as these often have built-in support for remote MCP servers, that allows the user base to make use of them.

[georgeharker]

I tend to agree that acp and cli seems to be the most promising direction. I think it's great that there's native mcp support now in codecompanion, and I'm happy to contribute to making that as full as you'd like it to be. Given the acp direction I'm taking myself, I wanted to be able to share mcp servers between acp instances - hence mcp-companion. I think it's a great on-ramp to have local stdio mcp support built in, I think there's plenty of uses where a user will just use the mcp support in their acp server too - just looking to make that a little more controllable from within codecompanion / nvim

[augustocdias]

is there a way to expose the tools I wrote in lua to the acp agent? I'm trying acp right now and it seems indeed quite promising but I do have a bunch of tools I wrote in lua that I'd like to use with it and it seems unable to see them...

[georgeharker]

There isn’t currently. It might be possible to port the native neovim integration (both accessing neovim state and lua tools) but it’s currently not implemented.

[andtankian]

@georgeharker Tried to install and use it and failed miserably.
Shared server throws this error

Installing standalone doesn't work as well. When I open CodeCompanion it freezes for at least 10 seconds. After ready to chat, the mcps doesn't appear.

CodeCompanion: 19
Neovim: 0.11.6
Python: 3.13.5
Uv: 0.8.11

Can you help me troubleshooting this?

[georgeharker]

I think uv sync should create the venv if it doesn’t exist. I’ll experiment and update the install instructions

[toniher]

I have the same issue. I am not managing to make it work. I am using as detailed in the instructions

    build = "cd bridge && uv sync --frozen",

In the .local/state/nvim/mcp-companion.log

[2026-04-01 22:49:27] [DEBUG] Health check attempt 29 failed (connection refused)
[2026-04-01 22:49:28] [DEBUG] Health check attempt 30 failed (connection refused)
[2026-04-01 22:49:29] [ERROR] Bridge health check timed out after 30s
[2026-04-01 22:49:29] [WARN] CC: bridge did not connect in 30000ms

Running it without Neovim/sharedserver seems to work...

CodeCompanion: 19
Neovim: 0.11.6
Uv: 0.8.13

[andtankian]

@toniher

Go manually inside the sharedserver installation folder and execute these commands:

cd bridge && uv venv --python 3.14 .venv && uv sync --frozen

It will show a warning (possibly). You skip the warning and done, you're ready.

[georgeharker]

logs live at ~/.local/state/nvim/mcp-bridge.log for the bridge
sharedserver keeps logs at $XDG_RUNTIME_DIR/sharedserver if XDG_RUNTIME_DIR is set or /tmp/sharedserer

[toniher]

With the last update you pushed, without any other action from my side I managed to make it work. Thanks a lot!

[georgeharker]

Please do let me know if you try it- if it's working well for you or if there are issues you encounter. I'd like to make sure it's solid for folks other than me.

[andtankian]

Hi @georgeharker
I've raised up an issue in mcp-companion. Can you take a look?

[georgeharker]

Can you try either

:ServerList in neovim

or

sharedserver list

from the cli?

If you have one running outside shared server it’ll likely port conflict on startup.

You can use lsof -ti 9741 to find pids using that port

also

sharedserver admin kill mcp-bridge

will bring down a problematic start of the bridge if started via shared server (or the mcp-companion)

[toniher]

Maybe a naughty bridge was not there anymore since the last restart of the computer. I will take the recipe into account!

[georgeharker]

Mcp-companion can now toggle mcps per chat session. You can also choose which to expose to chats by default