コンテンツにスキップ

MCPサーバー

OstorlabはMCPサーバーを提供しており、AIアシスタントやエージェントフレームワークが、カスタムGraphQLクライアントを構築することなく、スキャン・脆弱性・チケット・アセットを直接操作できます。

GraphQL APIがプラットフォームの全機能を提供するのに対し、MCPサーバーはAIクライアントに、自律的に発見して呼び出せる型付きツールの厳選されたセットを提供します。アシスタントに「私のアプリの最新スキャンは何を検出した?」と尋ねれば、適切なツールを選択し、それらを連鎖させて回答します。

エンドポイント

https://api.ostorlab.co/apis/mcp/{api_key}/

トランスポートはstreamable HTTPです。APIキーはURLパスの一部に含まれます。

Warning

末尾のスラッシュは必須です。スラッシュがない場合、サーバーは307リダイレクトを返します。リダイレクトに従うクライアントは動作しますが、リクエストごとに余分なラウンドトリップが発生します。POSTリクエストでリダイレクトに従わないクライアントは失敗します。

Warning

URL内のキーは認証情報です。URLはプロキシログ、ブラウザ履歴、シェル履歴に記録されることが多く、MCPクライアントの設定ファイルは通常プレーンテキストで保存されます。エンドポイントURLはキー自体と同様に厳重に扱ってください。キーを無効化するには失効（revoke）させてください — 有効期限を設定しても、このパスでのキーの動作は停止しません。

APIキーの取得

Webアプリケーションの Integrations/API → API Keys（https://report.ostorlab.co/integrations/api）から作成します。キーのロールによってMCPツールで実行できる操作が決定されます — 権限を参照してください。

クライアントの接続

ほとんどのクライアントはサーバー名、トランスポート、URLを要求します。トランスポートはstreamable HTTPであるため、クライアントがタイプを求める場合はhttpを指定してください。

Claude Code

claude mcp add --transport http ostorlab https://api.ostorlab.co/apis/mcp/YOUR_API_KEY/

Claude Desktop、Cursor、VS Code、Windsurf、Zed

これらのクライアントはJSON設定ファイルを読み込みます。ファイルの保存場所はクライアントやプラットフォームによって異なるため、各クライアントのドキュメントを確認してください。設定エントリの形式は共通です：

{
  "mcpServers": {
    "ostorlab": {
      "type": "http",
      "url": "https://api.ostorlab.co/apis/mcp/YOUR_API_KEY/"
    }
  }
}

セクション名がmcpServersではなくserversであったり、urlの代わりにserverUrlを使用するクライアントもあります。上記のブロックが拒否される場合は、クライアントのドキュメントでキー名を確認してください — 重要なのはトランスポートとURLです。

動作確認

クライアントにスキャンの一覧表示などの読み取りツールの実行を依頼してください。無効なキーの場合はInvalid API Key.が返されます。ツール一覧の取得は確認手段になりません：ツール一覧はキーの有効・無効にかかわらず返されます。

権限

すべてのツールは、処理を実行する前にAPIキーの権限を検証します。キーにはロールが割り当てられており、ロールによってアクションのセットが付与されます。各ツールには1つのアクションが必要です。

ツールの種類 必要なアクション
スキャン、脆弱性、チケット、コメント、チェックリストの読み取り read
チケット、コメント、チェックリストの作成または変更 write
脆弱性のトリアージ write
スキャンの開始、再実行、停止 write
アタックサーフェスのアセットおよびタグの一覧取得 attack_surface_read
検出アセットの承認または却下、タグの追加・変更・削除 attack_surface_audit
ディスカバリキューの読み取りおよびトリアージ、アタックサーフェスグラフの読み取り attack_surface_audit（ただしグラフはattack_surface_readが必要）
APIキー、ユーザー、シングルサインオン（SSO）の管理、監査ログの読み取り、組織設定の読み取りおよび変更、チケットエージェント、スキャナーおよびスキャナーグループの管理、自動化ルールの作成、ならびに大部分のインテグレーションの設定・読み取り・削除 admin

必要なアクションを持たないキーで呼び出した場合、部分的な結果ではなく明確なエラーが返されます。

ロールとアクションの対応関係は以下の通りです：

ロール read write admin attack_surface_read attack_surface_audit
reader あり なし なし あり なし
user あり あり なし あり あり
admin あり あり あり あり あり
attack_surface_auditor なし なし なし あり あり

上記の表から2つの点がわかります。attack_surface_readはすべてのロールに付与されているため、どのキーでもlist_assetsおよびlist_tagsを呼び出せます。また、attack_surface_auditorキーはreadもwriteも持たないため、アタックサーフェス関連のツールに限定されます。アセットやタグの読み取り、承認、却下、編集は可能ですが、スキャン、脆弱性、チケットを参照することはできません。

組織でオブジェクトレベルアクセスが有効になっている場合、ツールはGraphQL APIキーパスと同じルールに従ってこれを尊重します：

  • スキャンとチケット — 非管理者キーは、明示的に付与された個々のスキャンおよびチケットのみ参照できます。
  • アセット — 権限の付与はアセット単位ではなくオーナー単位です。キーは、アクセスが付与されたオーナーに属するすべてのアセットを参照できます。キーがアクセス可能なオーナー（したがって参照可能なアセット）を確認するには、list_ownersを使用してください。

利用可能なツール

以下の表では、操作対象ごとにツールを分類しています。各表にはキーに必要なアクションが記載されているため、特定のロールのキーがどのツールにアクセスできるかをひと目で把握できます。

サーバーは常に自身の仕様を提示します。すべてのツールには独自の説明と引数リストが含まれており、クライアントの接続時に双方が読み込まれます。ここに記載されていないツールがある場合は、クライアントにツール一覧の表示を依頼してください — 接続先サーバーにとってはそれが最も正確な仕様となります。

スキャン

ツール アクション 説明
list_scans read スキャンの一覧を取得。status、asset_id、scan_profile、risk_rating、created_after、archivedでフィルタリング可能。
get_scan read 単一スキャンの詳細を取得。
get_scan_status read スキャンの進行状況、直近のステータス履歴、報告されたエラーを取得。
list_scan_profiles read 組織が実行可能なスキャンプロファイルの一覧と、create_scanで指定する正確なプロファイル名を取得。
search_store_applications read 公開モバイルストアでアプリを検索し、create_scanに必要な名前とパッケージ名を取得。
create_scan write Web、ネットワーク、またはモバイルストアのターゲットに対してスキャンを開始。
create_source_code_scan write Gitリポジトリのスキャンを開始。
create_source_code_archive_scan write アップロード済みのソースコードアーカイブのスキャンを開始。
create_mobile_file_scan write アップロード済みのモバイルバイナリのスキャンを開始。
create_multi_asset_scan write 複数のターゲットを同時に網羅する単一スキャンを開始。
create_mobile_testflight_scan write TestFlight経由で配布されたiOSビルドのスキャンを開始。
create_autodiscovery_scan write 組織の承認済みアタックサーフェス全体に対するスキャンを開始。
create_rescan write 同一のアセット、プロファイル、認証情報、設定を使用して既存のスキャンを再実行。
stop_scan write 実行中のスキャンを停止。
generate_scan_report write スキャンのPDFレポートを生成し、ダウンロード用リンクを返却。

get_scanおよびget_scan_statusは、list_scansで一覧表示できる場合であっても、アーカイブ済みスキャンを返しません。アーカイブ済みスキャンに対してどちらかを呼び出すと、Scan not found.が返されます。

create_scanには、web、network、mobile_storeのいずれかのasset_typeと、それに対応するターゲットフィールドを指定します：Webの場合はurls、ネットワークの場合はnetworks、モバイルストアターゲットの場合はmobile_asset_typeに加えてapplication_nameおよびpackage_nameです。また、scan_profile_nameも受け取ります。これはlist_scan_profilesが返すプロファイル名のいずれかでなければなりません。組織が実行できないプロファイル名は事前に拒否され、エラーメッセージで有効なプロファイル名が提示されるため、事前にlist_scan_profilesを呼び出してください。

create_rescanは、対象ターゲットが過去にスキャンされたことがある場合に手軽な手段です。既存スキャンのIDのみを受け取り、すべての設定をそのまま複製するため、プロファイルやアセットの指定ミスを防ぐことができます。新しいスキャンにはRescan of <元のタイトル>というタイトルが付けられ、元のスキャンが非表示設定であっても常に表示されます。

その他のツールは、create_scanが対応していないターゲットに対するスキャンを開始します。create_source_code_scanはGitリポジトリを対象とします。create_mobile_testflight_scanはTestFlight経由で配布されたiOSビルドを対象とします。create_autodiscovery_scanはターゲットを一切受け取りません — 組織の承認済みディスカバリセット全体をスキャンするため、list_autodiscovery_assetsによってインベントリに承認されたアセットすべてが対象となります。create_multi_asset_scanは、Web、ネットワーク、リポジトリ、モバイルストア、アップロードファイルなどの複数ターゲットをまとめて受け取り、1回のスキャンとして実行します。

また、名前で指定可能なターゲットではなくファイルを受け取るツールが2つあります：create_mobile_file_scanはモバイルバイナリをスキャンし、create_source_code_archive_scanはソースアーカイブをスキャンします。いずれも、後述するアップロードハンドルを受け取ります。

スキャン対象ファイルのアップロード

ツールの引数はJSON形式であるため、ファイル自体のバイトデータを直接含めることはできません。先にファイルをアップロードし、返却されたハンドルをスキャンツールに渡してください。

curl -X POST https://api.ostorlab.co/apis/upload/ \
     -H "X-API-Key: <your-api-key>" \
     -F "file=@app.apk"

レスポンスにはupload_idとともに、サーバー側で記録されたファイル名、サイズ、SHA-256が含まれるため、ファイルが破損なく到達したかを確認できます：

{
  "upload_id": "de6024a2-8af5-4e0c-87d2-fdc2c306225f",
  "filename": "app.apk",
  "size": 4171034,
  "sha256": "4ad2930d93c3af606582b26c55ac285485e9623bb508dbf05e5d391b8e4b0969",
  "expires_at": "2026-09-10T09:44:04Z"
}

このupload_idを、create_mobile_file_scanにはapplication_upload_idとして、create_source_code_archive_scanにはarchive_upload_idとして、またはcreate_multi_asset_scanが受け取るアップロードリストの1つとして渡してください。

ハンドルについて知っておくべき3つのポイント：

  • ハンドルはアップロードを実行した組織に帰属します。別組織のハンドルは、未知のハンドルと同様にUpload not found.として拒否されます。
  • ハンドルには有効期限があります。期限切れ後はUpload has expired.として拒否されます。
  • スキャンによってハンドルは消費（spend）されます。スキャンが作成されるとハンドルは解決できなくなるため、2回目のスキャンを実行するには再アップロードが必要です。呼び出しが失敗した場合はハンドルが使用可能なまま残るため、リトライ時に再アップロードは不要です。

Warning

ここにあるすべてのcreate_*ツールは実際の稼働スキャンを開始し、スキャンクレジットを消費します。クライアントがツールを呼び出す前に、ターゲットとプロファイルを確認するようにしてください。

Warning

generate_scan_reportはPDFの生成が完了するまでブロックされ、数分かかる場合があります。応答に時間がかかっても失敗ではありません。結果が返る前にタイムアウトさせたりリトライしたりしないでください。レスポンスにはファイルそのものではなくurlが含まれます。X-API-Keyヘッダーに同一のAPIキーを含めて、HTTPS経由でそのURLを取得してください。

AIペンテスト

AIペンテスト（Agentic Deep Scanとも呼ばれます）は、通常のスキャンとは異なるカテゴリに属します。ID体系は通常スキャンとは異なり、検出結果は脆弱性ではなくリスク（risks）と呼ばれます。

ツール アクション 説明
get_agentic_deep_scan read 単一AIペンテストの詳細：状態、ターゲット、所要時間、サマリーを取得。
get_ai_pentest_usage read 単一AIペンテストが消費したAIトークン使用量を取得。
list_risks read AIペンテストで検出されたリスクの一覧を、ペンテストおよび重大度（severity）でフィルタリングして取得。
list_ai_provider_api_keys read 組織が保存しているAIプロバイダーのAPIキー一覧を取得。

Note

リスクはlist_vulnerabilitiesやsearch_vulnerabilitiesでは返されず、AIペンテストはget_scanでは返されません。AIペンテストのIDをget_scanに渡すとScan not found.が返されます — これは「存在しない」のではなく「ツールが異なる」ことを意味します。脆弱性ツールしか認識していないクライアントは、AIペンテストで何も見つからなかったと誤認して報告します。

脆弱性

ツール アクション 説明
list_vulnerabilities read 単一スキャン内の検出結果一覧。scan_id、risk_rating、kb_detail_id、または所属チケットでフィルタリング可能。
search_vulnerabilities read 全スキャンを横断した検出結果の検索。アセット、日付範囲、重大度、ナレッジベース詳細、フリーテキストでフィルタリング可能。
get_vulnerability read 単一の検出結果詳細：技術的詳細、悪用の詳細、CVSSベクトル、位置メタデータ。
update_vulnerability write トリアージ：カスタムリスク評価やCVSSベクトルの設定、誤検知（false positive）または許容済み例外（accepted exception）としてのマーク。

複数のスキャンにまたがる調査（例：「このアプリケーションにおけるすべてのCritical脆弱性」「先月検出された項目」など）には、search_vulnerabilitiesを使用してください。list_vulnerabilitiesは、すでに単一のスキャンIDを把握している場合にのみ使用してください。search_vulnerabilitiesなら1回の呼び出しで回答できる質問に対して、スキャンリストをループ処理してlist_vulnerabilitiesを呼び出さないでください。

update_vulnerabilityについて知っておくべき2つのポイント：

  • 検出結果を誤検知または例外としてマークする操作は、その検出結果に紐づくチケットに作用します。チケットのない検出結果は変更されず、それでも呼び出しは成功を報告します。
  • all_vulnerabilitiesパラメータは、同一スキャン内で同一ナレッジベース詳細を共有するすべての検出結果に変更を適用し、スキャン全体のリスク評価を再計算します。影響範囲は単一の検出結果よりもはるかに大きくなります。

各検出結果はdnaフィールドを持ちます — これは検出結果のタイトル、技術的詳細、位置情報から導出されるフィンガープリントです。後続のスキャンで再発見された同じ問題は、これら3つの要素が変わらない限り同一のdnaを保持するため、他システムへ検出結果を取り込む際の重複排除に役立ちます。実行ごとに技術的詳細が変動する場合、安定性は保証されません。

スキャンアーティファクト

スキャンは検出結果以上の情報を収集します。以下のツールは、スキャンの実行中に収集されたアーティファクトを読み取ります。

ツール アクション 説明
list_api_endpoints read スキャンで発見されたAPIエンドポイントの一覧。
list_http_traffic read スキャンがキャプチャしたHTTP送受信データ。
list_http_folders read スキャンが検出したHTTPディレクトリ構造。
list_pcap_files read スキャンが生成したパケットキャプチャファイル。
list_ide_files read スキャンのバイナリ内部から検出されたファイル。
list_ide_functions read スキャンのバイナリから逆コンパイルされた関数。
list_ide_logs read アプリ操作中にスキャンがキャプチャしたデバイス側のランタイムログ。
list_call_ui_nodes read モバイルアプリの操作中に到達した画面一覧。
list_stack_traces read アプリ操作中にスキャンが記録したコールスタック。

スキャンが収集する内容は、スキャンの実行種別に依存します。WebスキャンにはHTTPトラフィックが存在し、逆コンパイルされたバイナリは存在しません。モバイルスキャンには両方が含まれる場合があります。結果が空であっても、その種別のデータが収集されなかったことを意味するだけであり、スキャンが失敗したわけではありません。

チケット

ツール アクション 説明
list_tickets read チケットの一覧。status、priority、assigned_email、agent、tag、title、created_since、modified_sinceでフィルタリング可能。ソート可能、limit指定対応。
get_ticket read 単一チケットの詳細をIDまたはキー（例：os-1234）で取得。
create_ticket write チケットを作成。タグ、担当者、チケットエージェント、期日を任意で指定可能。
update_ticket write 同一フィールドの変更。
delete_ticket write チケットを削除。取り消し不可。

コメントとチェックリスト

ツール アクション 説明
list_comments、create_comment、update_comment、delete_comment 一覧取得はread、その他はwrite チケット上のコメントスレッド。
list_checklists、create_checklist、update_checklist、delete_checklist 一覧取得はread、その他はwrite チケットに添付された修復チェックリスト。
create_checklist_item、update_checklist_item、delete_checklist_item write 個々のチェックリスト項目。

Note

チケットエージェントが割り当てられているチケットにコメントを追加すると、エージェントの実行が開始されます。

MCP経由で作成されたコメントには投稿者が紐づきません。サーバーが認証するのはユーザーではなくAPIキーであるためです。Webアプリケーション上では投稿者なしで表示されます。

チケットエージェント

チケットエージェントは、修復作業を実施するためにプラットフォームがチケット上で自律実行できるAIエージェントです。チケットをエージェントに割り当てることでルーティングします。

ツール アクション 説明
list_ticket_agents read チケットをルーティング可能なエージェントの一覧。enabledフラグおよび各エージェントの実行サマリーを含む。
assign_ticket_agent write チケットにエージェントを割り当て、実行を開始。
create_ticket_agent admin 新規エージェントを追加。実行定義も任意で設定可能。
update_ticket_agent admin エージェント名、説明、または実行定義を変更。
delete_ticket_agent admin エージェントを削除。

Warning

エージェントを割り当てると実行が開始され、実行を取り消すことはできません。チケットにエージェントが割り当てられると、その後のチケットへのコメント追加ごとに新たな実行が開始されます。実行が実際に開始されたのかスキップされたのかを確認するには、レスポンスのagent_runフィールドを確認してください — 開始されたと安易に仮定しないでください。

エージェントを削除すると、そのエージェントが割り当てられていたすべてのチケットで割り当てが解除されます。チケット自体は保持されますが、エージェントは「なし」に設定され、復旧するには新しいエージェントを作成してチケットごとに再割り当てするしかありません。レスポンスにはunassigned_tickets件数が含まれるため、エージェントが未使用であると判断する前にその数値を確認してください。また、エージェントの実行定義も破棄され、削除前に完全な形で読み出すことはできません — list_ticket_agentsはマスクされた要約のみを返します。引数の値は一切返されないため、これらのツールを使ってエージェントの認証情報を読み取ることはできません。

チケットストリーム

ストリームは、スプリント、リリース、またはセキュリティ施策を横断してチケットを一括追跡できるようにグループ化する仕組みです。

ツール アクション 説明
list_ticket_streams read ストリーム一覧。ステータス、名前の部分一致、またはストリームIDでフィルタリング可能。
get_ticket_stream read 単一ストリームの詳細を取得。
create_ticket_stream write ストリームを作成。リード、メンバー、関連チケット、日付を任意で指定可能。
update_ticket_stream write 同一フィールドの変更。
delete_ticket_stream write ストリームを削除。参照されているチケットおよびユーザーアカウントは保持されます。

member_emailsおよびticket_idsは、既存のセットに追加するのではなく完全置換します。メンバーを1名追加する場合は、最終的にストリームに所属させたいメンバー全員の完全なリストを渡してください。

アセットとインベントリ

ツール アクション 説明
list_assets attack_surface_read アタックサーフェスのアセット一覧。asset_type、owner_id、search、tagsでフィルタリング可能。
create_asset write 単一アセット（ドメイン、アプリ、IPアドレス、リポジトリ、または汎用ノード）をオーナーの下に登録。
update_asset write アセットのオーナー、ロケーション、カラー、メモ、CIA要件、タグを変更。
delete_asset write インベントリから単一アセットを削除。
list_fingerprints attack_surface_read インベントリ全体で検出されたテクノロジー一覧。
list_ports attack_surface_read インベントリ全体で検出された個別のポート一覧。
list_protocols attack_surface_read インベントリ全体で検出された個別のプロトコル一覧。

アセットはID単体ではなく、asset_typeとasset_idのペアで一意に識別されます。アセットのサブタイプごとに独立したテーブルに格納されているため、同じ数値であってもサブタイプが異なれば別のアセットを指します。update_assetとdelete_assetはいずれもこのペアを受け取り、list_assetsが返すのもこのペアです。

create_assetは同一オーナーに対して冪等です：すでに存在するアセットを登録すると、失敗する代わりにcreatedフラグがfalseとなった既存レコードが返されます。別のオーナーの下にすでに存在する識別子は汎用エラーで拒否されるため、書き込み操作を使ってキーから参照できないアセットを探索することはできません。

アセットを削除しても、そのスキャンや検出結果は削除されません。スキャンとの紐づきは解除されますが、スキャン自体はそのまま残ります。

update_assetのtagsは、アセットのタグ全体を丸ごと置換します。既存タグとのマージは行われません。

list_fingerprints、list_ports、list_protocolsは、インベントリの一覧表示ではなくサマリーを返します。キーがアクセス可能なアセット全体で検出された個別の値を返すため、list_assetsをページングすることなく「何が稼働しているか」「何が公開されているか」を把握できます。

オーナー

オーナーはチームを表し、オブジェクトレベルアクセスの付与単位となる境界です。オブジェクトレベルアクセスが有効な場合、キーは自身がアクセス可能なオーナーに属するアセットを参照できます。アセットを割り当てるには、事前にオーナーが存在している必要があります。

ツール アクション 説明
list_owners read 組織のオーナー一覧。名前の部分一致でフィルタリング可能。
create_owner write 名前、オーナー種別、および任意の連絡先・親オーナーを指定してオーナーを作成。
update_owner write オーナーの名前変更、種別の変更、連絡先の再割り当て、または別の親オーナーへの移動。
delete_owner write オーナーを削除。

ownership_typeにはrejected、acquisition、third_party_service、internalのいずれかを指定します。

Warning

オーナーにアセットが紐づいている場合、または検出済み未承認の候補がそのオーナーを指している場合、delete_ownerは削除を拒否します。削除が連鎖（カスケード）することは決してありません — アセットは保持され、拒否されることで保護されます。これにより、アセットが紐づいたままオーナーが削除され、そのオーナー経由のオブジェクトレベルアクセス権がすべて失われてキーからの可視性が暗黙のうちに消滅する事態を防止しています。先にアセットを再割り当てまたは削除してから、オーナーを削除してください。

オブジェクトレベルアクセスの下にある非管理者キーの場合、list_ownersはキーにアクセス権が付与されているオーナーとその親オーナーを返します。管理者キーは組織内のすべてのオーナーを参照できます。したがって、結果が空である場合は、組織にオーナーがまったく存在しないか、このキーがどのオーナーにもアクセスできないかのいずれかを意味します。

アセットロケーション

ロケーションは、アセットをグループ化できるラベル付けされた（任意で階層化可能な）拠点やリージョンを表します。これは単なるラベルであり、スキャナーではなく、スキャンがどこで実行されるかを決定するものでもありません。

ツール アクション 説明
list_asset_locations read 組織に設定されているロケーション一覧を取得。
create_asset_location write 名前、任意の住所、任意の親ロケーションを指定してロケーションを作成。
update_asset_location write ロケーションの名前変更、住所の変更、または別の親ロケーションへの移動。
delete_asset_location write ロケーションを削除。

create_asset_locationは冪等です：同一の名前、住所、親を持つロケーションは、createdフラグがfalseの状態でそのまま返されます。

delete_asset_locationは、そのロケーションにアセットが固定されている場合や、子ロケーションがネストされている場合は削除を拒否します。削除が連鎖することはありません：アセットおよび子ロケーションは保持され、拒否されることで保護されます。先にそれらを移動または削除してから、ロケーションを削除してください。

検出アセット

アタックサーフェスディスカバリはアセット候補を提案します。候補は、誰かがインベントリに承認するか却下するまでレビューキューに留まります。

ツール アクション 説明
list_autodiscovery_assets attack_surface_audit 保留中のディスカバリキューを取得。キーパターン、候補種別、スコア範囲、オーナーでフィルタリング可能。
accept_autodiscovery_asset attack_surface_audit 単一の候補をインベントリに昇格（承認）。
reject_autodiscovery_asset attack_surface_audit 単一の候補を却下。
assign_potential_node_owner attack_surface_audit 保留中の候補にオーナーを割り当て。
compute_potential_assets attack_surface_audit 次回スケジュール実行を待たずに、今すぐディスカバリキューを再計算。
suggest_autodiscovery_domains attack_surface_audit 企業のフリーテキスト説明から、その企業が所有するドメインを提案。
get_attack_surface_graph attack_surface_read 1つ以上の開始点周辺のグラフ近傍を取得。

Warning

候補を承認すると、そのアセットはスキャン可能かつ課金対象になります — インベントリに加わり、スキャンターゲットとなり、組織のプラン上限にカウントされます。モデルが1回の呼び出しでキュー全体をインベントリに一括登録してしまわないよう、承認と却下はどちらも単一の明示的なIDを受け取り、一括処理やフィルタ指定は意図的に備えていません。候補は1件ずつ確認してください。

キーに対応するインベントリアセットが存在しない候補を却下すると、そのキーが記録され、以後のディスカバリ実行で再提案されなくなります。キーが既存アセットと一致している候補を却下した場合は、キューから除外されるだけであり、以後のディスカバリ実行で再度提案される可能性があります。

assign_potential_node_ownerは、候補が承認される前に所属するオーナーを設定します。これにより、インベントリに追加された時点でチームに紐づいた状態になります。このツールは候補を承認するものではありません — accept_autodiscovery_assetが呼び出されるまでキューに残ります。

get_attack_surface_graphは「これに何が接続されているか」を明らかにします。1つ以上の開始点を渡すとそこから外側へトラバースし、到達した近傍をノードとエッジの2つのフラットなリストとして返します。トラバース範囲には上限が設けられているため、グラフの密集した部分を開始点に指定した場合でも、到達可能なすべてではなく制限された近傍範囲が返されます。

compute_potential_assetsは、スケジュール実行を待つことなくオンデマンドでディスカバリを実行します。すでに実行が進行している最中に呼び出した場合、2回目の実行を開始するのではなく進行中の実行に合流するため、2回呼び出しても安全です。

ディスカバリ設定

ディスカバリは組織が所有する対象を記述したプロンプトによって方向付けられます。これにより、類似した名前の無関係な企業ではなく、自社に関連する候補のみが提案されるようになります。

ツール アクション 説明
get_attack_surface_agent_config read 組織のディスカバリを制御するプロンプトを取得。
create_attack_surface_agent_config write ディスカバリ制御プロンプトを設定。
update_attack_surface_agent_config write ディスカバリ制御プロンプトを変更。
delete_attack_surface_agent_config write ディスカバリ制御プロンプトを削除。

suggest_autodiscovery_domainsはこれらを補完するツールです：企業に関するフリーテキスト説明を受け取り、その企業が所有している可能性の高いドメインリストに変換します。ゼロから書く代わりにプロンプトの下書きを作成する手段として利用できます。このツールは提案を行うのみであり、呼び出してもキューやインベントリに何かが追加されることはありません。

タグ

タグはnameとvalueのペアで構成されるため、同一の名前で異なる値を持つタグが複数存在できます（例：env=prodとenv=stagingは2つの独立したタグです）。これらを作成する場合はvalueを渡してください。単なるラベルとして使用する場合は省略します。

ツール アクション 説明
list_tags attack_surface_read 組織内で定義されたタグ一覧。名前の部分一致でフィルタリング可能。
list_asset_tags attack_surface_read キーがアクセス可能なアセットで実際に使用されているタグ一覧。
add_tag attack_surface_audit タグを作成。任意のカラー、説明、アイコンを指定可能。
update_tag attack_surface_audit タグの名前変更またはスタイルの変更。
delete_tags attack_surface_audit ID指定でタグを削除。
delete_unused_tags attack_surface_audit 何からも参照されていないすべてのタグを削除。

タグ名は組織固有であるため、推測した名前を指定しても失敗するのではなく何も一致しません。タグでフィルタリングしたりアセットに付与したりする前に、list_tagsを呼び出してください。

update_tagは使用されているすべての箇所でタグを変更するため、そのタグを持つすべてのチケットやアセットに新しい名前が反映されます。一部のアイテムを別のタグに移行する手段としては使えません。別のタグがすでに保持しているname/valueペアにタグ名を変更しようとすると拒否されるため、意図せずタグが統合されることはありません。

delete_tagsは、そのタグが付与されていたすべてのチケットおよびアセットからタグを解除します。チケットやアセット自体は保持され、タグの紐づきのみが削除されます。この呼び出しはオール・オア・ナッシングです：指定IDの中に不明または到達不能なものが含まれている場合、何も削除されず、エラーでそのIDが報告されます。

list_tagsは、何にも使われていないタグを含め、組織で定義されているすべてのタグを返します。list_asset_tagsは、キーがアクセスできるアセットで使用中のタグのみを返すため、フィルタ選択に適した絞り込み済みリストが得られます。

delete_unused_tagsはIDを受け取りません。どのチケットにもどのアセットにも参照されていないすべてのタグを1回の呼び出しで完全に削除し、この操作は取り消せません。削除対象を事前に確認するため、実行前にlist_tagsとlist_asset_tagsを比較してください。

テスト認証情報

テスト認証情報は、スキャン実行中に認証を行うためにプラットフォームが使用できる再利用可能なログイン情報です。

ツール アクション 説明
list_test_credentials read 保存されている認証情報一覧。種別および非シークレットフィールドの部分一致でフィルタリング可能。
create_test_credential write サポート対象の種別のいずれかで新しい認証情報を保存。
update_test_credential write IDを保持したまま、保存済み認証情報の値を置換。
delete_test_credential write 認証情報を削除。

保存されたシークレットが返されることは一切ありません。list_test_credentialsは、非シークレットの識別子と行ごとのhas_secretフラグを返します。

update_test_credentialはマージではなく完全置換です。省略した認証情報種別のフィールドは、credential_nameラベルを含めすべてクリアされます。保持したい値は現在の値をそのまま渡してください。また、credential_typeは認証情報の作成時と同一の種別である必要があります。

認証情報のローテーションを行う場合は、削除して再作成するよりもupdate_test_credentialを使用することを推奨します：IDが維持されるため、その認証情報を使用するようにすでに構成されているスキャンの認証が継続します。認証情報を削除すると、それらのスキャンは認証に失敗するようになります。

スケジュールスキャン

スケジュールルールは定期的な周期でスキャンを実行し、単発スキャンの合間でもカバレッジを最新に維持します。

ツール アクション 説明
list_schedule_rules read 組織のスケジュールルール一覧。有効化状態（enabled）でフィルタリング可能。
create_schedule_rule write 1つ以上のアセット、スキャンプロファイル、実行周期を指定してルールを作成。
update_schedule_rule write ルールのアセット、プロファイル、周期、または有効化状態を変更。
delete_schedule_rule write ルールを削除。取り消し不可。

周期の指定形式には2種類あります。cadence_typeをcronに設定した場合、crontabには標準的な5フィールドのcron式（例：毎日16:00なら0 16 * * *）を指定します。cadence_typeをcontinuousに設定した場合、max_no_scan_duration_secondsにはルールの対象アセットに対するスキャン間の最大許容間隔（秒）を指定します。

Warning

有効化されたルールは定期的に課金対象のスキャンを実行するため、ルールはデフォルトで無効（disabled）の状態で作成されます。activeはデフォルトのまま作成し、list_schedule_rulesでルールを確認した上で有効化してください。作成直後から実行を開始させたい場合にのみ、作成時にactive=Trueを渡してください。

ルールの確認後に有効化するには、update_schedule_ruleにactive=Trueを渡して呼び出します。ルールを破棄せずに一時停止する場合もこのツールを使用します。delete_schedule_ruleはルールを完全に削除します。すでに実行されたスキャンは保持されます。

自動化ルール

自動化ルールは、検出結果が特定の条件に一致した際にアクションを自動実行します。チケットの自動起票や通知ルーティングの連携に用いられます。

ツール アクション 説明
list_automation_rules read 組織の共有ルール一覧。コンテキストおよび有効化状態でフィルタリング可能。
list_action_definitions read ルールで実行可能なアクションと、各アクションが必要とする引数の一覧を取得。
update_automation_rule write ルールの名前、条件、アクション、コンテキスト、共有設定の変更、または無効化。
delete_automation_rule write ルールを削除。
create_automation_rule admin コンテキスト、フィルタクエリ、単一のアクションからルールを作成。

contextにはattack_surface、remediation、inventoryのいずれかを指定します。filter_queryはJSON配列として記述される条件であり、少なくとも1つのエントリを含める必要があります — 空の配列を指定するとフィルタが適用されず、そのコンテキスト内のすべてのレコードにルールが一致してしまいます。

スケジュールルールと同様に、新しい自動化ルールはデフォルトで無効（disabled）の状態で作成されます。条件とアクションを確認した上で、update_automation_ruleを使用して有効化してください。

ルールを削除せずに停止させるには、update_automation_ruleにactive=Falseを指定して呼び出します。これは元に戻すことができます。delete_automation_ruleは取り消せません。

APIキーから参照できるのは、組織全体に共有されているルールのみです。個人がプライベートに保持しているルールは返されません。

ルールが実行するアクションは、プラットフォームで定義されているものでなければなりません。アクション名を推測してエラーを確認するのではなく、create_automation_ruleを実行する前にlist_action_definitionsを呼び出して、どのアクションが存在し何を引数に取るかを確認してください。

スキャナー

スキャナーはスキャンを実行するお客様自身のマシンであり、スキャン通信がOstorlabのネットワークではなくお客様のネットワークから送信されるようにします。スキャナーグループは複数のスキャナーを束ね、単一のマシンではなくグループに対してスキャンを割り当てられるようにします。

ツール アクション 説明
list_scanners read 組織が利用可能なスキャナー一覧を取得。
list_scanner_groups read 組織内で定義されたスキャナーグループ一覧を取得。
create_scanner admin スキャンを固定割り当てできるようにスキャナーを登録。
update_scanner admin スキャナーの名前、説明、または所属グループを変更。
delete_scanner admin スキャナーを廃止。取り消し不可。
create_scanner_group admin スキャナーグループを作成。
update_scanner_group admin グループの名前、説明、または所属スキャナーを変更。
delete_scanner_group admin スキャナーグループを削除。
grant_scanner_access admin 子組織に対し、自組織のスキャナーでのスキャン実行を許可。
revoke_scanner_access admin そのアクセス権を取り消し。

grant_scanner_accessおよびrevoke_scanner_accessがアクセスできるのは自組織の子組織のみであり、スキャナーは自組織が所有するものでなければなりません。権限付与はオール・オア・ナッシングです：自組織の子組織ではない組織を含むリストを指定した場合、何も書き込まれずに拒否されるため、部分的に権限が付与されることはありません。

連携

ツール アクション 説明
list_integrations read 組織が接続しているサードパーティ連携の一覧を取得。有効化状態および非シークレットのターゲット情報を含む。
get_jira_ticket_map read チケットがJiraに送信されたかどうか、およびどのJira課題になったかを取得。
configure_jira_integration write JiraワークスペースURL、認証情報、デフォルトプロジェクトを設定または置換。
configure_slack_integration write Slack Incoming Webhookを追加し、どのスキャン完了イベントで通知するかを選択。
create_servicenow_ticket write 単一チケットをインシデントとしてServiceNowに送信。
get_slack_integration admin 設定済みのSlack Webhookおよびその通知トグル設定を読み取り。
delete_git_pat_integration admin Git Personal Access Token連携を削除。
delete_servicenow_sync_config admin ServiceNow同期設定を削除。

チケットの送信、通知の送信、回答内でのプロバイダー名の言及など、インテグレーションに依存する操作を行う前にlist_integrationsを呼び出してください。どのプロバイダーが接続されているかがわかるため、操作を実行して失敗から確認する手間が省けます。有効として報告されている連携であっても認証情報が期限切れまたは失効している可能性があるため、これらのツールからは現在正常に動作するかどうかまでは判別できません。

これらのツールから認証情報が返されることは一切ありません。これにはJira APIトークン、OAuthシークレット、パスワード、Slack Incoming Webhook URLなどが含まれます。許可リストに登録された非シークレットフィールドのみが返されます。

2つの設定ツールは、再呼び出し時の挙動が異なります。Jiraの設定は組織あたり1つであるため、configure_jira_integrationを再実行すると同一レコードが更新され、以前の認証情報が置き換えられます。Slackはそうではないため、configure_slack_integrationを再実行すると既存のWebhookが変更されるのではなく、2つ目のWebhookが追加されます。

Warning

delete_git_pat_integrationを実行すると、そのトークンに依存していたソースコードスキャンおよび自動修正プルリクエストが停止します。保存されていたトークンはOstorlabから削除されますが、プロバイダー側では有効なまま残るため、別途プロバイダー側で失効させてください。

delete_servicenow_sync_configを実行すると、その設定下ですでに送信されたチケットの記録も破棄されます。ServiceNow側のインシデント自体は残りますが、各Ostorlabチケットからインシデント番号へのリンクが失われるため、送信済みチケットの追跡や更新ができなくなります。有効な最後の同期設定を削除すると、ServiceNowへのチケット送信が完全に停止します。

上記の表は簡易一覧です。プロバイダーごとの残りのツールについては以下のセクションで説明します。以下の各表は上記の一覧に追加されるものであり、重複するものではありません。

Webhook

Webhook連携は、OstorlabがイベントをPOST送信するお客様側のURLです。

ツール アクション 説明
create_webhook_integration admin Ostorlabがイベント通知をPOST送信する宛先を設定。
update_webhook_integration admin Webhookのエンドポイント、ヘッダー、または有効化状態を変更。
delete_webhook_integration admin Webhook連携を削除。

Slack

ツール アクション 説明
update_slack_integration admin 単一のSlack Webhook URLまたはその通知トグル設定を変更。
delete_slack_integration admin 単一のSlack Webhookを削除。

configure_slack_integrationは既存のWebhookを置き換えるのではなく新規追加するため、既存のWebhookを変更するにはupdate_slack_integrationを使用します。これらとdelete_slack_integrationはいずれもIDを受け取ります。このIDはget_slack_integrationが返すIDです。

Jira

ツール アクション 説明
get_jira_integration admin 保存されているJira設定を取得（認証情報は除く）。
test_jira_integration admin Jiraの接続テストを実行し、各項目の結果を個別に報告。
create_jira_ticket_map write チケットが既存のJira課題に対応していることを記録。
update_jira_ticket_map write チケットのJiraマッピング先を別の課題に変更。
delete_jira_ticket_map write チケットとJira課題の紐づきを解除。
create_jira_ticket write チケットに対応する新規Jira課題を作成し、マッピングを記録。
list_jira_metadata admin 保存された認証情報から参照可能なプロジェクト、課題タイプ、フィールドの一覧を取得。

チケットマップは1つのOstorlabチケットと1つのJira課題との間のリンクであり、get_jira_ticket_mapで読み取ることができます。3つのマップ書き込みツールは、Ostorlab外のJira上で作成された課題に対してこのリンクを手動管理します。これらはリンクのみを変更します。いずれのツールもJira課題自体の作成・編集・削除は行わないため、チケットの紐づきを解除してもJira課題はそのまま残ります。

実際にJiraにアクセスして処理を行うのはcreate_jira_ticketです。チケットに対応する新規課題を作成し、同一呼び出し内でマッピングを記録するため、Jira課題がまだ存在しない場合に使用するツールです。失敗した場合は課題もマッピングも残らず、何が問題であったかが明示されるため、認証情報から参照できないプロジェクトが指定された場合も汎用エラーではなくその旨が報告されます。

list_jira_metadataは、create_jira_ticketおよびconfigure_jira_integrationが必要とする値（認証情報がアクセスできるプロジェクト、各プロジェクトが受け付ける課題タイプ、マッピングに使用可能なフィールド）を確認する手段です。結果が空である場合は、認証情報からプロジェクトが一切参照できないことを意味します。ツールの不具合と判断する前に、test_jira_integrationで確認することをお勧めします。

test_jira_integrationは各検証結果を名前付きで個別に報告するため、URL、認証情報、プロジェクトのどこに問題があるのかを具体的に特定できます。

Linear

ツール アクション 説明
configure_linear_integration admin Linear接続を設定または置換。
get_linear_integration admin 保存されているLinear設定を取得（認証情報は除く）。
test_linear_integration admin Linearが設定済み、有効、かつアクセス可能であるかを報告。
list_linear_teams admin 課題を作成可能なLinearチーム一覧を取得。

ServiceNow

ツール アクション 説明
configure_servicenow_integration admin ServiceNow接続を設定または置換。
test_servicenow_integration admin 単一のServiceNow設定のテストを実行し、各項目の結果を個別に報告。
delete_servicenow_integration admin ServiceNow連携を削除。
configure_servicenow_sync_config admin チケットをServiceNowテーブルおよびそのフィールドにマッピング。
get_servicenow_sync_config read 同期設定がどのようにチケットをテーブルにマッピングしているかを取得。
list_servicenow_fields read 同期設定のターゲットとなるServiceNowテーブルのカラム一覧を取得。
get_servicenow_ticket_map read チケットがServiceNowに送信されたかどうか、およびどのレコードになったかを取得。
create_servicenow_ticket_map write チケットが既存のServiceNowレコードにマッピングされていることを記録。
update_servicenow_ticket_map write チケットのServiceNowマッピング先を別のレコードに変更。
delete_servicenow_ticket_map write チケットとServiceNowレコードの紐づきを解除。

ServiceNowは2段階で設定します。まずconfigure_servicenow_integrationでインスタンスと認証情報を保存します。次にconfigure_servicenow_sync_configで、チケットを書き込むテーブルと各チケットフィールドがマッピングされるカラムを定義します。マッピングに実在するカラムを指定できるよう、事前にlist_servicenow_fieldsを呼び出してそのテーブルが実際に持っているカラムを確認してください。

チケットマップツールの仕組みはJiraの場合と同様です：OstorlabチケットとServiceNowレコードのリンクを管理するのみであり、レコード自体を操作することはありません。実際にレコードを作成するツールはcreate_servicenow_ticketです。

ソースコード

ツール アクション 説明
list_repositories read Ostorlabが現在アクセス可能なリポジトリ一覧を取得。
create_git_pat_integration admin Git Personal Access Tokenを登録。
update_git_pat_integration admin 保存済みトークンを置換、または対象範囲を変更。
create_standard_git_integration admin セルフホスト型Gitインスタンスを登録。
update_standard_git_integration admin セルフホスト型Gitの登録内容を変更。
delete_standard_git_integration admin セルフホスト型Gitの登録を削除。
enable_github_app_connection admin GitHub Appのリポジトリに対するソースコードスキャンおよびプルリクエストを再開。
disable_github_app_connection admin インストール状態を維持したまま、それらを停止。
delete_github_app_connection admin 組織からGitHub Appのインストール設定を削除。
update_source_code_oauth_integration admin ソースコードOAuth連携を有効化または無効化。
delete_source_code_oauth_integration admin ソースコードOAuth連携を削除。

list_repositoriesは、create_source_code_scanを実行する前に呼び出すべきツールです。接続中のソースコード連携が現在公開しているリポジトリを返すため、推測した名前ではなく、プラットフォームが実際にクローン可能なリポジトリをスキャンできます。

disable_github_app_connectionは、delete_github_app_connectionの可逆的な代替手段です。無効化するとスキャンとプルリクエストは停止しますがインストール状態は維持されるため、enable_github_app_connectionで元の状態に戻せます。削除した場合はインストール設定そのものが削除されるため、復旧するにはGitHub上で再度アプリをインストールし直す必要があります。

App Center

ツール アクション 説明
create_app_center_integration admin App Centerアプリを連携し、ビルドを自動スキャンできるように設定。
update_app_center_integration admin App Center連携を変更。
delete_app_center_integration admin App Center連携を削除。

Vanta

ツール アクション 説明
get_vanta_auth_url admin ブラウザで開いてOstorlabをVantaに認可するためのリンクを取得。
delete_vanta_integration write Vanta連携を切断。

Vantaの連携にはブラウザが必要です。get_vanta_auth_urlはOstorlabを認可するためにユーザーがブラウザで開くリンクを返します。連携の完了はツール経由ではなくブラウザ上で行われるため、クライアント単体でこの操作を完了させることはできません。

組織とアクセス

ツール アクション 説明
me 有効なキーがあれば不要 キーが所属する組織、およびキーに付与されているロールを取得。
list_shared_access_tokens read 組織のアクティブな共有リンク一覧。付与されたスキャンおよび使用回数を含む。
list_invitations read 組織に招待され、まだ参加していないユーザーの一覧。
create_shared_access_token write アカウントを持たない第三者が単一のスキャンを閲覧できるリンクを作成。
revoke_shared_access_token write 共有リンクを即座に無効化。
list_organisation_users admin 組織へのアクセス権を持つユーザー、そのロール、スコープ対象のオーナーの一覧。
add_user admin 指定したロールで組織に参加するようユーザーを招待。
update_user_access admin メンバーのロール、またはスコープ対象のオーナーを変更。
revoke_user admin 組織からユーザーのアクセス権を剥奪。
review_invitation admin 保留中の招待を承認または辞退。
get_organisation_settings admin 組織の設定およびエンタイトルメント情報を取得。
update_organisation_settings admin 書き込み可能な組織設定を変更。
list_api_keys admin 組織のAPIキー一覧：名前、ロール、作成日時、有効期限、失効状態、マスクされたキー。
update_api_key admin キーの制限：ロールの降格、オーナー付与の解除、有効期限の短縮、または名前の変更。
revoke_api_key admin APIキーを即座に無効化。
list_audit_actions admin 誰が何をいつ変更したかの監査履歴。時間範囲およびアクターでフィルタリング可能。

meは人物ではなくキーの情報を説明します。サーバーが認証するのはキーであるため、「自分は誰か」という問いへの回答は、キーが所属する組織、ならびにキー独自の名前、プレフィックス、ロール、オーナー権限付与、有効期限となります。ユーザーアカウントは返されません。

add_userはアカウントを作成するのではなく招待を送信します。ユーザーが承認するまではlist_invitationsに表示され、承認後に初めてlist_organisation_usersに表示されます。

update_api_keyはキーの権限を狭めることしかできません。設定できるロールはキーが現在持つロール以下でなければならず、オーナー権限付与は解除のみ可能で追加はできず、有効期限は前倒し（短縮）のみ可能です。したがって、キーに現在以上の権限を付与する手段としては機能せず、キー自体のシークレット文字列が返されることもありません。

失効（Revoke）のみがAPIキーを確実に無効化します。有効期限の設定単独では無効化されず、キーはrevokedが設定されるまでMCPパスで動作し続けます。revoke_api_keyで失効が設定され、この変更は取り消せません。キーが自身を失効させることはできません；セッションの途中で自らの接続を切断することになるため、その呼び出しは拒否されます。

APIキーの平文テキストがツールから返されることは一切ありません。平文が存在するのはキーが作成された瞬間のみであり、以後はハッシュのみが保存されます。list_api_keysは代わりにmasked_key（キーのプレフィックスにアスタリスクが続く形式であり、Webアプリケーションや監査証跡と同じ表示形式）を返します。人物に対してキーを指定・連絡する必要がある場合は、このマスク表記を使用してください。

Warning

共有アクセストークンを保持している人は誰でも、アカウントなしでそのトークンが指すスキャンおよびその検出結果を閲覧できます。これらのトークンに有効期限はありません。list_shared_access_tokensは現時点でアクティブな共有のみを一覧表示するため、すべての行は現在誰かが持っているアクセス権を表します。生のトークン文字列が返されるのは、create_shared_access_tokenのレスポンス時の1回限りです。

list_audit_actionsは、組織で操作監査が無効になっている場合、エラーではなく空のリストを返します。レスポンスにはその旨を示すmessageフィールドが含まれるため、「0件」が「何も起きなかった」と誤認されるのを防ぎます。

シングルサインオン

ツール アクション 説明
get_saml_config admin 組織のSAMLシングルサインオン設定を取得。
configure_saml admin SAMLシングルサインオンを設定。
update_saml admin SAML設定を変更。

configure_samlは厳密な新規作成ツールです：組織にすでに設定が存在する場合は拒否され、既存設定を置き換えることはありません。既存設定を変更する場合はupdate_samlを使用します。これは部分更新であり、指定したフィールドのみが書き込まれます。どちらを適用すべきかを確認するため、事前にget_saml_configを呼び出してください。

修復SLO

ここでのSLOは修復期日を指します：特定の重大度または優先度のチケットをオープンにしておくことが許容される日数です。

ツール アクション 説明
get_slo_config read 組織の重大度別および優先度別の許容期間（日数）を取得。
update_slo_config write それらの許容期間を変更。

許容期間にnullが設定されている場合、その重大度または優先度には期限が設定されていないことを意味します。update_slo_configは部分更新です：正の数値を指定したキーはその許容期間が設定され、nullを指定したキーはクリアされ、省略したキーは変更されません。未知のキーが指定された場合は拒否されます。

UI自動化プロンプト

ツール アクション 説明
list_ui_automation_rules read 組織が利用可能なUI自動化ルール一覧を取得。
create_ui_prompts write UI自動化プロンプトを作成。
update_ui_prompts write 自組織が所有するUI自動化プロンプトのコード、名前、または説明を変更。
delete_ui_prompts write 自組織が所有するUI自動化プロンプトを削除。取り消し不可。

codeは完全置換であり呼び出しごとに常に書き込まれますが、nameおよびdescriptionは指定された場合にのみ書き込まれます。したがって、プロンプトの名前変更のみを意図した呼び出しであっても、プロンプトの既存のコードを送信する必要があります。送信しない場合、コードは送信された内容で上書きされます。

この呼び出しはオール・オア・ナッシングではありません。更新可能なプロンプトは、他のプロンプトの更新に失敗した場合であっても更新されます。レスポンスには更新されたIDと、更新できなかった各プロンプトの失敗理由が示されます。

list_ui_automation_rulesは組織が所有していないルール（すべての組織が利用できる共有ルール）も返します。変更または削除できるのは自組織が所有するルールのみであるため、一覧に正常に表示されるプロンプトであっても、update_ui_promptsやdelete_ui_promptsでは拒否される場合があります。

ナレッジベース

ナレッジベースはOstorlab独自の参照データです。組織ごとの個別データではなく全組織共通のデータであるため、これらのツールが返すレコードはお客様のスキャンとは直接関係のないデータも含まれます。

ツール アクション 説明
list_cves read CVEレコードをID、重大度、または説明文のテキストで検索。
list_kb_applications read 新規公開CVEの発生をOstorlabが監視している公開アプリケーションの一覧を取得。
list_kb_targets read CVEとそれが影響を与えるアプリケーションバージョンを紐づけるレコード一覧を取得。
list_app_cards read Ostorlabで利用可能な共有App Card一覧を取得。

list_kb_targetsは他の2つの間を結合するツールです：CVEを指定すると影響を受けるアプリケーションバージョンを返し、アプリケーションを指定するとそれに対して公開されたCVEを返します。

エージェントストア

スキャンプロファイルはエージェントを組み合わせて構築されます。エージェントストアは、存在するエージェントのカタログです。

ツール アクション 説明
search_agents read エージェントストアを名前で検索。
get_agent read 単一エージェントの詳細と、その最新バージョンが受け取る引数一覧を取得。

search_agentsは探索ステップであり、get_agentは詳細確認ステップです：名前で検索してエージェントのキーを特定し、そのキーが受け付ける引数を確認します。

エクスポート

これらのツールはいずれもファイルを生成し、ファイルそのものではなくダウンロードリンクを返します。generate_scan_reportと同様に、X-API-Keyヘッダーに同一のAPIキーを含めてHTTPS経由でそのURLを取得してください。

ツール アクション 説明
export_scan read 単一スキャンの完全なアーカイブ。
export_scan_sarif read 単一スキャンの検出結果をSARIF形式で出力。
export_vulnerabilities read 単一スキャンの検出結果をCSV形式で出力。
export_tickets read 修復チケットをCSV形式で出力。
export_assets attack_surface_read 確定済みのインベントリアセットをCSV形式で出力。
export_potential_nodes attack_surface_read 保留中のディスカバリ候補をCSV形式で出力。

2つのアタックサーフェスエクスポートツールには、すべてのロールが付与されているattack_surface_readが必要です。他の4つのツールにはreadが必要であるため、attack_surface_auditorキーはアセットおよびディスカバリ候補をエクスポートできますが、スキャン、検出結果、チケットをエクスポートすることはできません。

結果の上限

すべての一覧ツールは返す件数に上限を設けています。その上限についてツールがどのように通知するかは一律ではありません。3つの挙動パターンがあります。

一部の一覧ツールはカーソル（cursor）を返します。カーソルは、直前に受信したページの終了位置を示す不透明なトークンです。これはnext_cursorフィールドで返されます。次の呼び出し時にその値をcursor引数として渡すことで、後続のページを取得できます。next_cursorがnullであれば、最後のページに到達したことを意味します。カーソルの内部を解析したり独自に構築したりしないでください — その中身は実装の詳細であり、それを生成したツールにとってのみ意味を持ちます。

一部の一覧ツールはtruncated真偽値を返します。これはさらにレコードが存在することを示しますが、それを取得する手段は提供されません。代わりにフィルタを使用してクエリを絞り込んでください。

残りのツールはどちらも返しません。これらのツールでは上限が暗黙的です：上限件数までのレコードが返されますが、それ以上の件数が存在するかどうかは通知されません。

ツール デフォルト 最大 追加レコードの通知方法
list_scans 200 200 next_cursor
list_vulnerabilities 200 200 next_cursor
list_assets 200 200 next_cursor
list_risks 200 200 next_cursor
get_scan_status（ステータス履歴） 50 50 なし
list_scan_profiles 上限なし 上限なし 該当なし
list_checklists 上限なし 上限なし 該当なし
search_vulnerabilities 200 200 truncated
list_tags 200 200 next_cursor
list_api_keys 200 200 truncated
list_shared_access_tokens 200 200 truncated
list_ticket_agents 100 100 truncated
list_owners 200 200 next_cursor
list_asset_locations 200 200 next_cursor
list_autodiscovery_assets 200 200 next_cursor
list_test_credentials 200 200 next_cursor
list_integrations 200 200 next_cursor
list_audit_actions 200 200 next_cursor
list_organisation_users 200 200 next_cursor
list_schedule_rules 100 100 next_cursor
list_automation_rules 100 100 next_cursor
get_slack_integration 100 100 next_cursor
list_ticket_streams 50 200 next_cursor
list_tickets 50 200 truncatedおよびnext_cursor
list_comments 50 200 truncatedおよびnext_cursor

最大値を超える数値を指定した場合は、拒否されるのではなく上限値に丸められます。0、負の数、または数値以外の値を指定した場合はInvalid limit.で拒否されます。カーソルは生成元のフィルタ条件と結びついているため、異なるフィルタ条件でカーソルを再利用すると、誤ったページを暗黙に返すのではなくInvalid cursor.として拒否されます。

追加レコードが通知されないツールでは、返された上限件数が回答のすべてとなります：たとえば500件のステータスエントリを持つスキャンであっても、get_scan_statusからは50件が返され、残りの450件が存在することを示す手掛かりはありません。件数が重要となる場合はフィルタで絞り込んでください — 一覧結果からモデルに件数をカウントさせないでください。

削除

このページに記載されているすべてのdelete_*およびrevoke_*ツールはデータを完全に削除します。これにはdelete_ticket、delete_comment、delete_checklist、delete_checklist_itemが含まれ、同様にdelete_asset、delete_owner、delete_asset_location、delete_tags、delete_unused_tags、delete_test_credential、delete_scanner、delete_scanner_group、delete_schedule_rule、delete_automation_rule、delete_ui_prompts、delete_ticket_agent、delete_ticket_stream、delete_checklist、各種連携の削除ツール、ならびにrevoke_api_key、revoke_shared_access_token、revoke_userが含まれます。

一部のツールは連鎖削除を行わずに処理を拒否します。delete_ownerおよびdelete_asset_locationは、何かが依存している間は実行されず、delete_assetはアセットに紐づいていたスキャンや検出結果を保持します。ツールが連鎖削除を行うかデータを保持するかについては、該当ツールの説明セクションに明記されています。

ツールはクライアントに対してアノテーション（annotations）を通知します。アノテーションはツールリスト内でツールとともに伝達されるヒントであり、そのツールを呼び出すと何が起こるかを記述することで、事前にユーザーへ確認を求めるべきかをクライアントが判断できるようにします。以下の3つのヒントが使用されます：

  • readOnlyHint — ツールは何の変更も行いません。
  • destructiveHint — ツールは元に戻せない方法で状態を変更します。
  • idempotentHint — ツールを2回呼び出しても、1回呼び出した場合とまったく同じ効果となります。

前述のツール群には破壊的（destructive）としてのアノテーションが付与されており、データを削除または上書きする他のすべてのツールも同様です。

Warning

アノテーションはあくまでヒントであり、強制力を持つものではありません。実際にユーザーへの確認が求められるかどうかはクライアントの実装に依存します。破壊的なツールの呼び出しごとに確認を求めるクライアントもあれば、一度確認して回答を記憶するクライアントや、まったく確認を求めないクライアントもあります。いずれの場合であっても、サーバーは呼び出しを実行します。書き込み権限を持つキーをモデルに割り当てる前に、クライアントが破壊的ヒントをどのように処理するかを確認してください。

すべてのツールにアノテーションが付与されているわけではありません。アノテーションのないツールの場合、クライアントはMCP仕様のデフォルトにフォールバックし、呼び出しが破壊的であり冪等ではないと仮定します。その結果、アノテーションのない読み取り専用ツールが、慎重なクライアントにとっては実際よりも危険に見えてしまう場合があります。

エラー

失敗したツールは、本文にerrorフィールドを持つ通常の成功レスポンスを返します：

{"error": "Invalid API Key."}

JSON-RPCのisErrorフラグはfalseのままとなります。クライアントがisErrorで条件分岐している場合、認証エラーや権限エラーを成功として読み取ってしまいます — 代わりにerrorフィールドを確認してください。

例

サーバー接続後に有効なプロンプトの例：

  • 「先週完了した、リスク評価が高いスキャンを一覧表示して。」
  • 「スキャン12345のクリティカルな検出結果を表示して、それぞれにチケットを作成して。」
  • 「脆弱性987の技術的詳細は？ そのチケットに誰かコメントしてる？」
  • 「脆弱性654を誤検知としてマークして。」
  • 「rubberduckに割り当てられているオープンなチケットは？」
  • 「Webターゲットに対して実行可能なスキャンプロファイルを教えて。example.comに対してFast Scanを開始して。」
  • 「失効しておらず、作成から1年以上経過しているAPIキーはどれ？」
  • 「アタックサーフェスディスカバリキューの中で、スコアが80以上の候補は何がある？」

トラブルシューティング

接続時のHTTP 404 URLにキーのセグメントか末尾のスラッシュが抜けています。/apis/mcp/YOUR_API_KEY/の形式である必要があります。

Invalid API Key. キーが解決できません。キー全体が正しくコピーされているか、失効していないかを確認してください。

API Key does not have write permission. ツールがキーのロールより上位のロールを要求しています。必要なロールを持つキーを発行してください。

Webアプリケーションでは見えるスキャンに対するScan not found. 考えられる原因は4つあります：スキャンがアーカイブ済みである（get_scanおよびget_scan_statusはアーカイブ済みスキャンを拒否します）、スキャンが別組織に属している、組織がオブジェクトレベルアクセスを使用していてこのキーにそのスキャンへのアクセス権が付与されていない、または指定されたIDが通常スキャンではなくAIペンテストのものである（スキャンツールはAIペンテストのIDを解決できないため、get_agentic_deep_scanを使用してください）。アクセス権のないスキャンは、存在しないスキャンと意図的に同一の形式で報告されます。