你在电脑上跑了一个本地模型，让它帮你改代码。它能给建议，却不能直接连接专门的编程工具：模型像一位被关在房间里的顾问，知道该做什么，手边却没有工具。llama.cpp 正在补上这条连接通道，让本地模型不只生成文字，也能通过 MCP 调用外部能力。
llama.cpp 是一个广泛使用的本地大模型推理项目，重点是在个人电脑和多种硬件上运行模型。MCP，即 Model Context Protocol（模型上下文协议），则让 AI 应用以相对统一的方式连接工具和数据源。两者接起来，llama.cpp 承担的角色就开始变化：它不再只是“跑模型”的引擎，也在靠近 Agent——能够选择并调用工具来完成任务的 AI 系统——的运行入口。
需要先说明：本次功能描述主要来自一篇 r/LocalLLaMA 帖子。帖子使用了“full MCP support”和“for all protocols”等说法，但材料没有提供完整的官方文档、版本说明或独立测试。因此，本文只确认材料明确提到的 HTTP 与 stdio，不把它扩大解释为已经覆盖 MCP 的所有传输方式、协议版本和能力项。
真正补上的，是本机工具这条路
据该帖作者 ilintar 介绍，llama.cpp 客户端此前已经能够连接通过 Web 提供的 HTTP MCP 服务。HTTP 是网页和网络服务交换请求与响应的通用方式，适合访问远程服务。
更难处理的是 stdio。stdio，即标准输入输出，是程序通过文本流收发数据的基础机制。MCP 的 stdio 模式常用于连接电脑上直接启动的工具进程。通俗地说，HTTP 像给网络服务打电话；stdio 更像让两个同机运行的程序直接递纸条。后者需要 llama.cpp 负责启动、连接和管理本机程序，不能只把网络请求转发出去。
供稿所引帖子称，合并 ggml-org/llama.cpp 的 PR #26062 后，llama.cpp 增加了对 stdio MCP server 的原生集成。这里的 MCP server 不是模型服务器，而是向模型提供具体工具的程序。这样，本机运行的工具也可以进入 llama.cpp 的工具调用链路。
入口也被收拢了
这次变化不只是多支持一种连接方式。帖子称，开发者先调整了 llama-cli——llama.cpp 的终端客户端——让它改用 llama.cpp server，而不再走一条独立的模型服务路径。随后，MCP 支持被接入已有的 native tools server，也就是 llama.cpp 原生的工具服务层。
这番调整把原先分散的环节收拢到同一入口：用户在 WebUI 中与模型对话，模型发现可用工具，再通过工具服务连接 MCP server。帖子因此把 WebUI 称为“完整的 agentic chat”。更克制地说，它现在具备了开展 Agent 式对话所需的一块关键基础设施；实际体验是否已经“完整”，仍要看模型的工具选择能力、外部服务和具体配置。
MCP server 的配置可以放进 JSON 配置文件，也可以直接写在命令行中。JSON 是一种常见的结构化文本格式。配置文件适合保存固定工具组合，命令行内联配置则适合临时启用某项能力。不过，“标准 JSON 格式”究竟指通用的 MCP 生态格式，还是 llama.cpp 接受的一种 JSON 结构，现有材料没有充分说明。
为什么这一步值得看
关键不在于 llama.cpp 又多了一个功能开关，而在于本地推理的边界向外移动了。过去谈本地模型，重点常是“模型能否在自己的电脑上跑起来”。接入 MCP 后，问题开始变成“它能否在本地对话入口中连接并使用工具”。这正是从推理引擎走向 Agent 运行时的一步。
帖子举出的例子是 Serena 这类 coding MCP server。把它接入 llama.cpp，便可以用本地模型搭建能够调用编程工具的 agentic coder。这里更准确的表述是：用户可能不再需要额外部署一层模型代理框架；Serena 本身仍是独立的 MCP server，也仍有自己的运行依赖。
局限与未知
- “全协议支持”目前证据不足。材料明确涉及 HTTP 和 stdio，但没有说明是否覆盖 MCP 的全部现行传输方式、协议版本及能力项。
- 供稿没有给出对应的 llama.cpp 发布版本、兼容范围或实际运行测试，不能据此判断稳定性与使用门槛。
- WebUI 能接入工具，不等于模型一定能可靠地选择和调用工具；帖子也没有提供成功率、性能或安全性数据。