2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

本文最初发布于 burn451.cloud。此处为同步转载。

构建 Burn 的模型上下文协议服务器：三种真正有效的模式

模型上下文协议（MCP）开源已有一年多。Cursor 在本月初发布了 Bugbot MCP 支持。Anthropic 发布了 2026 年路线图，明确将规范演进从固定的发布节奏转移到工作组中。而我自己的 burn-mcp-server 在 npm 上的安装量刚刚突破一千次。在所有这些事件的交织中，MCP 不再仅仅是“Anthropic 的新玩意儿”，而成为了我思考如何将任何产品暴露给智能体时的默认方式。

我开发了一款稍后阅读应用，名为 Burn 451。大约一个月前，我在 npm 上发布了 burn-mcp-server——它包含 26 个工具，让智能体能够阅读、分类和整理我保存的文章。过去 7 天：349 次安装。过去 30 天：1152 次安装。其中大部分是我自己使用，加上一小部分早期用户，人数少到我可以单手数出来。采用率曲线并不是本文的重点。重点在于，在从第一个工具到第二十六个工具的过程中，我做出了三个设计决策，防止了整个项目因自身复杂性而崩溃，我想在代码记忆尚新时将这些决策记录下来。

我并不是一名职业工程师。我使用 Claude Code 进行发布，我会阅读自己的代码差异，我会搞坏东西，然后修复它们。如果你正在构建你的第一个 MCP 服务器，你可能会在至少其中一个决策上做出相反的选择，这没关系——关键在于你要知道为什么做出这样的选择。

你应该如何向 MCP 客户端暴露数据——作为工具还是作为资源？

对于采取行动的智能体，工具胜出；对于只读的数据转储，资源胜出。而在实践中，我所关注的几乎每个 MCP 客户端都将工具视为一等公民，而将资源视为事后补充。我在 Burn 项目中选择了工具优先，如果重来一次，我依然会这样做。

以下是代码的实际样子。burn-mcp-server 注册了 26 个 server.tool() 调用和恰好 2 个 server.resource() 条目。这些资源暴露了 burn://vault/bookmarks 和 burn://vault/categories——即用户永久知识库的批量 JSON 转储。它们的存在是因为 MCP 规范规定应该有它们。在 30 天的生产使用中，我从未见过 Claude Code、Cursor 或 Windsurf 在实际操作中优先选择读取资源而不是调用工具，即使两者都被配置为返回相同的数据。

原因很简单。工具拥有 schema（模式）。智能体知道要传递什么参数、会得到什么返回结果，以及会产生什么副作用。资源是一个你需要获取的统一资源标识符（URI）；智能体必须猜测获取它是否有帮助。Claude Desktop 会很乐意在用户界面中列出你的资源，但在终端中运行的 Claude Code——这才是智能体真正工作的地方——大多数时候会忽略资源，除非你明确提示模型去查看它们。

因此，我将智能体可能想要调用的所有功能都推入了工具中。search_vault 带有查询和限制参数。list_flame 用于收件箱。get_flame_detail 用于完整文章提取。即使是批量视图也配备了工具（list_vault、list_categories），因为带有明确过滤条件的工具调用，比将整个知识库作为资源转储并让模型去其中搜索要高效得多。

资源仍然发挥作用的唯一领域是可发现性。当有人首次将 burn-mcp-server 接入 Claude Desktop 并打开 MCP 检查器时，这两个资源会作为一个提示出现：“此服务器有一个知识库，以下是其中的内容。”它们不是主力干将，而是迎宾垫。

如果你 a