cryptocapi

带有可验证印记的加密货币市场分析，以原生工具的形式提供给任何支持 MCP 的 Agent。
每个回复都会附带其输入的 SHA-256，因此分析可以重新计算和核验：无需相信模型。

开始使用  ·  工具  ·  演示  ·  验证印记  ·  配置  ·  cryptocapi.com

复制这段即可运行

无需账户、无需注册、无需密钥。将其放入你的 MCP 客户端配置文件中：

{
  "mcpServers": {
    "cryptocapi": {
      "command": "npx",
      "args": ["-y", "@cryptocapi/mcp"]
    }
  }
}

这样就可以询问 Agent 关于 Bitcoin 或 Ethereum 的信息，并获得由两个分析引擎签署的分析。演示的具体范围见下文。

你会用 Claude 分析交易吗？这份指南 使用 Claude 构建交易机器人，不编造价格 提供了示例请求，以及防止模型编造数字的规则。

四种工具、三个引擎和 Market Scan

工具	引擎	返回内容	所需条件
get_insight	Radar	对某项资产的分析。alpha 视图附带签章	pulse 无需通行证，只需免费 key · alpha 需要 Radar Alpha 通行证
get_insight，并设置 engine="quant_plus"	Quant Plus	由确定性引擎签署的同一项资产分析，附带 reproducible 签章	Quant Plus 通行证
batch_signals	Quant Plus	一次调用返回多项资产的信号	Quant Plus 通行证
get_signal	Quant Pro	一个交易对的量化信号	Quant Pro 通行证
scan_market	Market Scan（排名层）	根据某种策略对市场进行排名	Market Scan 通行证

这里有五行，却只有四种工具，因为 get_insight 是两个引擎的入口，而每个引擎都需要各自的通行证。拥有 Radar Alpha 并不会因此开放同一工具的 Quant Plus：更改 engine 参数，所需的通行证也会改变。

**Market Scan 不是第四个引擎。**它不会计算自己的信号，而是根据 Quant Plus 的信号对市场进行排序。它作为另一款产品单独销售。

那么 get_market_summary、get_prices 和 get_macro 呢？

截至 2026-08-30，另外还有三种工具（get_market_summary、get_prices、get_macro），用于返回第三方数据：市值和恐惧与贪婪指数、CoinGecko 价格，以及 FRED 宏观数据序列。它们已被移除，因为 CryptoCapi 不是聚合器：其引擎会签署衍生情报，外部数据只是内部输入。Agent 问“市场行情如何？”时，会拿到摘要，然后直接带着第三方数据离开，完全没有调用引擎。这些端点仍存在于 REST API 中；移除的是让 Agent 将它们视为工具这一功能。

**每个引擎都需要单独购买，因此拥有其中一个并不会开放其他引擎。**工具说明会写明所需的具体引擎，而不是笼统地写“PRO”，这样 Agent 就不会把调用次数浪费在其 key 无法使用的工具上。如果 Agent 仍然尝试调用，错误信息会说明缺少哪种通行证、已拥有哪种通行证，而不是只返回一个空洞的 403。

请注意一个会导致 Agent 调用失败的格式细节：get_signal 接收交易对（BTCUSDT），而 batch_signals 接收币种标识符（bitcoin）。它们使用同一个引擎，但格式不同；各字段的架构中都有说明。

无需注册即可试用

默认配置使用公开的演示 key。无需账户。

{
  "mcpServers": {
    "cryptocapi": {
      "command": "npx",
      "args": ["-y", "@cryptocapi/mcp"],
      "env": { "CRYPTOCAPI_API_KEY": "demo_btc_eth_public" }
    }
  }
}

env 是可选项：不设置任何变量时，软件包会自动使用公开的演示 key，因此只需填写 command 和 args。

截至 2026-08-30，使用演示 key 可用的功能（依据已发布版本）：

引擎	工具	使用演示 key 时
Radar	get_insight	✅ 仅限 bitcoin 和 ethereum，始终使用带签章的 alpha 视图，即使请求的是 pulse
Quant Plus	get_insight?engine=quant_plus	✅ 仅限 bitcoin 和 ethereum，带有可复现签章及 input_vector
Quant Plus	batch_signals	✅ 仅限 bitcoin 和 ethereum，可用范围与 get_insight 相同
Quant Pro	get_signal	❌ 已关闭，任何交易对都不可用
Market Scan	scan_market	❌ 已关闭，任何策略都不可用

后面三种工具不会因币种而失败，而是始终失败：使用 Bitcoin 的交易对 BTCUSDT 调用 get_signal，同样会返回 403。仅 get_insight 受限于 bitcoin 和 ethereum。

也就是说，首次会话中四种工具里只有一种会响应，而它展示的正是产品核心功能：由两个引擎签署的 Bitcoin 分析。

如果要不受币种限制地试用三个引擎和 Market Scan，需要注册免费的 14 天试用，网址为 https://www.cryptocapi.com。试用期间，这个 key 可以使用全部功能。

有何不同

引擎的响应会附带一个 audit_trail，其中包含 protocol_hash：这是生成分析的确定性计算的印记。此软件包会原样转发从 API 收到的这些值，不会重新序列化，因为哪怕只重新格式化一个数字，都足以导致哈希验证失败。

不用光听我们说：让你的 Agent 使用 get_insight(coin_id="bitcoin", view="alpha") 获取分析，然后将输出中的 protocol_hash 与直接调用 API 进行同一查询得到的值进行比较。

curl -H "x-api-key: demo_btc_eth_public" \
  "https://api.cryptocapi.com/v1/market/insights/bitcoin?view=alpha"

两者必须完全一致。如果哪天不一致，那就是此软件包的故障，值得提交一个 issue。

**也说明一下边界：**这个印记能证明计算可复现，且并非由大模型编写。它不能证明分析准确；而且目前它只是一个没有数字签名的校验和，因此证明的是完整性，而非来源。

软件包本身也经过验证

印记保护的是数据。至于你下载的 tarball 是否确实由这份代码生成，则由另一套机制保障：软件包通过 CI 和 npm 来源证明发布，因此每个版本都会关联到构建它的 commit 和 workflow。

npm audit signatures

npm 上的软件包页面还会显示指向确切 commit 的链接。这与 protocol_hash 遵循的是同一原则，只不过应用于供应链，而不是数据：不用光听我们说，可以自行验证。

配置

变量	用途	默认值
CRYPTOCAPI_API_KEY	你的 API key	demo_btc_eth_public
CRYPTOCAPI_API_BASE	API 基址，用于开发	https://api.cryptocapi.com/v1
CRYPTOCAPI_TIMEOUT_MS	每次请求的时间预算，单位为毫秒。见下文	因工具而异

**时间预算并非只有一个。**每种工具都有自己的预算，因为它们的耗时不同：针对单个资产的引擎需要 20 秒（get_insight、get_signal），而遍历多个资产的工具需要 45 秒（batch_signals、scan_market）。 用单次读取的预算来中断市场扫描会造成虚假的超时，导致 Agent 以为 API 已经宕机，而实际上它仍在处理请求。

CRYPTOCAPI_TIMEOUT_MS 会替换这些预算，而不是在其上累加：你设置的数值会应用于全部四种工具。将它设为 30000 来给 scan_market 更多时间，实际上会缩短其预算，从 45 秒降至 30 秒。如果要调整，建议设置为高于最高预算的值。

工具超时后，错误信息会显示实际生效的预算，因此你需要设置高于该数值的值。

获取 14 天试用 key：cryptocapi.com

开发

npm install
npm run check      # tipos + tests + auditoría de dependencias
npm run contrato   # verifica contra la API real que el contrato copiado sigue vigente

测试使用 Node 原生运行器运行，没有任何测试依赖，也不会访问网络：API 由 node:http 模拟。它们测试的是软件包，而不是服务，因此运行快速且稳定。

该运行器会直接加载 TypeScript，不进行转译，因此开发需要 Node 22.18 或更高版本，尽管发布的软件包可以在 20 上运行：这是 engines 声明的要求，也是 CI 通过在 20、22 和 24 上启动构建产物来验证的内容。这是开发要求，不是使用要求。

因此，特意将另一半留在范围之外：验证发布的软件包能否与真实 API 及 Agent 配合良好。为此准备了 PRUEBAS.md，其中包含十四项手动检查，每次发布后都会运行。

npm run contrato 无需人工介入即可覆盖这一半的一部分。 测试有意不访问网络，而这种隔离存在一个盲点：2026 年 9 月发现了四个 bug，其中三个涉及真实 API 实际发送的内容与软件包的假设不符；只会返回测试中写入内容的模拟服务无法发现这些问题。契约检查正是检查这一点，每天只运行一次，如果发现有变化就会创建 issue。

已发现但尚未修复的问题记录在 PENDIENTES.md 中，其中说明了每项问题的原因，并提供了足够的信息，方便日后继续处理，无需重新调查。

发布

发布由 tag 触发，CI 会带来源信息地发布到 npm 和 MCP Registry：

npm version <patch|minor|major>   # subir también las dos versiones de server.json, y commitear
git tag -a vX.Y.Z -m "vX.Y.Z" && git push origin vX.Y.Z

工作流会先检查 tag 是否与 package.json 中的版本以及 server.json 中的两个版本一致，因为npm 上的版本无法重复使用，而这个错误无法撤销。认证使用基于 OIDC 的 trusted publishing，无需 token：它与 release.yml 的文件名绑定，因此重命名该文件会导致发布失败。

npm 发布成功后，第二个 job 会通过 OIDC 将 server.json 发送到 Registry。该步骤单独运行，这样如果 Registry 出错，「Re-run failed jobs」就只会重试这一步，而不会再次执行 npm publish。

对于服务端，npm version 是版本号的唯一来源：它会读取已发布的 package.json 来声明 serverInfo.version，而握手测试会在两个版本号不一致时失败。唯一手动填写的版本号位于 server.json 中；如果它落后了，tag 就无法通过第一项检查。

版本管理

从 1.0.0 起，该软件包遵循 semver。契约包括四个工具、它们的参数以及响应格式：

• 补丁版本（1.0.x）： 修复和文本调整。工具及其参数保持不变。
• 次版本（1.x.0）： 不会破坏现有功能的新内容，例如新增工具或可选参数。
• 主版本（2.0.0）： 移除或重命名工具，或更改现有参数。如果有此需要，会提前通知。

响应会原样传递 API 提供的内容，因此即使软件包没有发布新版本，响应中也可能出现新字段。

许可证

MIT

cryptocapi.com  ·  npm  ·  问题