bizfile

bizfile

初めて取引する会社について、その会社の説明が公的な登録情報によって裏付けられているか確認しておくと安心です。bizfile は、ホスト型の Jid MCP サービスに接続する小規模なローカルブリッジです。会社名または登録番号で企業ファイルを検索し、根拠として引用された事実とともにファイルを読み取り、署名付きのレシートを添えて取引の進行／要確認／中止の検証判断を求めたり、ID を指定して以前のレシートを取得したりできます。また、メールのヘッダーを決定論的にチェックし、申告された送信元から本当に送信されたかを確認できます。

お使いのマシン上で検証が行われることはありません。このパッケージは、取得済みのツール定義から tools/list への応答をローカルで返し、すべての tools/call をストリーミング可能な HTTP JSON-RPC セッション経由でホスト型サービスに転送します。サービスから返された内容は変更せずに返します。

このビルドは、対象を限定したサブセットです。取得済みの Jid の機能には 7 つのツールがありましたが、個人を審査する 2 つのツール、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 または会社名／登録番号で企業を検証します。任意で、申告された活動、管轄区域、金額も指定できます。活動を指定すると、理由と署名付きの receipt_id を含む判断（進行、要確認、中止、または insufficient_data）を返します。指定しない場合は、ステータスと引用された主要な事実を返します。
• get_receipt — 保存された Ed25519 署名付きの検証レシートを receipt_id で取得します。レシートには、入力、判断、理由、事実 ID と値のハッシュ、ルールのバージョン、チェック時刻が含まれます。
• check_email — 指定したメッセージの生ヘッダーをチェックします。受信サーバーが記録した DMARC／SPF／DKIM、From との DKIM の整合性、別ドメインの 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

1 つのバイナリで、コマンドラインと 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、不明なサブコマンド（省略されたツールを含む）や不正な JSON 引数など、使用方法に問題がある場合は 2 です。

設定

• 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 ヘッダーを付けて initialize リクエストに応答した場合、その値は以降のすべてのリクエストに引き継がれ、開いたセッションはプロセスが終了するまで再利用されます。応答は通常の 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

テストスイートでは、提供されるツール一覧を記録済みのツールと一つずつ照合し、除外された2つのツールがレジストリ、MCP、CLI の各レベルで存在しないことを検証します。また、セッションのハンドシェイクと再利用をテストし、キーのヘッダーに関する両方の分岐を網羅するとともに、引数が変更されずに上流へ送られ、結果が変更されずに返されることを確認します。

ライセンス

MIT — LICENSE を参照してください。Copyright (c) 2026 Rene Turcios。