agent-bom は、SCA、シークレット、IaC、コンテナにわたってリポジトリとソフトウェアサプライチェーンをスキャンし、AI エージェント、MCP、モデル、データセットを棚卸しし、読み取り専用のクラウド、アイデンティティ、Snowflake、データソースに接続します。そのエビデンスを単一の Finding + UnifiedGraph モデルに正規化し、到達可能なリスクを関連付けてから、オーナー、修正、検証、コンプライアンスエビデンス、またはランタイムポリシーを通じて作業を進めます。
エージェントまたはツールのエントリポイント → MCP サーバー → パッケージ → 検出結果 → 影響 → オーナー → 修正 → 検証
アドホックにローカルまたは CI で実行するか、セルフホスト型コントロールプレーンを使用して、スケジュールまたは接続されたスキャン、履歴、割り当て、ランタイムの強制を実行できます。生のソースと認証情報は顧客管理の実行境界内に留まり、収集・推論・静的・ランタイムの関係は別々に保たれ、不完全なエビデンスは明示的に示されます。
クイックスタート · エビデンスワークフロー · 統合機能マトリクス · 測定済みマッチャー証明 · コントロールプレーンアーキテクチャ
Related MCP server: agent-audit
役割 | 開始場所 | 主な成果 |
AppSec / プロダクトセキュリティ |
| リポジトリの依存関係、シークレット、IaC、イメージをスキャンし、到達可能な検出結果で CI をゲートする |
AI / ML エンジニア |
| エージェント、MCP クライアントとサーバー、スキル、モデル、データセットを出荷前に棚卸しする |
クラウドセキュリティ |
| 読み取り専用のクラウドまたは Snowflake ソースに接続し、インベントリ、ポスチャ、アイデンティティのエビデンスを評価する |
プラットフォーム / DevOps |
| エビデンスを一元化し、オーナーと SLA を割り当て、是正し、検証する |
GRC / 監査 |
| コントロールマッピングをレビューし、明示的なギャップを含むエビデンスをエクスポートする |
経営層 / CISO |
| ポスチャ、カバレッジ、重大なリスク、経時変化をレビューする |
セキュリティエンジニアリングと GRC は別々のワークフローのままです。検出結果と到達可能性は監査認証として提示されません。製品境界を参照してください。
以下のキャプチャは、明示的にラベル付けされたサンプル環境を使用しています。ライブスキャンも同じ Finding + UnifiedGraph コントラクトを使用します。フルサイズの証明には任意の画像を選択してください。
完全な製品ギャラリーのランタイム強制に進む · キャプチャプロトコル
ここから始めてください。これが正面玄関です — 2 つのコマンド、アカウント不要、設定不要。 オフラインサンプルはアドバイザリデータベースをダウンロードせずに完了し、インベントリ、検出結果、ブラスト半径の出力形式を示します。
pip install agent-bom
agent-bom scan --demo --offlineこのサンプルには既知の悪意のあるパッケージが意図的に含まれているため、終了ステータス 1 は想定どおりであり、印刷されたレポートは完全なものです。次にリポジトリをスキャンします:
agent-bom scan .リポジトリスキャンは、インベントリ、検出結果、到達可能な影響を示します。
agent-bom scan . と agent-bom scan -p . は同じコマンドです。PATH は --project のエイリアスです。
切断されたスキャンが必要ですか? まず最小のパッケージアドバイザリデータベースをシードします:
agent-bom db update --osv-ecosystem PyPI
agent-bom scan . --offlineそのデータベースが存在しないか読み取り不能な場合、スキャンは -o が設定されているときに部分的なアーティファクトを書き込み、1 で終了します。したがって、CI は利用できないアドバイザリカバレッジをクリーンなスキャンと誤認することはできません。
新しいデータベースでは、そのコマンドは選択したエコシステムのみをカバーします。他のエコシステムのパッケージは、明示的なオフラインカバレッジギャップのままです。ポリグロットリポジトリの場合は --osv-ecosystem を繰り返すか、OSV の全エコシステムアーカイブには agent-bom db update --source osv を使用してください。完全なアーカイブは 1 GB を超える可能性があり、数分かかる場合があり、サーバーが提供する場合は正確な合計とともにライブの進行状況が表示されます。ディストリビューション、悪用確率、既知の悪用済み脆弱性フィードも必要な場合は、より広範な agent-bom db update を実行してください。
非ゼロの終了はクラッシュではなく判定です。 scan は、ゲートに一致するものが何もない場合は 0 で終了し、一致した場合は 1 で終了します — 設定した --fail-on-* しきい値、既知の悪意のあるパッケージ、または完了しなかったスキャンです。レポートはどちらの場合も完全に印刷され、最後の行は一致したゲートの名前を示します。完全な終了コードコントラクト。
agent-bom scan . -f sarif -o findings.sarif でアーティファクトを保存するか、初回実行ガイドに従ってフォーマットと CI での使用法を確認してください。
インストールせずにスキャナを試し、パッケージを追加する前にチェックします:
uvx agent-bom scan .
uvx agent-bom check requests@2.33.0 --ecosystem pypicheck はインストール前の許可/不安全/不完全の判定を返します。scan はリポジトリと検出された AI/MCP 設定をカバーします。依存関係とシークレットの両方のゲートをチームで自動化するには、同梱のコンシューマフックをピン留めします:
repos:
- repo: https://github.com/msaad00/agent-bom
rev: v0.102.0
hooks:
- id: agent-bom-secrets
- id: agent-bom-scanpre-commit install を 1 回実行します。フックは agent-bom を独自の分離環境にインストールするため、コントリビューターは別途グローバルインストールを行う必要はありません。フックの動作と CI の例。
必要なもの | 移動先 |
リポジトリをスキャンする |
|
ラップトップ上のダッシュボード | |
共有デプロイ (Docker、Helm、EKS、Snowflake) | セルフホスト テーブル |
プルリクエストをゲートする | |
AI エージェントにツールを提供する |
|
クラウドアカウントを接続する |
|
出力形式だけを確認したい場合は、厳選された明示的に合成されたサンプルを使用してください:
agent-bom scan --demo --offlineこのサンプルには既知の悪意のあるパッケージが意図的に含まれており、フェイルクローズします。
ループバックコントロールプレーンを起動します:
pip install 'agent-bom[ui]'
agent-bom serve共有デプロイの場合は、ドキュメント化された Docker または Helm パスを使用し、公開する前に実際のアイデンティティ、TLS、PostgreSQL、暗号化、監査キーを設定してください。
ターゲット | 開始場所 |
Docker Compose | Platform compose — PostgreSQL、分割シークレット、マイグレーションジョブ |
Docker Compose（評価用） | Pilot compose — ループバックのみ、SQLite、認証なし |
Helm / Kubernetes |
|
EKS | |
Snowflake SPCS / Native App |
|
エアギャップ |
例はこのリリース候補を対象としています。正確なピンをコピーする前に、リリースの可用性を確認してください。 それ以外の場合は、PyPI に表示されている最新バージョンを使用してください。
デプロイメント概要 · エンタープライズ設定 · クラウド接続
ニーズ | 最初のアクション | 成果物または次のステップ |
GitHub CI |
| SARIF、PR サマリー、ポリシーの終了コード |
クラウドエビデンス |
| 保存された接続参照。コントロールプレーンからスキャンを実行 |
ランタイムゲートウェイ |
| 許可、警告、ブロックの監査イベント |
エージェントインターフェース |
| 84 個の MCP ツール、6 個のリソース、8 個のワークフロープロンプト |
エージェント配布 | レジストリ固有のインストールメタデータ |
MCP サーバーモードは、84 個の MCP ツール、6 個のリソース、8 個のワークフロープロンプトを公開します。すべて読み取り優先です。検出と分析は、スキャン対象を決して変更しません。
YDC_API_KEY を設定すると、ローカルの脅威インテルデータベースに加えて、ライブの Web およびニュースコンテキスト用のオプションの youcom_search MCP ツールが有効になります。これはクエリを第三者に送信する唯一のツールであり、キーが設定されていない限りオフになり、リクエストは TLS 経由で You.com オリジンに固定されます。そのため、設定によってキーが別のホストにリダイレクトされることはありません。
CLI、Docker、API、Helm チャート、MCP サーバー、ゲートウェイ、SDK は、同じ製品の配布面です。Snowflake SPCS / Native App レーンは、顧客の Snowflake アカウント内で実行されます。これは顧客所有のデプロイメントターゲットであり、agent-bom がホストするサービスではありません。Snowflake と Snowpark は、他のデプロイメントプロファイルのコネクタおよびランタイム統合としても残ります。
配布面 | 入手方法 |
Python パッケージ |
|
コンテナ |
|
Kubernetes |
|
GitHub Action | |
MCP サーバー |
|
MCP レジストリ | |
SDK | Python · TypeScript · Go |
デフォルトで読み取り専用の検出。ランタイムの書き込み決定は別個かつ明示的です。
認証情報は保存時に書き込み専用で、保存時暗号化され、API レスポンスで返されることはありません。
API およびコントロールプレーンのルートは、明示的なローカルモード以外ではテナントスコープであり、認証で保護されています。
欠落したエビデンスは、利用不可または部分的として表示され、事実上のゼロに変換されることはありません。
公開されている例とスクリーンショットは、決定的な合成識別子のみを使用しています。
脅威モデル · リリース検証 · セキュリティポリシー · MCP セキュリティモデル
行き詰まっている、または質問の送り先がわからない場合は、SUPPORT.md にルーティングと、期待できる応答についての正直な説明があります。
コントリビュートするには、CONTRIBUTING.md、AGENTS.md、およびオープンな issue から始めてください。
Apache-2.0 ライセンス。
Check a specific package for known CVEs before installing.
Queries OSV.dev for vulnerabilities in the given package. Use this
before installing an MCP server or dependency to verify it is safe.
Args:
package: Package name with optional version, e.g. "express@4.18.2",
"@modelcontextprotocol/server-filesystem@2025.1.14",
or just "requests" (resolves @latest).
ecosystem: Package ecosystem — "npm", "pypi", "go", "cargo",
"maven", "nuget", "rubygems", "composer", "swift",
"pub", "hex", "conda", "deb", "apk", or "rpm".
Defaults to "npm".
Returns:
JSON with package, version, ecosystem, vulnerability count,
and vulnerability details (id, severity, cvss, fix version, summary).
| Name | Required | Description | Default |
|---|---|---|---|
| offline | No | Use only the local advisory database. An explicit version is required; registry resolution and publication checks are disabled. | |
| package | Yes | Package name with optional version, e.g. 'express@4.18.2', '@modelcontextprotocol/server-filesystem@2025.1.14', or 'requests' (resolves @latest). | |
| version | No | Optional package version when omitted from ``package`` (e.g. package='flask', version='0.12.2'). Prefer embedding in ``package`` as 'flask@0.12.2' or 'flask==0.12.2' when possible. | |
| ecosystem | No | Package ecosystem: 'npm', 'pypi', 'go', 'cargo', 'maven', 'nuget', 'rubygems', 'composer', 'swift', 'pub', 'hex', 'conda', 'deb', 'apk', or 'rpm'. | npm |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is covered structurally. The description adds genuine value by disclosing the external dependency on OSV.dev (an outbound network query) and documenting the JSON return shape. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The key purpose is front-loaded in the first line, followed by a tight context sentence and structured Args/Returns blocks. It earns its length with the OSV.dev source note, usage guidance, and return-format disclosure, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich annotations, an output schema, and 100% parameter coverage, the description covers what matters beyond structure: external data source, when to invoke, and expected return fields. The only minor gap is that the offline/version parameters are not surfaced in the description text, though the schema fully documents them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented structurally and the baseline is 3. The description reinforces package/ecosystem with concrete examples but omits the offline and version parameters entirely from its Args section. It adds convenience, not new meaning, on top of the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise 'Check a specific package for known CVEs before installing' — a specific verb, resource, and scoping constraint. It clearly separates this single-package advisory check from broad siblings like scan or registry_lookup by framing it as a targeted, pre-installation safety verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this before installing an MCP server or dependency to verify it is safe' gives an explicit trigger condition and intended moment of use. However, it does not name any alternative tools or state when NOT to use it, leaving an agent to infer the boundary against scan/policy_check/marketplace_check on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OWASP LLM Top 10 / OWASP MCP Top 10 / MITRE ATLAS / NIST AI RMF compliance posture.
Scans local MCP configurations, maps findings to 47 security controls
across four AI security frameworks, and returns per-control
pass/warning/fail status with an overall compliance score.
Args:
config_path: Path to a specific MCP config directory.
If not provided, auto-discovers all local agent configs.
image: Docker image reference to scan (e.g. "nginx:1.25").
Returns:
JSON with overall_score (0-100), overall_status (pass/warning/fail/no_data),
and per-control details for OWASP LLM Top 10 (10 controls),
OWASP MCP Top 10 (10 controls), MITRE ATLAS (13 techniques),
and NIST AI RMF (14 subcategories). Plus a nist_800_53_catalog line:
the vendor-asserted, catalog-backed NIST SP 800-53 Rev 5 score over
evaluated controls only (with ISO-27001-by-id attribution), scored
independently and NOT folded into overall_score.
| Name | Required | Description | Default |
|---|---|---|---|
| image | No | Docker image to scan, e.g. 'nginx:1.25'. | |
| config_path | No | Path to MCP client config directory. Auto-discovers all if omitted. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable context about scan behavior, return structure, and the notable fact that the nist_800_53_catalog score is independently scored and NOT folded into overall_score. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args and Returns sections, front-loaded with purpose. It is somewhat verbose, especially the Returns details, given that a full output schema exists. However, the special NIST 800-53 scoring nuance justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with two optional parameters and an output schema, the description fully explains scope, control mapping, return structure, and the separate NIST score. It leaves no critical gaps for an agent to understand what the tool does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The paragraph text essentially restates schema descriptions (config_path auto-discovers, image is a Docker reference) without adding new semantics or edge-case guidance. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Get OWASP LLM Top 10 / OWASP MCP Top 10 / MITRE ATLAS / NIST AI RMF compliance posture.' It clearly states what it does (scans MCP configurations, maps to 47 controls) and distinguishes itself from sibling tools like scan or cis_benchmark by naming unique frameworks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: scans local MCP configs with optional config_path or image, auto-discovers if omitted. However, it does not explicitly mention when to prefer this tool over alternatives or provide exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return ranked ExposurePath JSON for headless security agents.
This is the agent-native graph surface: Claude, Cursor, Codex,
Windsurf, Cortex, and other MCP clients can request the same
investigation objects used by the dashboard without scraping UI state.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of ranked exposure paths to return. | |
| cursor | No | Continue with pagination.next_cursor; keep the risk filter unchanged. | |
| scan_id | No | Optional graph scan ID. Omit to use the latest snapshot. | |
| min_risk | No | Minimum path risk score to include. | |
| tenant_id | No | Tenant ID for the graph snapshot. Defaults to 'default'. | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior, so the description doesn't need to repeat that. It adds minimal extra context: it returns JSON and is agent-native. There is no mention of error conditions, rate limits, or specific response format nuances, but the annotations cover the safety profile. The description doesn't contradict annotations and adds slight value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core action ('Return ranked ExposurePath JSON') in the first sentence, followed by a brief context sentence about its purpose. No wasted words; it's well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a rich output schema and all parameters have descriptions, the description doesn't need to explain return values or parameter syntax. It adequately conveys the tool's purpose and intended use case. The only minor gap is that it doesn't explicitly mention the ranking logic or graph snapshot behavior, but those are covered by 'min_risk' and 'scan_id' descriptions in the schema. Overall, it's sufficiently complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions cover 100% of parameters, so the schema itself fully documents each parameter's purpose. The description adds no additional parameter-specific meaning beyond what's already in the schema. With high schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return ranked ExposurePath JSON for headless security agents.' It specifies a concrete verb, resource, and audience. It also mentions it's the 'agent-native graph surface' and distinguishes it from UI scraping, which differentiates it from sibling tools that might simulate UI interactions or other analysis functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for agents to obtain investigation objects without scraping UI state, implying it's the preferred method for programmatic access. However, it does not explicitly exclude alternatives or name sibling tools like 'scan' or 'intel_lookup' for comparison. Still, the context is strong enough to guide an agent on when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Software Bill of Materials (SBOM) for your AI agent setup.
Discovers AI agents and MCP servers, extracts all package dependencies,
and generates a standards-compliant SBOM.
Args:
format: SBOM format — "cyclonedx" (CycloneDX 1.7) or "spdx" (SPDX 3.0).
config_path: Path to a specific MCP config directory.
If not provided, auto-discovers all local agent configs.
Returns:
JSON string containing the SBOM in the requested format.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | SBOM format: 'cyclonedx' (CycloneDX 1.7) or 'spdx' (SPDX 3.0). | cyclonedx |
| config_path | No | Path to MCP client config directory. Auto-discovers all if omitted. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that the tool discovers agents and servers, extracts dependencies, and generates a standards-compliant SBOM, which is consistent with read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and uses a clear structure with bullet points for arguments and return. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (mentioned in signals) and two optional parameters, the description provides complete context: what the tool does, how parameters work, and the return format. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description adds value by specifying the exact format values ('cyclonedx' and 'spdx') and clarifying config_path auto-discovery behavior, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a Software Bill of Materials (SBOM) for AI agent setups, with specific details on discovering agents, MCP servers, and extracting dependencies. It distinguishes itself from sibling tools like 'scan' or 'inventory' by focusing on SBOM generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (to generate an SBOM) and explains config_path auto-discovery. However, it does not mention when not to use it or compare to alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one advisory from the local threat-intel database.
| Name | Required | Description | Default |
|---|---|---|---|
| advisory_id | Yes | CVE, GHSA, or OSV advisory ID, e.g. CVE-2024-1234 or GHSA-abcd-1234-wxyz. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds 'local threat-intel database' context, indicating no external fetch. No contradiction. However, it doesn't detail behavior on missing IDs or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence that is front-loaded and free of redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simplicity (1 param, output schema exists, annotations rich), the description is nearly complete. Minor gap: no mention of error handling or edge cases like invalid IDs, but output schema likely covers return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema's parameter description already provides detailed format guidance (e.g., 'CVE-2024-1234 or GHSA-abcd-1234-wxyz'). The tool description adds no new parameter-level information beyond 'one advisory,' so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Look up one advisory from the local threat-intel database.' It specifies a specific verb (look up) and resource (advisory from a local database), distinguishing it from siblings like intel_match which likely handle multiple matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific advisory ID is known, but lacks explicit guidance on when to use this tool versus alternatives like intel_match or intel_sources. No mention of when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a security policy against current scan results.
Runs a scan, then evaluates the provided policy rules against the
findings. Policies can gate on severity thresholds, CISA KEV status,
AI risk flags, credential exposure, and denied packages.
Args:
policy_json: JSON string containing policy rules. Example:
{"rules": [{"id": "no-critical", "severity_gte": "critical",
"action": "fail"}, {"id": "no-kev", "kev": true, "action": "fail"}]}
Returns:
JSON with passed (bool), violations list, failure_count, and
warning_count.
| Name | Required | Description | Default |
|---|---|---|---|
| policy_json | Yes | JSON string containing policy rules, e.g. {"rules": [{"id": "no-critical", "severity_gte": "critical", "action": "fail"}]}. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive, and idempotent behavior. The description adds that it runs a scan and evaluates rules, and specifies the return structure (passed, violations, etc.), which is beyond annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with summary, details, and return info, but is slightly verbose. Could be more concise while retaining key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and existence of output schema, the description covers the essential behavior and expected output. However, it lacks details on error handling or edge cases (e.g., invalid policy_json).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by providing an illustrative example of the policy_json format and listing supported rule types (severity, KEV, etc.), enhancing understanding beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it evaluates a security policy against current scan results, with a specific verb and resource. It distinguishes from sibling tools like 'compliance' or 'code_scan' by focusing on custom policy rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's purpose but lacks explicit guidance on when to use it versus alternatives like 'check' or 'should_i_deploy'. It provides context on policy components but no when-not statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a remediation plan for vulnerabilities in your AI agent setup.
Scans for vulnerabilities, then generates actionable fix commands for
each affected package (npm install, pip install), credential scope
reduction guidance, and reports on unfixable vulnerabilities.
Args:
config_path: Path to a specific MCP config directory.
If not provided, auto-discovers all local agent configs.
image: Docker image reference to scan (e.g. "nginx:1.25").
Returns:
JSON with package_fixes (upgrade commands by ecosystem),
credential_fixes (scope reduction steps), and unfixable items.
| Name | Required | Description | Default |
|---|---|---|---|
| image | No | Docker image to scan, e.g. 'nginx:1.25'. | |
| config_path | No | Path to MCP client config directory. Auto-discovers all if omitted. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavior: scanning for vulnerabilities, generating fix commands (npm install, pip install), credential scope reduction guidance, and reporting unfixable items. Annotations (readOnlyHint=true) align with generating instructions without executing them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, scanning, arguments, returns). It is slightly lengthy but each sentence provides relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers all necessary aspects: scanning, fix generation, optional parameters, and return structure. Together with the input and output schema, the description is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds minimal value beyond the schema. It clarifies behavior for config_path (auto-discovers if omitted) and image, but this is largely repetitive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating remediation plans for vulnerabilities in AI agent setups. It specifies scanning for vulnerabilities and producing fix commands, distinguishing it from sibling tools that focus on scanning alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (after vulnerabilities are found) and describes the optional parameters (config_path, image). However, it does not explicitly mention when not to use or compare to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a full AI supply chain security scan and return an AI-BOM.
Point it at a target with one of:
• repo_url — a public git repo URL (cloned + scanned, no checkout)
• config_path — a local project / MCP-config directory
• image — a Docker image
• sbom_path — an existing CycloneDX/SPDX SBOM
• package — a single package or MCP launch command (pair it with
``ecosystem`` when the spec names no launcher)
With none of these, it auto-discovers local MCP clients (Claude Desktop,
Cursor, Windsurf, VS Code Copilot, OpenClaw, etc.).
It extracts package dependencies, looks up CVEs (online via OSV.dev and
advisory sources unless offline mode is requested or configured),
assesses config security (credential exposure, tool access), computes
blast radius, and returns structured results. Scanning is fully static
and read-only — repository and image contents are parsed, never executed.
Returns:
JSON. By default a bounded summary: counts (packages, agents,
findings by severity/category), top findings, affected paths, and a
result_id. Page any full-fidelity section with
scan(result_id=..., section='findings', offset=0, limit=25).
An incomplete scan (e.g. vulnerability source unavailable) is
returned as an error result whose body is still JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| image | No | Docker image to scan (e.g. 'nginx:1.25', 'ghcr.io/org/app:v1'). | |
| limit | No | Maximum items per page of `section` (1-200). | |
| detail | No | JSON output only. 'summary' (default): counts, top findings, affected paths, and a result_id for paged follow-ups. 'full': the whole AI-BOM document, shortened structurally (still valid JSON, with _truncation metadata) if it exceeds the response budget. | summary |
| enrich | No | Enable NVD CVSS, EPSS probability, and CISA KEV enrichment. | |
| offset | No | Zero-based item offset into `section`. | |
| policy | No | Policy object to evaluate alongside scan results, e.g. {"rules": [{"id": "no-critical", "severity_gte": "critical", "action": "fail"}]}. | |
| offline | No | true: use the local vulnerability DB only and skip registry, OSV, GHSA, and NVIDIA network lookups (requires a populated DB from `agent-bom db update`). false: query those sources online. Omitted: online unless the server operator set AGENT_BOM_OFFLINE or AGENT_BOM_VULN_DB_OFFLINE. | |
| package | No | Direct package or MCP launch command to scan, e.g. 'npx @modelcontextprotocol/server-filesystem@2025.1.14' or '@modelcontextprotocol/server-filesystem'. A bare 'name@version' spec is assumed to be npm — pass ``ecosystem`` for anything else. | |
| section | No | Section of a stored result to page, e.g. 'findings', 'blast_radius', 'packages', 'exposure_paths'. | |
| repo_url | No | Public git repository URL to clone and scan, e.g. 'https://github.com/org/repo'. Maps the repo's dependencies, project structure, secrets, IaC, and AI/MCP usage into an AI-BOM. Static and read-only: the repository is shallow-cloned into a temporary directory, scanned without ever executing its code, then deleted. The fastest way to point this tool at a target — no local checkout required. | |
| ecosystem | No | Ecosystem of ``package`` when the spec does not name a launcher: 'npm', 'pypi', 'go', 'cargo', 'maven', 'nuget', 'rubygems', 'composer', 'swift', 'pub', 'hex', 'conda', 'deb', 'apk', or 'rpm'. Omitted, the ecosystem is inferred from the spec (PEP 440 specifiers such as 'flask==0.12.2' are PyPI) and any assumption is reported in the result warnings. | |
| result_id | No | result_id from a previous scan response. With it, no new scan runs: returns that result's summary, or one page of `section`. | |
| sbom_path | No | Path to existing CycloneDX or SPDX JSON SBOM file to ingest. | |
| scorecard | No | Enrich packages with OpenSSF Scorecard scores (requires resolvable GitHub repos). | |
| db_sources | No | Comma-separated DB sources to sync before scanning (e.g. 'nvd,ghsa,osv,epss,kev'). | |
| transitive | No | Resolve transitive dependencies for npx/uvx packages. | |
| config_path | No | Local directory to scan — a project root or an MCP client config directory. Auto-discovers installed MCP clients if omitted unless no_discover=true. Mutually exclusive with repo_url. | |
| no_discover | No | Disable ambient host MCP-client discovery. Explicit repo/config, image, SBOM, and package targets are still scanned; use this for deterministic CI. | |
| fail_severity | No | Return failure status if vulns at this severity or higher: critical, high, medium, low. | |
| output_format | No | Output format: 'json' (default), 'sarif', 'cyclonedx', 'spdx', 'junit', 'csv', or 'markdown'. | json |
| warn_severity | No | Return warning status (gate_status=warn, exit 0) when vulns at this severity or higher exist. Use with fail_severity for two-tier CI gates, e.g. warn_severity='medium', fail_severity='critical'. | |
| auto_update_db | No | Explicitly refresh the local vuln DB when older than the daily freshness target before scanning. | |
| verify_integrity | No | Verify package SHA-256/SRI hashes and SLSA provenance against registries. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing that the scan is fully static — repo/image contents are 'parsed, never executed', shallow-cloned to a temp dir then deleted — whether network lookups happen (OSV/GHSA/NVD unless offline), and that an incomplete scan is returned as an error result whose body is still JSON. These are exactly the operational traits annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then a scannable bullet list of targets, then behavior, then returns. It is somewhat long, but nearly every sentence carries distinct information; only the returns paragraph slightly overlaps with what the output schema already provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a 23-parameter tool with an output schema: it explains target selection, discovery fallback, network/offline posture, mutation-free execution, gating semantics via fail/warn severity, and the summary-vs-paged-full result model. Nothing an agent needs to choose arguments or interpret a response is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics: the mutually exclusive repo_url/config_path relationship, the package+ecosystem pairing, the auto-discovery default when no target is given, and how result_id/section/offset/limit compose into paging. That linkage is meaningfully more than the per-parameter text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Run a full AI supply chain security scan and return an AI-BOM' — and enumerates the five target modes it accepts. It never names a sibling (e.g. generate_sbom or policy_check), so an agent must infer differentiation from the target list alone rather than being routed explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use guidance via the bulleted target list, notes the mutually exclusive relationship with config_path, and explains the no-target auto-discovery fallback. It also documents the paged follow-up pattern (result_id + section). It stops short of exclusions against sibling tools, so it lands at 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.10scan9 fields changedInput schema / properties / detailAdded value: +{
+ "default": "summary",
+ "description": "JSON output only. 'summary' (default): counts, top findings, affected paths, and a result_id for paged follow-ups. 'full': the whole AI-BOM document, shortened structurally (still valid JSON, with _truncation metadata) if it exceeds the response budget.",
+ "enum": [
+ "summary",
+ "full"
+ ],
+ "title": "Detail",
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "default": 25,
+ "description": "Maximum items per page of `section` (1-200).",
+ "maximum": 200,
+ "minimum": 1,
+ "title": "Limit",
+ "type": "integer"
+}Input schema / properties / offline / anyOfAdded value: +[
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / offline / defaultPrevious value: -trueNew value: +nullInput schema / properties / offline / descriptionPrevious value: -"Use the local vulnerability DB only and skip registry, OSV, GHSA, and NVIDIA network lookups."New value: +"true: use the local vulnerability DB only and skip registry, OSV, GHSA, and NVIDIA network lookups (requires a populated DB from `agent-bom db update`). false: query those sources online. Omitted: online unless the server operator set AGENT_BOM_OFFLINE or AGENT_BOM_VULN_DB_OFFLINE."Input schema / properties / offline / typeRemoved value: -"boolean"Input schema / properties / offsetAdded value: +{
+ "default": 0,
+ "description": "Zero-based item offset into `section`.",
+ "minimum": 0,
+ "title": "Offset",
+ "type": "integer"
+}Input schema / properties / result_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "result_id from a previous scan response. With it, no new scan runs: returns that result's summary, or one page of `section`.",
+ "title": "Result Id"
+}Input schema / properties / sectionAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Section of a stored result to page, e.g. 'findings', 'blast_radius', 'packages', 'exposure_paths'.",
+ "title": "Section"
+}exposure_paths1 field changedInput schema / properties / cursorAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 4096,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Continue with pagination.next_cursor; keep the risk filter unchanged.",
+ "title": "Cursor"
+}v1.0.5access_reviewai_inventory_scanaisvs_benchmarkanalytics_queryanomaly_scanapprove_exceptionaudit_integrityaudit_queryblast_radiusbrowser_extension_scancis_benchmarkcloud_inventorycloud_side_scancode_scancontext_graphcost_allocationcost_forecastcost_reportcreate_ticketcredential_expirydataset_card_scandiffdrift_incidentsfindings_triagefirewall_checkfleet_scangateway_statusgpu_infra_scangraph_correlategraph_correlation_statusgraph_exportidentity_grant_jitidentity_issueidentity_revokeidentity_revoke_jitidentity_rotateingest_external_scanintel_daily_briefintel_matchintel_sourcesinventoryinventory_assetinventory_listinventory_summarykspm_cluster_posturelicense_compliance_scanlist_exceptionsmarketplace_checkmodel_file_scanmodel_provenance_scannhi_discoverprompt_scanproxy_alertsproxy_statusregistry_lookupregistry_sweep_scanrequest_exceptionrisk_campaign_workflowruntime_blueprint_driftruntime_blueprintsruntime_correlateruntime_evidence_ingestruntime_production_indexshield_break_glassshield_startshield_statusshield_unblockshould_i_deployskill_scanskill_trustskill_verifysync_ticket_statustool_risk_assessmenttraining_pipeline_scanvector_db_scanverifywhereyoucom_searchv0.103.2runtime_evidence_ingest3 fields changedInput schema / properties / operator_roleRemoved value: -{
- "default": "viewer",
- "description": "Operator role for this write action. Must be admin.",
- "title": "Operator Role",
- "type": "string"
-}Input schema / properties / operator_scopesRemoved value: -{
- "default": "",
- "description": "Comma-separated operator scopes. Must include findings:write.",
- "title": "Operator Scopes",
- "type": "string"
-}Input schema / properties / reasonRemoved value: -{
- "default": "",
- "description": "Human audit reason for ingesting runtime evidence.",
- "title": "Reason",
- "type": "string"
-}graph_correlategraph_correlation_statusinventory_list1 field changedInput schema / properties / severityAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Filter by the asset's highest directly linked finding severity.",
+ "title": "Severity"
+}runtime_evidence_ingest3 fields changedInput schema / properties / operator_roleAdded value: +{
+ "default": "viewer",
+ "description": "Operator role for this write action. Must be admin.",
+ "title": "Operator Role",
+ "type": "string"
+}Input schema / properties / operator_scopesAdded value: +{
+ "default": "",
+ "description": "Comma-separated operator scopes. Must include findings:write.",
+ "title": "Operator Scopes",
+ "type": "string"
+}Input schema / properties / reasonAdded value: +{
+ "default": "",
+ "description": "Human audit reason for ingesting runtime evidence.",
+ "title": "Reason",
+ "type": "string"
+}tool_risk_assessment3 fields changedInput schema / properties / allow_command_executionAdded value: +{
+ "default": false,
+ "description": "Explicitly allow launching unblocked stdio server commands. False only connects to HTTP/SSE servers.",
+ "title": "Allow Command Execution",
+ "type": "boolean"
+}Input schema / properties / timeout / maximumAdded value: +60Input schema / properties / timeout / minimumAdded value: +0.1v0.102.0approve_exceptioncheck1 field changedInput schema / properties / offlineAdded value: +{
+ "default": false,
+ "description": "Use only the local advisory database. An explicit version is required; registry resolution and publication checks are disabled.",
+ "title": "Offline",
+ "type": "boolean"
+}gateway_status4 fields changedInput schema / properties / activity_cursorAdded value: +{
+ "default": "",
+ "description": "Opaque cursor from a prior gateway_status activity response.",
+ "title": "Activity Cursor",
+ "type": "string"
+}Input schema / properties / activity_limitAdded value: +{
+ "default": 100,
+ "description": "Maximum activity events to return when include_activity is true.",
+ "maximum": 500,
+ "minimum": 1,
+ "title": "Activity Limit",
+ "type": "integer"
+}Input schema / properties / include_activityAdded value: +{
+ "default": false,
+ "description": "Include the durable, cursor-paged gateway activity feed.",
+ "title": "Include Activity",
+ "type": "boolean"
+}Input schema / properties / include_self_postureAdded value: +{
+ "default": false,
+ "description": "Include this deployment's tenant-scoped operator self-posture evidence.",
+ "title": "Include Self Posture",
+ "type": "boolean"
+}list_exceptionsrequest_exceptionscan2 fields changedInput schema / properties / config_path / descriptionPrevious value: -"Local directory to scan — a project root or an MCP client config directory. Auto-discovers all installed MCP clients if omitted. Mutually exclusive with repo_url."New value: +"Local directory to scan — a project root or an MCP client config directory. Auto-discovers installed MCP clients if omitted unless no_discover=true. Mutually exclusive with repo_url."Input schema / properties / no_discoverAdded value: +{
+ "default": false,
+ "description": "Disable ambient host MCP-client discovery. Explicit repo/config, image, SBOM, and package targets are still scanned; use this for deterministic CI.",
+ "title": "No Discover",
+ "type": "boolean"
+}v0.101.0blast_radius2 fields changedInput schema / properties / scan_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional persisted scan scope.",
+ "title": "Scan Id"
+}Input schema / properties / tenant_idAdded value: +{
+ "default": "default",
+ "description": "Tenant scope for persisted findings. Defaults to 'default'.",
+ "title": "Tenant Id",
+ "type": "string"
+}cis_benchmark1 field changedInput schema / properties / region / descriptionPrevious value: -"AWS region (only for provider=aws). Defaults to us-east-1."New value: +"Optional AWS region scope. Omit to evaluate CIS across all enabled AWS regions."cloud_side_scanfindings_triagerisk_campaign_workflowyoucom_searchv0.99.0scan2 fields changedInput schema / properties / ecosystemAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Ecosystem of ``package`` when the spec does not name a launcher: 'npm', 'pypi', 'go', 'cargo', 'maven', 'nuget', 'rubygems', 'composer', 'swift', 'pub', 'hex', 'conda', 'deb', 'apk', or 'rpm'. Omitted, the ecosystem is inferred from the spec (PEP 440 specifiers such as 'flask==0.12.2' are PyPI) and any assumption is reported in the result warnings.",
+ "title": "Ecosystem"
+}Input schema / properties / package / descriptionPrevious value: -"Direct package or MCP launch command to scan, e.g. 'npx @modelcontextprotocol/server-filesystem@2025.1.14' or '@modelcontextprotocol/server-filesystem'."New value: +"Direct package or MCP launch command to scan, e.g. 'npx @modelcontextprotocol/server-filesystem@2025.1.14' or '@modelcontextprotocol/server-filesystem'. A bare 'name@version' spec is assumed to be npm — pass ``ecosystem`` for anything else."v0.98.3create_ticketingest_external_scan1 field changedInput schema / properties / scan_json / descriptionPrevious value: -"JSON string from Trivy, Grype, or Syft scan output"New value: +"JSON string containing tool-agnostic SARIF, CycloneDX, SPDX, Trivy, Grype, or Syft evidence"kspm_cluster_postureruntime_evidence_ingestsync_ticket_statusv0.96.2generate_sbom1 field changedInput schema / properties / format / descriptionPrevious value: -"SBOM format: 'cyclonedx' (CycloneDX 1.6) or 'spdx' (SPDX 3.0)."New value: +"SBOM format: 'cyclonedx' (CycloneDX 1.7) or 'spdx' (SPDX 3.0)."inventory_assetinventory_listinventory_summaryScored across 8 tools
scan and generate_sbom both extract dependencies but differ in output (AI-BOM vs SBOM); compliance and policy_check both evaluate security posture but one maps to frameworks and the other enforces custom rules. Most tools have clearly distinct purposes, though some overlap in the underlying scanning could confuse an agent.
Names mix single verbs (scan, check, remediate), nouns (compliance, exposure_paths), and verb_noun compounds (generate_sbom, policy_check, intel_lookup). The inconsistency in verb style and structure reduces predictability, though all are readable.
8 tools is well-scoped for an AI supply chain security server, covering scanning, checking, compliance, SBOM generation, policy, remediation, intel, and exposure paths. No tool feels redundant or unnecessary.
Core lifecycle is covered: scan, check, generate_sbom, compliance, policy_check, remediate, plus intel_lookup and exposure_paths. Missing a dedicated 'list past scans' or policy management tool, but scan's result_id paging mitigates; minor gaps only.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
AWS cloud security scanners for AI agents — S3, IAM, EC2, EKS, RDS, CloudTrail, CloudWatch Logs
MCP server: static security scanner for MCP servers, agent skills & plugins. 17 attack patterns.