第一次把知识库接到一个 Agent 上的时候，我写的是一堆私有接口：一个 HTTP 端点负责检索，另一个负责导入文档，客户端还得自己处理分页、鉴权和错误码。能用，但换一个客户端就要再写一遍。
后来我知道了这个叫 MCP（Model Context Protocol）的协议。它把「模型或 Agent 调用外部能力」这件事统一了起来。理解它之后我才意识到，我之前写的不是知识库，而是在为每个客户端各写一套临时胶水。
MCP 解决什么问题
没有 MCP 时，每个模型应用要连工具，都得各自定义「怎么连、传什么、怎么鉴权」。结果是 M 个工具、N 个客户端，需要 M×N 份集成代码。
MCP 把这个 M×N 收敛成 M+N：工具端实现一次 MCP server，客户端实现一次 MCP client，双方通过同一个协议对话。协议本身是公开规范，由 modelcontextprotocol.io 维护。
server、client 与 tool
MCP 里有三个核心概念：
- server：把能力暴露出来的一方。比如琅嬛暴露
knowledge_search、document_ingest这些工具。 - client：使用能力的一方。比如 Claude Desktop、Cursor，或你自己写的 Agent。
- tool：server 暴露的一个具体可调用动作，有名字、入参和返回结构。
此外还有 resource（供读取的数据）和 prompt（预设提示模板）。对「接知识库」这件事，最常用的是 tool。
一个知识库怎么变成 MCP 服务
对琅嬛来说，这一步就是把已有的检索与导入接口，用 MCP 的 tool 语义重新包装一层：检索是 knowledge_search，导入是 document_ingest，查状态是 document_status。客户端拿到的是一份标准的工具清单，而不是每个项目各写一套说明。
你不需要自己解析协议细节——握手、工具调用和错误返回都在 MCP 规范 里定义好了。工具端的实现可以到 琅嬛仓库 里核对。
一句话总结
MCP 不改变「工具能做什么」，它改变的是「工具怎么被调用」。当你的知识库以 MCP server 的形式存在，任何支持 MCP 的客户端都能直接使用它。这正是把知识能力变成基础设施的关键一步。
如果你的知识库还只是一堆私有 HTTP 接口，值得先问一句：换下一个 Agent 时，是不是又要重新写一套胶水？