mcphub.nvim
将 MCP 协议能力注入 Neovim,一站式管理 AI 编程助手工具调用
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
将 MCP 协议能力注入 Neovim,一站式管理 AI 编程助手工具调用
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
图1:mcphub.nvim 主界面——在 Neovim 中管理 MCP 服务器状态
想象这样一个场景:你正在用 Neovim 写代码,同时想让 AI 助手(Claude、GPT 等)直接读取你当前的代码文件、查询项目文档、甚至帮你重构某个函数。传统的做法是切换到 VS Code、打开 Chat 界面、粘贴代码——来回折腾效率极低。mcphub.nvim 解决的就是这个痛点:它把 MCP(Model Context Protocol)协议的能力直接搬进了 Neovim,让 AI 工具成为编辑器的一部分,而不是另一个需要切换的窗口。
MCP(Model Context Protocol)是由 Anthropic 主导推出的开放协议,旨在标准化 AI 模型与外部工具、数据源之间的通信方式。简单理解:有了 MCP,AI 不再只能靠"粘贴文本"获取上下文,而是可以真正调用文件系统工具、搜索工具、数据库等——就像给 AI 安装了一个标准化的 USB 接口。
在这样的背景下,mcphub.nvim 应运而生。作者 ravitemer 在 2024 年创建了这款插件,目标是为 Neovim 用户提供统一的 MCP 客户端体验。它的核心价值在于:无论你用的是 Avante、Codecompanion 还是 Copilot Chat,都可以统一通过 mcphub 管理所有 MCP 服务器,无需为每个插件单独配置。
截至 2026 年 6 月,该项目已积累 1779 颗 GitHub 星标,获得了 CryogenicPlanet、Yetone(native-feel-skill 作者)、Oli Morris 等知名社区成员的赞助支持,并获得 Warp 终端的官方赞助——Warp 甚至为 mcphub.nvim 开设了专门的集成页面。
mcphub.nvim 的使用流程可以概括为"安装插件 → 配置服务器 → 在 AI 对话中使用"。以一个典型的配置为例,用户只需在 Neovim 配置文件(通常是 init.lua 或 plugins.lua)中加入几行设置:
-- 使用 lazy.nvim 安装
{ "ravitemer/mcphub.nvim" }
-- 在 config 中初始化
require("mcphub").setup({
port = 37373, -- MCP Hub 服务端口
config = "~/.config/mcphub/servers.json", -- MCP 服务器配置
auto_approve = false, -- 是否自动批准工具调用
auto_toggle_mcp_servers = true, -- 允许 AI 自动启停服务器
workspace = { enabled = true }, -- 支持项目级别配置
extensions = {
avante = { enabled = true },
codecompanion = { enabled = true },
}
})
插件默认通过 mcp-hub CLI(Node.js 程序)驱动。该 CLI 由同一个作者维护,通过 npm 全局安装:
npm install -g mcp-hub@latest
安装后,servers.json 文件定义了所有可用的 MCP 服务器。例如 filesystem 服务器可以让你在对话中直接读取项目文件:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "${workspaceFolder}"]
},
"memory": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-memory"]
}
}
}
mcphub.nvim 提供了完整的 UI 界面来管理这些服务器:查看已连接的服务器列表、监控工具调用输入输出、启用/禁用特定服务器,甚至支持图片渲染——当你询问 AI"帮我分析这张图"时,结果直接显示在 Neovim 缓冲区中,而不是弹出一个外部窗口。
从代码结构来看,mcphub.nvim 的架构设计相当清晰,体现了作者对 Neovim 插件生态的深刻理解。
核心层(hub.lua,约 60KB):这是整个插件的引擎所在。MCPHub 类负责与 mcp-hub CLI 进程建立通信(通过 plenary.nvim 的 Job 模块),管理连接状态、超时控制(默认 60 秒工具调用超时)、工作空间感知(workspace-aware mode)以及服务器生命周期(启动/停止/故障恢复)。值得注意的是,插件支持工作空间级别配置:不同项目可以有不同的 servers.json,mcphub 会自动为每个工作空间启动独立的 MCP Hub 实例(端口通过哈希算法分配)。
原生服务器层(native/):这是 2025 年新增的重要特性。在此之前,mcphub 必须依赖外部的 mcp-hub CLI 进程;现在插件内置了原生 MCP 协议实现,可以直接在 Lua 中注册 MCP 服务器定义,无需 Node.js 运行时。这对 NixOS 用户尤其友好——通过 flake.nix 打包的插件不再需要额外安装 Node.js 生态依赖。
UI 层(ui/):采用 Neovim 的浮动窗口(floating window)和虚拟文本(virtual text)机制渲染 MCP 工具调用状态。renderer.lua(约 38KB)是最复杂的 UI 模块,负责将 JSON 格式的 MCP 响应渲染为可读性强的 Neovim 缓冲区内容。image_cache.lua 负责缓存 AI 返回的图片数据,uitext.lua 和 nuiline.lua 分别处理文本渲染和状态栏(lualine)集成。
扩展层(extensions/):插件通过扩展机制与主流 Neovim AI 聊天插件深度集成:
配置管理层(utils/config_manager.lua,约 17KB):负责读写 servers.json,支持 JSON5 语法(允许注释),还支持直接从 VS Code 的 .vscode/mcp.json 文件读取配置,方便从 VS Code 迁移来的用户。
mcphub.nvim 定位明确,是为已经深度使用 Neovim 作为主力编辑器、同时希望引入 AI 辅助能力的用户设计的。以下人群会从中受益:
不适合的场景:
servers.json,有一定学习曲线需要坦诚指出几个现实问题:
MCP 生态碎片化:MCP 服务器数量虽然在增长,但很多官方推荐的服务器(如 filesystem、memory)依赖 npx 动态下载,首次使用有网络等待时间。部分服务器的 Windows 兼容性也不如 Linux/macOS 理想。
配置复杂度:当 MCP 服务器数量增加时,servers.json 的管理会变得繁琐。虽然有工作空间感知功能,但跨项目共享服务器配置目前需要手动维护多份配置或使用符号链接。
稳定性依赖外部进程:mcp-hub CLI 作为独立 Node.js 进程运行,如果该进程崩溃,Neovim 中的 mcphub 会丢失连接,需要手动重启。原生服务器层(native/)虽然提供了替代方案,但目前覆盖的服务器类型还比较有限。
Avante 生态锁定:虽然 mcphub 支持多种聊天插件,但与 Avante 的集成深度最高,如果你使用的是 Cursor 的内置 AI 或 Windsurf 的 AI 功能,mcphub 帮不上忙。
mcphub.nvim 的出现是 Neovim 生态拥抱 AI 时代的一个缩影。在此之前,Neovim 社区的 AI 集成主要靠社区成员各自为政的插件实现——Avante 有自己的工具系统,Codecompanion 有自己的扩展体系,CopilotChat 又是另一套逻辑。mcphub 试图提供一个统一抽象层,让用户可以在不同 AI 聊天插件之间自由切换,同时保留统一的 MCP 服务器配置。
这个思路与 MCP 协议本身的跨平台目标高度一致:MCP 想做的是 AI 工具的"USB-C",mcphub.nvim 想做的是 Neovim 中的"MCP Hub"。从数据来看,1779 颗星标在 Neovim 插件中属于中等偏上规模,但其获得 Warp 官方赞助和众多核心插件作者的支持,证明了其在生态链中的战略价值。
作者 ravitemer 维护了一个活跃的更新节奏,CHANGELOG.md 记录了从 v0.1 到 v0.5+ 的完整迭代历史,包括原生服务器支持、workspace-aware 模式、lualine 集成等重要里程碑。Issues 区有 27 个开放问题,但大多数是功能请求而非 bug 报告,整体社区健康度良好。