labelproof

labelproof

labelproof は、製品を出荷または出品する前に、 公開 EPREL 登録簿にエネルギーラベルについて 実際に何が記載されているかを確認し、確認した 内容を正確に記録として残せるようにします。

EPREL に登録されているのは、サプライヤーが申告した記録です。ブランド、モデル、 申告されたラベルおよび製品シートの値が含まれます。 これらの情報は独立して検証されておらず、このツールも その前提で扱います。検索結果では候補となる レコードを明示的な一致種別とともに返すため、見つからない場合も 「照会したソースに一致するレコードがない」と表示され、 「未登録」とは表示されません。比較では、共通する申告値を 単純な表にまとめ、優劣は判定しません。レシートツールでは、 独自の検索結果をまとめ、何をいつ検索したかを記録した 署名付きの冪等な記録を作成できます。ここで得られる情報はすべて 事前確認の証拠に限られます。このパッケージは、適合性、CE マーキング、GPSR、 安全性に関する問題、市場参入の可否を判断するものではありません。

検索処理自体は、ホスト型の事前確認サービスで実行されます。 このパッケージはローカル側の部分であり、このサービスの インターフェースを保存したコピーから tools/list に応答し、 すべての呼び出しを上流に中継して、応答を変更せずに返します。

ツール

• search_eprel_products — modelIdentifier、registrationNumber、または productGroup で絞り込んだ supplierOrBrand を指定して、公開レコードの候補を検索します。テキスト検索では、ライブソースが一度に1つのグループを検索するため、製品グループの指定が必要です。登録番号による検索には不要です。保存されたスキーマでは、すべての引数が任意です。一致結果には exact_public_record、possible_match、multiple_matches、no_match_in_queried_source のいずれかが付与されます。ソースが正常に応答できない場合は、unavailable、source_schema_unverified、stale の状態が返されます。
• get_eprel_product_record — publicRecordId で候補を1件指定し、申告されたサプライヤーとグループ、申告フィールド、ドキュメント、欠落フィールド、出典情報および鮮度を含む構造化レコードを取得します。
• get_eprel_energy_label_data — publicRecordId で指定したレコードの申告済みラベルおよび製品シートの値を取得します。応答では、データがサプライヤー申告のものであり、独立して検証されていないことが明記されます。
• compare_eprel_product_metrics — 2～5件のレコード（publicRecordIds。必要に応じて metricKeys で絞り込み）について、共通する指標を並べて比較します。製品グループが異なるレコードは incompatible_comparison として安全に処理され、使用可能な識別子が2件に満たない場合は insufficient_identifiers が返されます。
• prepare_energy_label_preflight_receipt — 一連の検索結果を証明する記録を作成します。bundle（生のクエリ値を含まない、指紋付きの証明対象結果）と createdAt（バンドルを作成した ISO タイムスタンプ）が必要です。署名付きレシートには、入力、レコード参照、ソース、鮮度、判定状態が記録されます。これは確認を行った証拠であり、結果を証明するものではありません。

設定

• EU_ENERGY_MCP_URL（任意）— 上流エンドポイントを置き換えます。既定値は https://energy.mcp.jithox.com/mcp です。このオーバーライド用フックは、この再構築によるものであることを明記しています。
• EU_ENERGY_API_KEY（任意）— 設定すると、すべてのリクエストでその値が上流に Authorization: Bearer <value> として送信されます。未設定の場合、キーのヘッダーがマシンから送信されることはありません。Authorization ヘッダー名は元のサービスのレジストリレコードで宣言されていますが、そのレコードにはパッケージの環境変数が記載されておらず、インターフェースもキーなしで取得されています。そのため、環境変数名、Bearer 形式、および転送処理は、この再構築によるものであることを明記しています。

転送の仕組み

最初の呼び出しでは、上流とのストリーミング可能な HTTP JSON-RPC セッションを開きます。initialize リクエスト （protocolVersion 2025-03-26、clientInfo name labelproof）、notifications/initialized 通知、続いて指定された引数をそのまま含む tools/call リクエストを送信します。上流から Mcp-Session-Id が発行された場合、それ以降の すべてのリクエストに付与され、プロセスの残りの期間は セッションを再利用します。プレーンな JSON 形式と サーバー送信イベント形式の両方の応答に対応しています。

上流の結果は、上流で設定された isError フラグも 含め、そのまま返されます。ローカルのリレーで発生したエラー （上流の JSON-RPC エラー、2xx 以外の応答、読み取れない 本文、または完了しないリクエスト）は、テキストが labelproof error: で始まる isError 結果として返されます （この再構築版のラベル付き表現です）。

CLI

各ツールは、JSON 引数文字列を 1 つ取るサブコマンドとしても使えます。

npx @reneturcios/labelproof search_eprel_products '{"modelIdentifier":"WM-100","productGroup":"washingmachines"}'
npx @reneturcios/labelproof get_eprel_product_record '{"publicRecordId":"rec-42"}'
npx @reneturcios/labelproof prepare_energy_label_preflight_receipt '{"bundle":{"lookups":[]},"createdAt":"2026-10-28T09:00:00Z"}'
npx @reneturcios/labelproof --version

終了コード：エラーのない結果は 0、isError の結果は 1、 使用方法のエラーは 2 です。

MCP サーバー

npx -y @reneturcios/labelproof mcp

MCP クライアントの設定：

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

Docker

docker run -i ghcr.io/cloudcorprecords/labelproof
docker run --rm ghcr.io/cloudcorprecords/labelproof --version

イメージはデフォルトで mcp コマンドを実行するため、最初の形式では stdio MCP サーバーが起動します。それ以外の引数は CLI に渡されます。

開発

npm install
npm run build
npm test
npm run dev

テストでは上流の JSON-RPC サービスをスタブ化しており、テストスイートから 実際のネットワーク呼び出しが行われることはありません。

ライセンス

MIT — LICENSE を参照してください。