接続するすべてのMCPサーバーは、tools/listレスポンス——サーバーを構築した誰かが書いたJSONドキュメント——を、レビューされないままモデルのコンテキストに直接送り込んでいます。そのレスポンスをVeriSwarmのスキャナーに貼り付けるだけで、数秒で11件の決定論的チェックが返ってきます：ツールポイズニング、タイポスクワッティング、スキーマ操作、ラグプルパターン、プロンプトインジェクション、過剰な権限、モデルの誤バインディング、コンテキストなりすまし、隠しチャネル、安全でないメモリ参照、ヘッダーインジェクションです。LLMがツールを判定することは一切なく——常に同じ判定結果を返すパターン・構造解析だけです。
MCPツールのメタデータは、システムの根幹を支えています。モデルは説明テキストをもとに何をどう呼び出すかを決めます——裏側のコードではありません。汚染された説明文は何かを直接侵害する必要すらなく、攻撃はモデルの推論の内部だけで完結します。MCPToxベンチマークは45件の実在するMCPサーバーと353件の実在するツールに対してこれを検証し、攻撃成功率が60%を超え、最大で72%に達することを測定しました。ツールの説明を目視で読む方法は最初の1台のサーバーを超えて拡張できず、ラグプル——レビュー中はきれいに振る舞い、次のバージョンアップで別物を出荷するサーバー——にも耐えられません。
これらはスキャナーがもともと対象としていたリスクカテゴリー——汚染された、あるいは不注意なツール定義に最も現れやすいもの——をカバーしています。
説明文やパラメータのテキストに隠された指示——「これまでの指示を無視して」、隠蔽を促す指示、人格の乗っ取りなど。スキャナーはスキーマツリー全体を、oneOf/anyOfの枝に入れ子になっているプロパティも含めて走査するため、4階層下に埋め込まれたペイロードでも表面化します。
よく知られたツールに疑わしいほど似せたツール名——大文字・小文字だけを変えたなりすましも含みます。例えばREAD_FILEがread_fileになりすます場合など、単純な完全一致の比較では丸ごと見逃してしまいます。
任意の入力を受け付ける空のオブジェクトスキーマ、隠しフィールドを紛れ込ませるadditionalProperties: true、そして4階層を超えるスキーマの入れ子——悪意あるパラメータを隠すためによく使われる場所です。
ツールの明記された目的では正当化できない、認証情報・トークンへのアクセスや、機密ファイル・内部ネットワークエンドポイントへのアクセスを求める文言——ツールが信頼された後に再定義するための下準備です。
読める文字列にデコードされるBase64のブロブ——ペイロードの密輸——や、キリル文字のаがあなたのaに成り代わるUnicodeホモグリフなど、視覚的なレビューをすり抜けて指示を紛れ込ませるために使われます。
読み取り専用と名付けられ、あるいはそう説明されているツールがcommand, script、またはsqlといったパラメータを受け付けている場合、ある能力を名乗りながら別の能力を提供していることになります。
元の6つではカバーしきれないプロトコル固有のリスクです。11のチェック全体で、スキャナーはOWASP MCP Top 10 v0.1-beta（2025）の10件中9件のリスクに対応しています。10番目——MCP08、Lack of Audit and Telemetry——は静的なツール定義では示せないものであり、スキーマの欠陥ではなく実行時ログの欠如です。
特定のモデルにハードコードされたツール——「GPT-4でしか動作しない」といった記述や、特定のシステムプロンプトへの結合を要求するもの。ルーティングの依存関係と、そのモデル固有の攻撃対象領域を生み出します。
会話履歴を書き換えたり、偽のターンを注入したり、ユーザーやアシスタントになりすませると主張するツール——安全フィルターと監査証跡の両方を同時に無効化しうる能力です。
標準にない最上位キーや、ベンダー拡張のスキーマフィールド（x-）、説明文に埋め込まれた長いbase64のブロブ——文章を探しているレビュアーが見に行かない場所です。
グローバル・共有・セッション横断の状態へのアクセスを主張する文言、あるいはワイルドカードをデフォルトとするsession_idパラメータ——テナント分離の破綻の背後にあるパターンです。
ヘッダー名のような形をしたパラメータ——authorization, cookie、またはhostを含む——や、MCP仕様のx-mcp-header拡張を通じて送信リクエストに組み込まれたものなど。どちらも、呼び出し元が決して目にすることのない信頼境界ヘッダーを上書きできます。
同じ11のチェック、同じレポート形式、実行方法は3通りです：
POST /v1/suite/guard/scan-mcpにツール定義をボディに入れて送ります。判定（pass / warn / fail）、0〜1のリスクスコア、そして発見結果の配列が返ります——各発見結果にはツール名、発火したチェック、深刻度、証拠、推奨対応が含まれます。scanMcpTools()はNode SDKで、scan_mcp_tools()はPython SDKで——どちらも同じエンドポイントを型付きのリクエスト／レスポンス形式でラップしています。scan_mcp_toolsツールを使って、別サーバーのツールを呼び出す前にスキャンできます——別途HTTPクライアントを用意する必要はありません。深刻度がクリティカルまたは高の発見結果は、テナント上のGuardスキャン結果として保存されるため、スキャン結果はその場限りのコンソール出力ではなく——時間をかけてレビュー・優先順位付け・対応完了までできる記録になります。
今日きれいにスキャンできたツール定義が、明日には別物を出荷することがあります——ラグプルを定義する性質はまさに、あなたが監査したバージョンが来週動かすバージョンとは違うという点にあります。最初の接続時だけでなく、MCPサーバーのバージョンが上がるたびに、またはスケジュールに沿ってスキャンを実行してください。スキャナーはこの物語のデプロイ前の半分です。実行時の半分——サーバーがすでにスキャンを通過した後に、ライブのツール呼び出しが発生するたびにフィルタリングする部分——はGuard Proxyです。どちらも互いの代わりにはなりません：スキャナーはツールが表明することを検出し、Guard Proxyはそれが実際に行うことを検出します。
ツールポイズニングは、深く理解する価値が最も高いチェックです——攻撃がネットワーク層で捕捉できるものを何ひとつ残さず、モデルの推論の内部だけで完結する唯一のチェックだからです。攻撃の仕組み、実際の攻撃成功率、そしてスキャナーがどう検出するかについては、「MCPツールポイズニング：攻撃の仕組みと検出方法」で詳しく解説しています。
tools/listメソッドを呼び出してツール定義を取得し、その配列をVeriSwarmのスキャナー——POST /v1/suite/guard/scan-mcp、Node SDKのscanMcpTools()、Python SDKのscan_mcp_tools()、またはホスト型MCPサーバーのscan_mcp_toolsツールのいずれか——に送ります。この4つはすべて同じ11チェックのエンジンを呼び出し、同じ構造化されたレポートを返します：判定（pass/warn/fail）、0-1のリスクスコア、そして発見結果ごとの深刻度、証拠、推奨対応です。
11の決定論的チェックがあります。ツールポイズニング、タイポスクワッティング、スキーマ操作、ラグプルパターン、プロンプトインジェクション、過剰な権限は元の6つのリスクカテゴリーをカバーしています。モデルの誤バインディング、コンテキストなりすまし、隠しチャネル、安全でないメモリ参照、ヘッダーインジェクションは、スキャナーをOWASP MCP Top 10 v0.1-beta（2025）の10件中9件のリスク——MCP08（Lack of Audit and Telemetry）を除くすべてのリスク——に対応させます。この項目は静的なツール定義では示せず、スキーマのスキャンではなく実行時ログが必要です。すべてのチェックはパターンと構造に基づいており——ループの中にLLMは存在しないため、あるツール定義をスキャンするたびに同じ結果が得られます。
いいえ。これは静的アナライザーです——正規表現パターン、スキーマツリーの走査、Unicode正規化であり、モデル呼び出しではありません。これは意図的なトレードオフです。確率的な判定者を使うことの問題点は、YARAベースのあるMCPスキャナーの独立監査で、誤検知率がおよそ78%と報告された例があることに表れています。決定論的チェックは再現率をいくらか犠牲にする代わりに、CIパイプラインが実際にゲートとして使えるものを手に入れます——同じ入力は2回とも同じ判定になります。
両方できます。CIでは、サーバーのtools/listのレスポンスをファイルに保存し、パイプラインのステップとしてスキャンします——クリティカルな発見結果はビルド失敗であり、後から気づくSlackスレッドではありません。本番環境では、スケジュールに沿って、あるいはMCPサーバーのバージョンが上がるたびにAPIエンドポイントを呼び出してください。あるツールが一度きれいにスキャンされたとしても、それはその時点でしか「良好」と分かっていないからです。再スキャンこそが、レビュー中は問題なく振る舞い、その後に悪意ある動きをするラグプルサーバーを、見逃さずに捕まえる方法です。
スキャナーはデプロイ前の半分を担います：エージェントがサーバーを実際に呼び出す前に、宣言されたツール定義を読み取ります。Guard Proxyは実行時の半分を担います：エージェントとそのツールの間に位置し、発生するライブ呼び出しをすべてフィルタリングします。どちらも互いの代わりにはなりません。スキャナーはツールが「やると言っていること」を検出し、Guard Proxyは呼び出し時に「実際にやっていること」を検出します。
これは実測されたものであり、理論上のものではありません。MCPToxベンチマークは45件の実在するMCPサーバーと353件の実在するツールに対してツールポイズニングを検証し、攻撃成功率が60%を超え、ピーク時には72%に達することを発見しました——より高性能なモデルほど従う頻度が高くなります。指示への追従性が高いということは、悪意ある指示にもより忠実に従ってしまうということでもあるからです。攻撃の仕組みと、スキャナーのtool_poisoningチェックがどのように検出するかについての完全な解説は、専用の解説記事にあります。
1件のtools/listレスポンスをGuardに送信して、あなたのエージェントがこれまで何を読んでいたのかを確認しましょう。Gateの無料プランでまずトラストスコアリングとイベントパイプラインを利用でき、Guardのスキャナーはその上で動作します。