bizfile

bizfile

在与一家刚认识的公司打交道之前，最好先确认公开登记信息是否支持对方的自我介绍。bizfile 是连接托管 Jid MCP 服务的小型本地桥接工具：你可以按名称或注册编号搜索企业档案，查看附有引用事实的档案，获取带签名回执的继续／复核／停止验证决定，按回执 ID 获取先前的回执，或者对电子邮件运行确定性的邮件头检查，看看邮件是否确实来自其声称的发件人。

所有验证都不会在你的本机上进行。此软件包根据捕获的工具定义，在本地响应 tools/list，并通过可流式传输的 HTTP JSON-RPC 会话将每个 tools/call 转发至托管服务，原样返回服务发送的内容。

此版本包含一个经过标注的子集。捕获的 Jid 工具集有七种工具；其中两种用于筛查个人的工具——qualify_counterparty 和 screen，会根据潜在客户或发件人的个人邮箱、电话、IP 地理位置和浏览器信号进行评分——不属于此重建版本，也不会在 MCP 层或 CLI 上注册。

工具

• search_business — 按名称或任意注册编号（FEI、LEI、SEC CIK、DUNS、NDC 标签持有人代码、州许可证或实体编号、法国 SIREN 或 SIRET）查找企业档案，并返回候选项、状态和匹配依据。传入国家代码 "FR" 时，还会实时搜索法国 SIRENE 登记库。
• get_business_file — 根据 Jid ID 返回一家企业的档案：状态和标记、标识符、已验证的网站，以及附带来源和验证日期的主要事实；或者将 detail 设为 "full"，以获取所有当前事实及其出处、所有者声明、可能的匹配项和变更历史。
• verify_business — 根据 Jid 持有的登记事实验证企业，可使用 ID 或名称／注册编号，并可选择提供所述活动、司法管辖区和金额。提供活动时，会返回一项决定（proceed、review、stop 或 insufficient_data）、理由和带签名的 receipt_id；未提供活动时，则返回状态和主要引用事实。
• get_receipt — 根据 receipt_id 返回已存储的 Ed25519 签名验证回执，内容包括输入、决定、理由、事实 ID 和值哈希、规则版本以及检查时间。
• check_email — 检查你提供的邮件原始邮件头：接收服务器记录的 DMARC／SPF／DKIM 状态、DKIM 与 From 的对齐情况、指向其他域名的 Reply-To，以及模仿知名企业的 From 域名或显示名称。根据捕获的说明，邮件头仅在内存中处理，绝不存储。

没有任何内置工具会进行购买、开通订阅、结账、生成密钥或筛查个人。

安装和运行

通过 npm 作为 MCP 服务运行：

npx -y @reneturcios/bizfile mcp

MCP 客户端配置：

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

作为容器运行：

docker run -i ghcr.io/cloudcorprecords/bizfile
docker run --rm ghcr.io/cloudcorprecords/bizfile get_receipt '{"receipt_id":"rcpt_123"}'

CLI

同一个二进制文件既可用于命令行，也可用于 MCP 服务。每个工具都是一个子命令，接受一个包含该工具参数的 JSON 字符串：

bizfile search_business '{"query":"Example Corp"}'
bizfile get_business_file '{"id":"example-corp-a1b2c3"}'
bizfile verify_business '{"id":"example-corp-a1b2c3","activity":"general_commerce"}'
bizfile get_receipt '{"receipt_id":"rcpt_123"}'
bizfile check_email '{"headers":"From: [email protected]\nSubject: hi\n"}'
bizfile --version

退出代码：转发的调用成功时为 0，上游结果为错误时为 1，用法有误时为 2，例如使用了未知子命令（包括省略的工具）或 JSON 参数格式错误。

配置

• JID_MCP_URL — 覆盖上游端点。默认值为固定的托管端点 https://jid.com/mcp。（该覆盖变量是此重建版本新增的。）
• JID_API_KEY — 设置后，其值会在每个请求中通过 Authorization: Bearer <value> 标头发送给上游。未设置时，则完全不发送密钥标头，这与捕获该工具接口时的无密钥行为一致。（变量名和 Bearer 形式均为重建内容；托管服务的注册记录声明了一个 Authorization 标头，但未标记为必需。）

上游故障——包括服务返回 JSON-RPC 错误、非 2xx 响应、响应正文无法读取或请求彻底失败——都会以错误结果的形式报告给调用方，文本以 bizfile error: 开头。

转发方式

首次转发调用会建立会话：先发送 initialize 请求（协议版本为 2025-03-26），再发送 notifications/initialized 通知，最后调用 tools/call。如果服务在响应初始化请求时返回 Mcp-Session-Id 标头，后续每个请求都会携带该值，并在进程的其余运行期间复用已建立的会话。响应可以是普通 JSON，也可以是服务器发送事件。成功结果会原样传递，包括任何 isError 标志和服务提供的任何额外字段。

开发

npm install
npm run build   # tsc -> dist/ (dist/cli.js is the bin)
npm test        # tsx --test test/*.test.ts — stubbed upstream, no network
npm run dev     # run the CLI from source

测试套件会逐项检查所提供的工具列表是否与捕获的工具接口一致，断言被省略的两个工具在注册表、MCP 和 CLI 层面均不存在，测试会话握手及其复用，覆盖两种密钥标头分支，并验证参数未经修改地发送至上游，结果也未经修改地返回。

许可证

MIT — 参见 LICENSE。版权所有 (c) 2026 Rene Turcios。