mcpField
A
Agent Receipt Verify

Agent Receipt Verify

ローカル
github.com金融データ02 日前に更新
リポジトリ公式サイト

Agent Receipt Verify について

Agent Receipt Verifyは、AIエージェントが使う支払い・結果レシートを独立して検証します。支払い前のエンドポイント適合性確認と、支払い後のレシートと決済の照合を行い、未測定と失敗を区別します。

主な機能

  1. 01x402エンドポイントの適合性確認
  2. 02レシートと決済の照合
  3. 03公開済み検証ベクトルの実行
  4. 04未測定の結果を明確に表示

活用シーン

  1. 01AIエージェントの支払い前にx402エンドポイントを確認
  2. 02レシートが決済に対応するか検証
  3. 03プロトコルのベクトルを使った検証器の相互確認

MCP 対応

MCPサーバーは、支払い前の確認用`check_x402_endpoint`と、支払い後の検証用`link_receipt_to_settlement`を提供します。標準入出力で通信します。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

インストール方法は未掲載です

このサーバーのパッケージやリモートエンドポイントはまだ取得できていません。プロジェクトの README の手順に従ってください。

リポジトリ
パッケージ
mcpbagent-receipt-verify-0.2.1.mcpb0.2.1

ツール

ツール一覧はまだ取得されていません

ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。

詳細

agent-receipt-verify

AI エージェントが使用する、支払いおよび成果証明のレシートを独立して検証します。

1 行で実行

npx -y agent-receipt-verify https://api.bitrefill.com/x402/gift-cards/search

アカウントもキーも支払いも不要です。このエンドポイントが x402 の定める方法で支払いを要求しているかを示します。また、実際の決済が必要なレベルについては、失敗と判定せずに NOT MEASURED と表示します。

このツールが行わないこと：レシートの形式を判定するものであり、発行者の誠実さを判定するものではありません。意図的に測定対象から除外している内容については、CONFORMANCE.md を参照してください。

npx -y agent-receipt-verify attempt-identity   # 19 vectors for x402 spec section 5.5
npx -y agent-receipt-verify link-vectors       # 12 vectors, receipt to settlement
npx -y agent-receipt-verify kanon              # cross-check against iamonuwa/kanon

これは何か

エージェントエコノミーには 2 種類のレシートがあります。1 つは誰に行動が許可されたかを示すもの（委任：UCAN、Authproof、Agent Passport）です。もう 1 つは、何に対して支払いが行われたか、そして出力が要件に合致しているかを示すものです（決済と成果：x402 offer-receipt、INAM の相互署名付きレシート、ERC-8004 の利用者が集計する証明）。

receipt-commons/receipt-interop は前者を扱います。このツールは後者を扱います。

エージェントから使う：MCP サーバー

どちらのチェックも Model Context Protocol サーバーとして利用できるため、人がコマンドを実行する代わりに、エージェント自身が実行できます。stdio 経由で MCP を使用し、プロトコルバージョンは 2025-11-25 です。フレーミング、initialize、tools/list、tools/call は、MCP SDK を使わず、必須の依存関係も一切なしで、src/mcp-server.mjs に直接実装されています。

エージェントが実際に答えを必要とする 2 つのタイミングに対応する、2 つのツールがあります。

check_x402_endpoint は、支払い前に使います。1 回リクエストを送信し、CONFORMANCE.md の階層のうち、エンドポイントがどのレベルに達しているかを報告します。実際の決済が必要なレベルは、失敗ではなく未測定として返されます。

link_receipt_to_settlement は、支払い後に使います。レシート、認可ソルト、支払いに使用したアセットを受け取り、ライブのチェーン状態を参照してソルト付きコミットメントを解決し、リンク済み、リンクなし、確認できず、のいずれかを回答します。この 3 つはそれぞれ異なる回答であり、2 つにまとめられることはありません。

クライアントに追加します：

{
  "mcpServers": {
    "agent-receipt-verify": {
      "command": "npx",
      "args": ["-y", "github:holistis/agent-receipt-verify", "mcp"]
    }
  }
}

アカウントも API キーも不要で、npm への公開もありません。git ref から Node を実行したくない場合は、Dockerfile もあります：

docker build -t agent-receipt-verify . && docker run -i --rm agent-receipt-verify

サーバーはポートを開かず、ディスクにも何も書き込みません。プロトコルフレーム以外のものはすべて stderr に出力します。stdout はクライアント専用です。npm test は 21 ケースで、実際のフレームを使ってサーバーをテストします。未知のツール名、返信してはならない通知、未知のネットワークも含まれます。未知のネットワークには「リンクなし」ではなく「確認できず」と回答する必要があります。

ethers はオプションの依存関係で、check_x402_endpoint 内の署名チェック 1 つに使用されます。これがない場合、そのチェック 1 つは合格ではなく未測定を報告します。それ以外はすべて変更なく動作します。

独立した実装が重要な理由

販売者が署名したレシートは、利害関係者による主張です。署名者ではない第三者が再計算し、同じ結論に達したときに初めて証拠になります。そのため、ここにあるすべての検証ツールは、リファレンス実装のソースではなく公開仕様に基づいて記述され、プロトコルの作成者自身が公開したベクターファイルを使ってテストされています。

互いのコードを見ていない 2 つの実装が同じベクターで一致すれば、それが相互運用性です。1 つの実装が自分自身と一致しても、何の証明にもなりません。

独立してこのプロジェクトに取り組んだ人々

以下は、ここでの主張ではなく、他の人々がこのプロジェクトについて述べている内容です。各行は、開いて確認できるリンクです。

  • INAM は、自らの検証ツールドキュメントで、SPEC.md を基に、同社のソースコードを使わずに作成した独立した実装として本プロジェクトを挙げています。また、コードを監査していないこと、ベクトルは自分で実行するべきであることも記しています：docs/VERIFIER.md
  • goun7 は、自身のベクトルドキュメントの誠実な制限事項のセクションで、本プロジェクトの測定値を2つ取り上げ、こちらの表現をそのまま使っています：TEST-VEKTOR-KOK-COMPUTE-WORK.md
  • iamonuwa は、Kanon から本プロジェクトのレシートから決済までのコーパスにリンクすることを、推奨ではなく補完的なセットとして決め、2つの形式を互換性のあるものに保つことにしました：kanon#32
  • babyblueviper1 は、ここで報告された拒否をデプロイしました。表示名があり、キー ID のないプロデューサーが、決済確定前に拒否されるというものです：erc-8004#99

このうち2件には、繰り返し伝える価値のある注意書きがあります。Kanon の README へのリンクはイシュー内で言及されていますが、まだ公開されていません。また、INAM はこのコードを監査していないことを明言しています。どちらも、意図してそのように記載されています。確認した人の一覧は、その人たちが何をしなかったかも記されているほうが、より価値があります。

状況

形式ベクトルの提供元ケース数判定の一致
INAM countersignedinamprotocol/inam-protocol @ d5e5f4544 / 4、一致しないチェックのセットも同一
x402 offer-receipt（commitment §5.6、PR 3827 で提案）x402-foundation/x402 @ 0e492d6、main には未反映公開例1件と独自のエッジケース6件はい、バイト単位で一致
x402 settlement link（§5.6.4、同じ提案）独自テストと実際の決済3件オフライン22件、実際の決済3件はい、それぞれが対応する決済に解決
npm test      # all of the above. No account, no key, and nobody else's server

keccak256 を除き、Node の組み込み機能のみを使用しています。「ネットワーク接続なし」というのは完全には正しくなく、このパッケージでは曖昧に主張すべきでない種類のことなので、正直な注記を2つ添えます。

  • 1つのケースでは、応答しないアドレスがツールをクラッシュさせずに「未測定」を返すことを確認するため、意図的に localhost の閉じたポートへ接続します。これはソケットを使用しますが、マシンに影響を与えず、第三者にも接続しません。
  • 最近まで、このテストスイートは他者が所有する、約2万件のエントリを含むライブのディスカバリーインデックスも取得していました。あるテストが census に未知のフラグを渡し、census が未知のフラグを無視して処理を続けていたためです。現在はそのフラグが拒否されるため、テストスイートは約11秒で完了し、どこにも接続しません。以前は、インデックスを1回取得するだけで30秒以上かかっていました。

以下の決済リンクだけが実ネットワークに接続します。その場合も、公開された読み取り専用 RPC のみです。

表の内容より重要な、相手側での確認結果です。x402 仕様の作成者は、この実装とコードを共有しない自身の実装を使い、以下の実際のレシート3件すべてを検証し、§5.6.4 の要件どおり、レシート、ソルト、アセットを起点として同じ3つの決済にたどり着きました。その結果とこちらの結果は、x402#3827 に記載されています。

アカウントなしで自分で再計算する

相互検証のうち2つは、単一のコマンドでオフライン実行できるため、ここに書かれた内容を何も疑わずに信頼する必要はありません。

npx -y agent-receipt-verify kanon
npx -y agent-receipt-verify beleid
npx -y agent-receipt-verify link-vectors

1つ目は、当社のEIP-3009検証ツールをiamonuwa/kanonの公開済み10個のベクトルと照合します。2つ目があるのは、一致していても疑問が残るためです。これら10個のベクトルはすべて過少支払いのみを対象としているため、過払いについても、1つのnonceが2人の支払者間で再利用された場合についても何も示していません。これらはx402#2725にある2つの未解決の疑問であり、このコマンドは、2つの考えられる答えがどこで異なり、どこで異ならないかを正確に出力します。

把握しておくべき適用範囲があります。high-sルールと署名者の復元が適用されるのは、コードを持たない支払者です。USDCは支払者のコードに応じて検証方法を選びます。コードがなければecrecover（high-s署名はrevertします）、コードがあれば支払者のコントラクト上でERC-1271 isValidSignatureを使います。そのため、スマートウォレットやEIP-7702の委任を受けた通常のアドレスを、署名の形式を理由に拒否してはいけません。コンテキストでpayerHasCode: trueを渡すと、検証ツールは両方のルールをスキップし、引き続き有効期間、金額、nonceを検証しますが、VALIDとは決して回答しません。署名自体はチェーンへの呼び出しによってのみ検証されるため、ongemetenと回答します。現在はすべての回答にpayerScope（code、no-code、unknownのいずれか）が含まれます。unknownはno-codeと同様に扱われ、その旨が示されます。この点はrobertolocatelli81-devがx402#3925で指摘したもので、最初のバージョンにも当てはまっていました。

3つ目は、支払い後半に関する12個のベクトルを実行します。このレシートは、その1件の決済に紐づくものか、という検証です。うち11個はネットワーク接続が不要です。12個目はチェーンを読み取りますが、失敗として報告するのではなく、実行できなかった検証はレシートについて何も示さないため、印を付けてスキップします。同じ12個はKanonベクトルのフィールド形式でもvectors/settlement-link-kanonに用意されているので、2つのデータセットを並べて確認できます。

さらに2つのコマンドがあります。どちらも自分たちではなく他者のエンドポイントを測定し、読み取り専用です。

npx -y agent-receipt-verify census [out.json]
npx -y agent-receipt-verify liveness [out.json]

censusはリソースごとではなくHOSTごとに検出インデックスを数えるため、パスが300個ある事業者が、事業者300社を上回ることはありません。livenessはその調査結果を受け取り、各ホストに対して今日も402を返すかを確認します。インデックスへの登録は、エンドポイントが稼働中である保証ではないためです。どちらも意図的に時間がかかります。その一覧にあるホストは測定を依頼していないため、リクエストの間に待機します。

レシートを決済に紐づける

transactionフィールドが空のレシートは、支払者、受取人、金額、時刻だけで支払いと照合できます。同じブロック内で条件が同じ2つの支払いは、まったく区別できません。x402のオファーレシート拡張のセクション5.6は、ERC-3009 nonceへのソルト付きコミットメントによってこの問題を解決します。ソルトを持つ人は、リンク先がただ1つの決済であることを再計算でき、それ以外の人には何もわかりません。

セクション5.6がどこにあるのかについては、読者が想定する場所ではないため説明しておきます。5.6から5.6.5までのセクションは、オファーレシート拡張のmainにあるバージョンには存在しません。存在するのは、現在オープン中のプルリクエスト3827のみです。したがって、ここで5.6を引用している箇所はすべて、公開済みの本文ではなく提案に照らして評価したものです。対象はそのプルリクエスト上のコミット0e492d6に固定されており、mainより4コミット先で、誰でも取得できます。マージ前に番号が変わる可能性はまだあります。レベル4と5では、プロファイルにこの点が記載され、ツールの出力にも明示されるため、公開済みの本文に基づく評価であるかのように結果が黙って提示されることはありません。

実際に重要になるのはセクション5.6.5です。誰にも開示されていないコミットメントは、依然として署名者による主張にすぎません。1つの決済に対して異なるソルトを持つ2つのレシートを発行したり、まったく開けないコミットメントを発行したりできるためです。そのため、決済を数えるコンシューマーが重複排除済みまたはSybil耐性のある件数を集計する場合、誰かが開示したコミットメントだけを数えられます。 以下は、同一条件の支払いを3件示したものです。同じ支払者、同じ受取人、同じ金額、同じリソースで、Base Sepolia 上で数分おきに行われています。コミットメントがなければ、これらのレシートを区別することはできません。それでも、それぞれが個別の決済に結び付きます。

npm run link-example

デフォルトのウィンドウは、レシートの issuedAt の前後800秒で、その地点付近で測定したブロック生成ペースを使ってブロック数に換算します。--window=<blocks> を指定すると、ブロック数で設定できます。公開ノードでブロックがプルーニングされている場合、コマンドはその旨を表示してから、同じログをキー不要のエクスプローラー（Blockscout）に問い合わせます。出力には、どのリーダーが応答したか（reader :）が示されます。エクスプローラーは、あなたとチェーンの間に入るサードパーティであり、ノードではありません。同じチェーンを読み取りますが、動作が異なる場合があるため、ノードを第一候補とし、エクスプローラーをセカンドオピニオンとして使います。フォールバックを禁止するには --no-explorer を、別の Etherscan 互換 API を使うには --explorer=<url> を指定します。両方とも失敗した場合は LINKED : unknown と表示されます。これは未完了の検証であり、決して判定結果ではありません。

訂正、2026年10月24日発見（0.2.11 以前のバージョン）。 このコマンドは、チェーンの先端でのペースが遡る道のり全体で維持されたと仮定して、レシートの時刻をブロックに当てはめていました。Base Sepolia では、10月16日は2秒ごとにブロックが生成され、その1週間後には0.2秒ごとになっていたため、推定は190万ブロックも早すぎました。全履歴を保持しているノードでは、決済が存在しない範囲を検索して LINKED : no と返しており、これは誤った結果です。公開ノードでは「プルーニングされた履歴」というエラーが発生していました。ある人がコマンドを6回実行しても判定結果を得られなかったことが、この問題を見つけるきっかけでした。0.2.12 ではブロックを計算する代わりに検索し、見つかったブロック付近でペースを測定して、秒単位のウィンドウを使います。以前のバージョンで、チェーンのペースが変わるより前のレシートに対して LINKED : no と表示された場合は、再実行してください。その no は誤ったウィンドウに対する結果でした。

commitment  : 0x5c35a61a09a566a9c284fad18a70ac2ddfff34d01d2a3ce776ce94e8d5b38ff8
candidates  : 2 nonce(s) consumed by this payer in that window
LINKED      : yes, to exactly one settlement
  tx        : 0xed87b09bfb20a8c8b69908e163fcea6432d193d389640c0465afcb5561dfeb30

commitment  : 0xfecee93e1aec7d6858a218bf324f23e2a4eed07925d8d4542b9662c5026e3d22
candidates  : 3 nonce(s) consumed by this payer in that window
LINKED      : yes, to exactly one settlement
  tx        : 0x2898d0ceb97ddf60af98e19c94fc0adddbdf1e64f9032e62454085e37acfe36b

commitment  : 0xea8dd34b8beac90f021a4e8d893a689c25249f86947770c8e6647c1cde206008
candidates  : 2 nonce(s) consumed by this payer in that window
LINKED      : yes, to exactly one settlement
  tx        : 0x2a9e95d63a5af8210767baa69143b364dad51caffc29a152c77e03bc508d7199

各ウィンドウは、それぞれのレシートの issuedAt を中心としているため、候補数は異なります。中央のレシートのウィンドウには3件すべての支払いが含まれますが、それでも1件だけを正確に特定します。これは、セクション5.6.1で説明されている曖昧さを、ライブ状態に照らして解消したものです。

この出力で変化するのは2つの値であり、判定結果は変わりません。支払者がより多くのノンスを消費するにつれて候補数は増え、上限のブロック番号は、チェーンの先端がその番号を超えるまでは現在の先端で上限設定されます。各レシートが結び付くトランザクションは固定されています。

examples/ にある3つのファイルには、セクション5.6.4が後続の検証者に必要だと述べているもの、つまりレシート、そのソルト、支払われたアセットがそのまま含まれています。ノンスとトランザクションハッシュは、意図的にファイルから除外されています。これらはトークンコントラクト上の AuthorizationUsed(address,bytes32) ログから取得され、ツールは、コミットメントを開示できる候補がちょうど1つの場合にのみ、その結果を受け入れます。一致が0件の場合も、複数件の場合も、最善推測として扱うことはなく、リンクなしとして報告します。

自分のレシートを指定するには --receipt=<file> を使い、ソルトとアセットがレシートと一緒に保存されていない場合は --salt= と --asset= を追加してください。3つすべてが必須です。アセットがなければ、レシートとソルトだけではリンクできません。これはセクション5.6.4自体が警告していることです。

これらの支払いは、バージョン2のレシートを発行する稼働中の x402 販売者に対して行われました。この販売者は、各レシートが結び付くべき決済とともに、以下でこれらのケースを公開しています。 https://api.tokenizen.nl/api/x402/conformance 自分の実装をここに接続して比較するか、有料ルートを呼び出して自分で取得したレシートをリンクしてください。フィクスチャだけでは、実際の決済エンベロープ内で、ソルトが§5.6.3で指定されている場所に届くかどうかは分かりません。それを確認できるのは、有料呼び出しだけです。 買い手も売り手も私たちなので、これによってチェーン全体がエンドツーエンドで機能することは示せます。ただし、ほかの誰かがこれを使っていることを示すものではありません。

ERC-8004 のフィードバックは支払いに基づいていますか？

npx -y agent-receipt-verify ground --feedback=0xa661b2ffd344926ddd5e31dc0c481212ba2d973fdb0c08a461d4c903f15d3936

チェーンから読み取り、個別に報告する4つの事実です。評価者が支払者であること、支払先アドレスがエージェントに紐付けられたウォレットであること、支払いがフィードバックより先に行われていること、そして評価者がオーナーでも承認済みオペレーターでもないことです。これらは、AgenticFinanceGraph が erc-8004/erc-8004-contracts#99 で定義している内容です。ここでは、そのコードではなく説明に基づいて再構築しています。Kanon のベクターと同じ方法です。5つ目の事実は別のものです。レシートとそのソルト（--receipt= --salt=）を与えたとき、フィードバックハッシュはレシートを通じて、まさにその決済を対象としていることを検証できるでしょうか。これにより、ハッシュが正しい送金を指していると読み手が信じる必要がなくなります。

これが存在する前に他の誰かが記録した2つの判定と照合しています。どちらも Base メインネットから記録され、vectors/grounding に保存されており、test/grounding.mjs によってオフラインで再実行されます。エージェント 1085288 では4つの事実すべてが成立し、エージェント 524087 では評価者が受取人であり、支払い先もエージェントに紐付けられたウォレットではありません。支払者と受取人はトランザクションではなく、USDC の送金ログから取得します。これは、決済をファシリテーターが送信するためです。紐付け情報はフィードバック時点のブロックで読み取ります。ノードがそれに対応できない場合は最新ブロックから読み取り、出力にその旨を記載します。測定できなかった事実は not_measured となり、決して false にはなりません。判定の対象はチェーン上の事実であり、評価が公平かどうかではありません。

1つのスイート

npx -y agent-receipt-verify suite

チェーンの順序に沿った4つのチェックを1つのテーブルにまとめ、いずれかが失敗した場合は終了コード 1 を返します。x402 セクション 5.5 の試行 ID、公開されている EIP-3009 ベクターに対する支払い承認、まさに1つの決済を対象としている必要があるレシート、そして支払いに基づいている必要があるフィードバックです（AgenticFinanceGraph による2つの記録済み判定を、ground --vectors でオフライン再実行します）。これは erc-8004/erc-8004-contracts#99 で要望されたもので、何かを二重に実装するものではありません。上記のコマンドを呼び出し、その結果を並べて表示します。この実装が公開済みのベクターと他者の記録済み判定に沿って動作するかをチェックします。他者のエンドポイント、レシート、フィードバックを認証するものではありません。

正直な限界

形式チェックでは、レシートの形式、つまり署名、コンテンツアドレス指定、ハッシュが取引相手の観測したバイト列と一致するかどうかを検証します。オペレーターが誠実かどうかや、レジストリがレシートを確定済みとして保持しているかどうかはわかりません。

決済リンクは実際のチェーン状態を読み取ります。実際の制約は次のとおりです。

  • レシートの issuedAt の前後の範囲を検索します。チェーン全体を検索しないのは、Base Sepolia のパブリック RPC が eth_getLogs の上限を1回あたり200ブロックとしているためです（ドキュメントを読んだのではなく、実測しました）。検索した範囲は必ず表示されるため、「見つからない」は「この範囲内にはない」という意味であり、「存在しない」という意味にはなりません。--window= で範囲を広げられます。

    売り手が先に nonce を持っているため、決済が確定する前にレシートが署名されることがあります。そのため、検索範囲は過去方向ではなく、中心を基準に設定します。ブロック時間の実測値から求めた検索範囲とともに、実際のレシートを使って測定した負荷は次のとおりです。

    --windowissuedAt の前後の範囲RPC 呼び出し回数実時間
    501.7分10.7s
    2006.7分30.8s
    400 (default)13分51.3s
    100033分111.7s
    200067分212.9s

    呼び出し回数は検索範囲に比例して増え、支払者の利用履歴には比例しません。これが検索範囲を広げる利点で、21回のリクエストで1時間の余裕を確保できます。支払者が使用済み nonce をすべて検索する場合は issuedAt が不要で、時刻のずれによる見落としもありませんが、コストはその支払者がこれまでに使った金額に応じて増えます。

  • RPC 呼び出しが拒否された場合は、空の結果を返すのではなくエラーになります。実行できなかった検索を、何も見つからなかった検索として報告してはいけません。

  • 実装されているのは eip3009 のみです。現在、仕様で定義されているのがこの方式だけだからです。

  • レシートが1つの決済に紐づいていることを確認します。金額や受取人が合意した内容と一致するかどうかは確認しません。その点は対応するトランザクションを確認してください。

  • レシートのバージョン2は、まだオープン中のプルリクエストで定義されているため、プリイメージは今後変更される可能性があります。基準としているコミットは、ソースコードと上記のステータステーブルに固定されています。

来歴とライセンス

Apache-2.0 です。検証対象の2つのプロジェクトが使用しているライセンスと同じです。公開されているテスト素材は、変更せず、帰属表示を付けて再配布しています。正確なコミットについては NOTICE を参照してください。どちらのプロジェクトも、このリポジトリをレビューしたり、推奨したりしていません。

コマンド1つで独自のエンドポイントを確認

インストール不要、アカウント不要、npm への公開も不要です。

npx github:holistis/agent-receipt-verify https://your-endpoint.example/paid

ラダー自体はバージョン管理されたファイル profiles/x402-deployed-ladder-v1.json です。このファイルには、各レベルの根拠となる条項、各チェックに必要な入力、チェックで判定できない場合に報告する内容が記載されています。ツールはルールをコードに埋め込まず、このファイルを読み取るため、別の実装でもこちらの実装を読まずに同じ内容を測定できます。

CONFORMANCE.md にあるラダーのレベル0〜2を、支払いなしで測定します。レベル3〜5には実際の決済が必要で、失敗ではなく「未測定」として返します。意図的に測定しない項目は、同じファイルに記載されています。

測定済みエンドポイントのバッジ

エディションでエンドポイントが測定されている場合は、そのバッジを取得できます。

[![x402 receipt](https://api.tokenizen.nl/api/x402/badge?url=https%3A%2F%2Fyour-endpoint.example%2Fpaid)](https://github.com/holistis/agent-receipt-verify/blob/main/CONFORMANCE.md)

同じデータの JSON 版は /api/x402/badge.json?url=... にあります。

このバッジには意図的な点が2つあります。まず、ライブ測定は行いません。日付付きの測定結果に基づいて応答するため、このエンドポイントを使って任意のホストを調べることはできず、ちょっとした問題が起きるたびに数値が変わることもありません。また、測定日はバッジ内に表示されるため、古くなったバッジは、ひそかに誤った情報を示すのではなく、古いことが目に見えてわかります。

どのエディションでも測定されていないエンドポイントは、レベル0ではなく measured: false として返されます。この2つの主張は異なります。前者は調べた結果何も見つからなかったことを示し、後者はまだ調べていないことを示します。

コメント

Markdown 対応

MCP は初めてですか？

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。