比特币温度计进了MCP：3步判断能不能用
2026 年 10 月 23 日，awesome-mcp-servers 合并了编号为 #16883 的提交，把 NakamotoNotes Bitcoin Barometer 加进 MCP 服务清单。10 月 22 日，Glama 的 MCP 页面已经出现该项目。两者只相隔一天，这是我的日期差计算；为什么现在值得看？因为一个面向普通用户的比特币综合指标，刚刚进入了更容易被 AI 客户端发现和调用的 MCP 生态。
不过，这次提交只改了清单中的 README.md：官方仓库页面显示，它增加了 1 行，删除 0 行。它不是 NakamotoNotes 宣布功能升级，而是一次收录。对使用者来说，真正该看的不是“又被推荐了”，而是这个服务提供什么、公开页面是否一致，以及怎样接入自己的 MCP 客户端。
一次目录收录，不等于一次产品发布
GitHub 提交页面显示，提交标题是“Merge pull request #16883 from multiassist/add-nakamotonotes-barometer”，内容则是把 multiassist/nakamotonotes-mcp 加入清单。提交页还记录了两个父提交，并显示这次变更只涉及一行 README。
这意味着什么？这是我的判断：GitHub 提交能证明“清单收录发生了”，不能单独证明 Barometer 的算法、数据源或接口在当天发生了变化。产品功能应以项目自己的说明和公开接口为准。
Glama 的项目页给出了工具的参数与输出结构，并从代理使用角度评价工具描述，包括用途是否清楚、参数是否解释充分。它把 Purpose 标为 4/5，把 Parameters 标为 3/5。这组评分不是产品性能评分，而是目录方对“Agent 能否正确理解并调用工具”的检查结果。
因此，普通用户看到的“进入热门清单”，更接近一次可发现性提升，而不是投资信号突然变得可靠。
一个温度计，为什么值得接进AI客户端
NakamotoNotes 官方首页的 Bitcoin Barometer 仪表盘把链上、技术和情绪指标合成为 0—100 的分数，用它表示比特币当前处于历史低位积累区（Chill Zone）还是过热危险区。页面自带 0% / 25% / 50% / 75% / 100% 的刻度，抓取时当日读数是 23（Chill Zone），当日 BTC 价格 $77,615。
关于”什么时候写的”和”几个指标”，这里必须说清两件事：
其一，原来那篇专门讲这个指标的官方博文现在已经下架（服务端返回 Gone 状态，链接打不开了）。所以任何挂在它上面的发布/更新日期都无法再核验 —— 我早前版本引用的那个日期正是从那篇推来的，现在已无法证实，应当作废，不应再出现在正文里。
其二，能核验的只有当前首页：页面标题写 “Across 8 Indicators”，而同一页面的日期行写 “from 10 indicators”。至于 On-chain Indicators 占 40% 权重这个说法，我没能在一个可访问的官方页面上核实到，因此这里不引用它。
项目在 awesome-mcp-servers 的收录说明中列出的可见指标包括 MVRV Z-Score、NUPL、Puell、Mayer Multiple、Fear & Greed，并提供 BTC 价格、底层指标和从 2014 年起的每日历史。这个服务被描述为只读，不需要 API key，同时提供自托管地址和远程托管地址。
对 AI 客户端来说，价值不在于多了一个聊天话题，而在于 Agent 可以直接取得结构化数据。例如，用户问“现在比特币的热度如何”时，客户端不必搜索网页、拼接多个指标，再自行决定如何加权；它可以读取服务给出的快照、区间和历史记录，再把结果整理成普通人能读的解释。
但这仍然只是“数据入口”。按项目自己的定位，它描述的是当前状态相对于自身历史的位置，不是价格预测，也不是投资建议。AI 可以提高读取和解释效率，却不能把综合指标自动变成可靠收益预测。
8个还是10个：公开信息有一处冲突
跨源对比后，最值得警惕的不是功能，而是口径不一致。
这里有个值得单独拎出来的发现：“8 还是 10″这个矛盾不在第三方目录，而在 NakamotoNotes 自己的页面上。
NakamotoNotes 官方首页上，页面标题写的是 “Bitcoin Barometer Dashboard — Market Sentiment Across 8 Indicators“，而同一页面的日期行写的是 “0-100 market heat from 10 indicators · how it’s calculated”。同一张官方页面，两处数字对不上。
第三方目录那边同样有 10 的说法 —— unyly.org 的 MCP 目录页写 10 个指标，并声称服务会返回 Heat Score、区域、BTC 价格的 24 小时与 7 天变化、指标值与热度以及每日历史。
| 核对项 | NakamotoNotes 官方页面 | 收录与目录页面 | 使用者应如何理解 |
|---|---|---|---|
| 综合指标数量 | 页面标题写 8 个、日期行写 10 个（同一页面内部就不一致） | unyly 写 10 个 | 数量口径不一致，不能自行补齐 |
| 分数范围 | 0—100 | 0—100 | 两边描述一致 |
| 历史数据 | 博客介绍每日历史 | 收录说明称始于 2014 年 | 可确认存在历史入口，具体覆盖需查接口 |
| 部署方式 | 未在所给正文详述 | 收录页同时列出本地与远程地址 | 可按客户端环境选择 |
| 数据性质 | 用于判断历史位置 | 目录页明确不是预测或投资建议 | 适合解释现状，不适合直接生成买卖结论 |
这是我的跨源判断：公开页面的分歧不一定意味着数据错误，可能是官方博客与目录介绍采用了不同版本或不同统计口径。但在真正接入前，应以 MCP 工具自己的输出结构和当前接口返回值为准。尤其是“8 个还是 10 个”，不能根据常识猜，更不能替官方选一个数字。
日期差也可以复算：
目录页发布日期：2026-10-22
GitHub 收录提交：2026-10-23
时间差：1 天这只是解释传播节奏，不代表两个事件存在技术依赖。
3步判断是否适合接入
第一步，看客户端是否支持 MCP。这个项目提供 stdio 方式配置，unyly 目录页给出的配置如下：
{
"mcpServers": {
"nakamotonotes": {
"command": "npx",
"args": ["-y", "@nakamotonotes/mcp"]
}
}
}第二步，核对数据访问方式。公开目录页称服务读取 https://nakamotonotes.com/open/barometer.json，不需要 API key，也不收集个人数据；收录说明同样写明无需 API key。对只想查询公开市场指标的普通用户，这是明显优点。对企业环境，则还要确认所在网络是否允许访问远程数据，以及团队的数据使用要求。
第三步，先看返回字段，再允许 Agent 写结论。目录页列出的工具包括 get_market_snapshot、explain_indicator 和 get_history。建议先分别调用一次，检查当前分数、区域、价格变化、指标明细和历史区间是否齐全，再测试自然语言问答。若代理把“过热”直接翻译成“应立即卖出”，就应增加约束：解释信号含义、展示历史背景、说明局限，而不是输出投资指令。
还要注意一个目录层面的矛盾：unyly 页面一方面展示了 npx -y @nakamotonotes/mcp，另一方面又写“没有发布包，需要从源码构建”。这是社区目录的公开说明，不是项目官方安装文档；实际运行前，应优先核对 multiassist/nakamotonotes-mcp 仓库中的 README，不要把目录页的安装命令视为已经验证过的部署保证。
把“数据可读”留在“结论可信”之前
这次收录最实际的变化，是比特币综合温度计从网页产品进入了 MCP 的工具候选集。普通用户由此多了一种清晰用法：让 AI 读取结构化快照、解释指标、查询历史，而不是自己翻找多个页面。
但目录评分、收录事件和综合分数分别回答三个问题：Agent 是否容易理解工具、工具是否容易被发现、数据是否适合支持判断。它们不能互相替代。接入时最稳妥的顺序是：确认 MCP 兼容性，核对实际返回结构，再用历史数据检验解释是否稳定；涉及投资决策时，把 0—100 分数当作辅助信息，而不是单独的行动信号。
参考来源
评论区
登录后可评论。