agent-bom is a comprehensive AI supply chain security scanner and runtime enforcement MCP server for discovering, assessing, and remediating vulnerabilities across AI agent infrastructure, MCP servers, and dependencies.
Core Scanning & Discovery
scan – Full AI supply chain scan: auto-discovers MCP configs (Claude Desktop, Cursor, Windsurf, VS Code Copilot, etc.), extracts packages, queries OSV.dev for CVEs, assesses credential exposure, computes blast radius, and returns a structured report. Supports Docker image scanning, policy evaluation, SBOM ingestion, and NVD/EPSS/CISA KEV enrichment.
inventory – Fast discovery and package extraction without CVE scanning; quick inventory of MCP configs, servers, packages, and transport types.
where – List all MCP client config discovery paths and show which files exist on the current system.
check – Check a specific package (npm, PyPI, Go, Cargo, Maven, NuGet) for known CVEs before installing, with severity, CVSS score, and fix version.
Risk Analysis
blast_radius – Map the full attack chain for a CVE: affected packages → MCP servers → agents → exposed credentials and tools.
context_graph – Build an agent context graph with lateral movement analysis (BFS paths) to answer "if agent X is compromised, what else is reachable?"
runtime_correlate – Cross-reference scan results with proxy runtime audit logs to identify which vulnerable tools were actually called in production.
Policy, Compliance & Remediation
policy_check – Evaluate security policy rules (severity thresholds, CISA KEV, AI risk flags, denied packages) against scan results; returns pass/fail with violations.
compliance – Map findings to 47 controls across OWASP LLM Top 10, OWASP MCP Top 10, MITRE ATLAS, and NIST AI RMF with per-control status and an overall score.
remediate – Generate actionable fix commands (npm/pip upgrades), credential scope reduction guidance, and flag unfixable vulnerabilities.
cis_benchmark – Run CIS Foundations Benchmark checks against AWS (18 checks) or Snowflake (12 checks) with per-check pass/fail results.
Trust & Integrity
skill_trust – Assess SKILL.md/instruction files across 5 trust categories with a benign/suspicious/malicious verdict.
verify – Verify package integrity via SHA-256/SRI hashes and SLSA build provenance attestations against npm/PyPI registries.
marketplace_check – Pre-install trust check for an MCP server package: download count, CVE status, registry verification, and trust signals.
registry_lookup – Query the built-in threat intelligence registry (109+ MCP servers) for risk level, known tools, credential requirements, and verification status.
Advanced Capabilities
generate_sbom – Generate a standards-compliant SBOM in CycloneDX 1.6 or SPDX 3.0 format.
diff – Compare a fresh scan against a baseline to identify new/resolved vulnerabilities and package inventory changes.
code_scan – Run SAST via Semgrep on source code to detect SQL injection, XSS, command injection, hardcoded credentials, and more.
fleet_scan – Batch-scan a list of MCP server names against the security registry for fleet-wide risk assessment.
analytics_query – Query vulnerability trends, posture history, and runtime event summaries from ClickHouse.
Additional features: real-time runtime enforcement proxy with behavioral attack pattern detection, MCP config drift watching, SIEM integration (Splunk, Datadog, Elasticsearch), output in JSON/SARIF/HTML/Mermaid formats, and AI-specific scanning for GPU/ML packages and model provenance (HuggingFace, Ollama, MLflow, W&B).
Scans AWS cloud infrastructure and Amazon Q configurations to identify security vulnerabilities and ensure compliance with CIS benchmarks.
Integrates with ClickHouse to provide security scan analytics, visualization, and posture scoring for AI infrastructure.
Performs security scanning of Databricks environments to detect misconfigurations and dependency vulnerabilities.
Scans Docker images and Docker-based MCP servers for security risks, tool poisoning, and dependency vulnerabilities.
Integrates as a CI/CD gate to automate security scans and enforce compliance policies during the development lifecycle.
Supports deployment and fleet-wide security scanning of AI agent infrastructure within Kubernetes using Helm charts.
Discovers and analyzes JetBrains AI configurations to identify potential credential leaks and security risks.
Enables dispatching security alerts and vulnerability findings to Jira for incident management and remediation tracking.
Scans Kubernetes clusters to map vulnerability propagation and assess the security posture of AI agent deployments.
Discovers and scans MLflow platforms to identify security risks and verify the provenance of AI models.
Provides integration with OpenTelemetry for monitoring and tracing the security scan pipeline and execution.
Dispatches real-time security alerts and scan reports to Slack channels via webhooks for immediate notification.
Provides governance and security scanning for Snowflake instances, including compliance checks against CIS Snowflake benchmarks.
Generates standardized Software Bill of Materials (SBOM) reports in the SPDX format for security compliance and transparency.
Analyzes security risks and maps the blast radius for AI agent tools and MCP servers utilizing SQLite databases.
Your team | What you can do |
Developers & AI engineers | Inspect repositories, dependencies and MCP configuration; bring findings into CI and coding assistants. |
AppSec & cloud security | Connect cloud accounts, trace findings through workloads and identities, and prioritize fixes by reachable impact. |
Platform & DevOps | Run a shared control plane, collect fleet evidence, and apply policy to MCP traffic through the proxy or gateway. |
GRC & audit | Open Compliance to review mappings and export scan evidence with its source, freshness and assessment gaps. |
Security & engineering leaders | Open Overview to review posture, remediation priorities and tracked AI spend across connected sources. |
AI assistants & automation | Use MCP workflows to query evidence and inspect findings within the caller’s permissions. |
Related MCP server: agent-audit
See the current risk posture, critical findings, assessment coverage and tracked AI spend together. Open the underlying evidence before assigning a priority.
Follow CVE-2023-4863 in pillow@9.0.0 from its service and container through the tool, workload identity and reachable data asset. Inspect the source receipts and carry the selected finding into remediation.
Review findings by priority, affected asset, detection evidence and available fix. Open remediation to compare package upgrades and mapped controls, assign owners, set SLAs and re-scan to verify fixes.
These are application captures, not mockups. Overview, Findings and remediation use labeled sample data. The graph uses the reproducible reference lab: real parsers, a pinned advisory scan and authenticated gateway calls, with modeled infrastructure. A blocked call does not establish that the underlying package was fixed.
Discover and scan · Runtime policy and agent workflows · Run the reference evidence lab · Evidence workflow · Control-plane architecture
Your infrastructure, your identity, your database, your audit boundary. Run the control plane on a workstation, a VM or your Kubernetes cluster. Connect the sources you need and add fleet collection or runtime enforcement as teams adopt them. The deployment guides cover credentials, persistence and access controls for each supported path.
For a workstation pilot, run from a published release checkout:
docker compose up -dOpen http://localhost:3000, then Connections or New Scan. For cloud accounts, add a scoped read-only connection, verify access, then start a scan. The pilot binds to loopback and retains state in a Docker volume. Use the authenticated deployment guide below for a shared instance.
Where you run it | Start here |
Workstation evaluation | Docker pilot — packaged API, dashboard and persistent state |
Shared VM / private cloud | Authenticated deployment · Compose profile — PostgreSQL and configured identity |
Kubernetes | |
Snowflake | |
Restricted networks |
Choose a deployment · Enterprise configuration · Connect cloud accounts
Use the CLI or GitHub Action in CI, the REST API for automation, and MCP from coding assistants. Export SARIF, CycloneDX, SPDX, JSON and HTML for downstream workflows. Cloud connectors and fleet sync feed the control plane; proxy and gateway deployments contribute runtime evidence.
Integration capability matrix · MCP client setup · Proxy, gateway and fleet · Smithery setup and manifest
Scan a repository:
pip install agent-bom
agent-bom scan .Save CI evidence with agent-bom scan . -f sarif -o findings.sarif.
Use agent-bom doctor to check setup. First-run guide
Try the CLI demo: agent-bom scan --demo --offline.
The synthetic sample deliberately triggers a security gate (exit 1).
The recording runs the offline command and pages its output for readability.
Give assistants access to the same evidence:
pip install 'agent-bom[mcp-server]'
agent-bom mcp serverStart with eight focused tools, then select a graph, cloud, runtime or audit profile. The full catalog has 86 MCP tools, 7 resources, and 8 workflow prompts. MCP workflows
Use uvx agent-bom scan . without a global install, or
uvx agent-bom check requests@2.33.0 --ecosystem pypi before adding a package.
For automatic dependency and secret gates, see
pre-commit and CI setup.
agent-bom db update --osv-ecosystem PyPI covers only the selected ecosystem;
add the ecosystems you need before running agent-bom scan . --offline.
The full agent-bom db update --source osv archive can exceed 1 GB; the command shows live progress.
A non-zero exit can mean a security gate or incomplete assessment: inspect the
report and coverage. Exit codes
Discovery uses read-only access by default. Explicit disk side-scans create temporary cloud resources; runtime enforcement acts on selected tool calls. Missing evidence stays unavailable or partial. Control mappings are not audit certification.
Product boundaries · Permissions · Threat model · Security policy · Release verification · Measured matcher proof
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. | |
| 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 convey readOnly, idempotent, and openWorld hints. The description adds context about the output being ranked and identical to dashboard objects, but does not disclose potential limits, error handling, or performance traits. It complements annotations without contradiction.
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 two sentences that deliver the core purpose and context without waste. The main action is front-loaded in the first sentence, and the second sentence adds relevant user audience information. 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 the tool's complexity (4 parameters, rich annotations, and an output schema), the description provides sufficient context about the intended users and use case. The presence of an output schema covers return values, and annotations cover safety, making the description 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%, so all four parameters are already well-documented in the schema. The description does not add any additional meaning or constraints beyond what the schema provides, meeting the baseline for this dimension.
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 returns ranked ExposurePath JSON for headless security agents. It mentions specific MCP clients and distinguishes itself as the 'agent-native graph surface', differentiating from siblings like blast_radius or context_graph. However, it could more explicitly contrast with similar graph tools.
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 indicates the tool is for headless agents and lists target clients, but it does not provide explicit guidance on when to use this tool versus alternatives like blast_radius or graph_export. No when-not-to-use or alternative references are given, only implicit context.
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, queries OSV.dev for CVEs, 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 with the complete AI-BOM report including agents, packages,
vulnerabilities, blast radius, and remediation guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| image | No | Docker image to scan (e.g. 'nginx:1.25', 'ghcr.io/org/app:v1'). | |
| enrich | No | Enable NVD CVSS, EPSS probability, and CISA KEV enrichment. | |
| policy | No | Policy object to evaluate alongside scan results, e.g. {"rules": [{"id": "no-critical", "severity_gte": "critical", "action": "fail"}]}. | |
| offline | No | Use the local vulnerability DB only and skip registry, OSV, GHSA, and NVIDIA network lookups. | |
| 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. | |
| 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. | |
| 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?
Beyond the annotations (readOnlyHint, destructiveHint), the description adds crucial behavioral detail: 'Scanning is fully static and read-only — repository and image contents are parsed, never executed.' It also discloses that repos are shallow-cloned into a temporary directory, scanned, and deleted. This goes well beyond the annotations and reassures an agent about side effects.
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 a clear opening line, bulleted target options, a compact summary of the scan process, and a Returns section. Every sentence earns its place; there is no filler. The front-loaded purpose and scannable list make it easy for an agent to parse quickly.
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 tool with 18 parameters and a rich output schema, the description is remarkably complete. It covers all target types, the scanning methodology, the static/read-only safety guarantee, and the return format. The existence of an output schema means the description need not detail the JSON structure. The description leaves no critical gap for an agent to call the tool 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?
Schema coverage is 100%, so the schema already documents each parameter with rich descriptions. The tool description adds value by explaining how parameters interact (e.g., package requires ecosystem when no launcher is named) and the auto-discovery behavior when no target is given. This contextual information helps an agent choose parameters correctly without re-reading the schema, though it doesn't describe individual parameters' formats or defaults beyond what the schema provides.
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 and resource: 'Run a full AI supply chain security scan and return an AI-BOM.' It then enumerates the distinct target types (repo_url, config_path, image, sbom_path, package) and outlines what the scan does (extract dependencies, query OSV, assess config, compute blast radius). This clearly distinguishes it from siblings like skill_scan or vector_db_scan, which target narrower scopes.
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 gives explicit guidance on how to select a target: 'Point it at a target with one of...' and explains the auto-discovery fallback when none is provided. It also clarifies the pairings of package with ecosystem and the mutual exclusivity of config_path and repo_url. However, it does not explicitly name alternative tools or state when not to use this tool versus siblings, leaving some inference to the agent.
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.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_summaryv0.93.0check1 field changedInput schema / properties / versionAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "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.",
+ "title": "Version"
+}ingest_external_scan3 fields changedInput schema / properties / parse_onlyAdded value: +{
+ "default": false,
+ "description": "When true, parse locally only. When false, bulk-ingest to the control plane when AGENT_BOM_API_URL and credentials are configured.",
+ "title": "Parse Only",
+ "type": "boolean"
+}Input schema / properties / reconcile_absentAdded value: +{
+ "default": false,
+ "description": "When pushing, mark findings absent from this batch as resolved.",
+ "title": "Reconcile Absent",
+ "type": "boolean"
+}Input schema / properties / sourceAdded value: +{
+ "default": "external_scan",
+ "description": "Source label stored on ingested findings.",
+ "title": "Source",
+ "type": "string"
+}v0.90.0registry_sweep_scanv0.89.2access_reviewanomaly_scancloud_inventorycost_allocationcost_forecastcost_reportcredential_expirydrift_incidentsidentity_grant_jitidentity_issueidentity_revokeidentity_revoke_jitidentity_rotatenhi_discoverscan2 fields changedInput schema / properties / config_path / descriptionPrevious value: -"Path to MCP client config directory. Auto-discovers all if omitted."New 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."Input schema / properties / repo_urlAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "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.",
+ "title": "Repo Url"
+}v0.88.4ai_inventory_scanaisvs_benchmarkanalytics_queryaudit_integrityaudit_queryblast_radiusbrowser_extension_scancheckcis_benchmarkcode_scancompliancecontext_graphdataset_card_scandiffexposure_pathsfirewall_checkfleet_scangateway_statusgenerate_sbomgpu_infra_scangraph_exportingest_external_scanintel_daily_briefintel_lookupintel_matchintel_sourcesinventorylicense_compliance_scanmarketplace_checkmodel_file_scanmodel_provenance_scanpolicy_checkprompt_scanproxy_alertsproxy_statusregistry_lookupremediateruntime_blueprint_driftruntime_blueprintsruntime_correlateruntime_production_indexscanshield_break_glassshield_startshield_statusshield_unblockshould_i_deployskill_scanskill_trustskill_verifytool_risk_assessmenttraining_pipeline_scanvector_db_scanverifywhereScored across 8 tools
Each tool has a clearly distinct purpose: check for single-package CVE pre-check, scan for comprehensive AI-BOM generation, remediate for fix plans, policy_check for policy evaluation, compliance for framework posture, generate_sbom for SBOM output, intel_lookup for advisory details, and exposure_paths for graph data. No overlapping or ambiguous boundaries.
All tool names are lowercase and use snake_case, but not strictly verb_noun (e.g., compliance and exposure_paths are nouns). However, most are action-oriented and predictable, so the set is readable and consistent in style with minor deviations.
With 8 tools, the server is well-scoped for an AI supply chain security domain. Each tool addresses a distinct stage or aspect (pre-check, full scan, SBOM, compliance, policy, remediation, intel, exposure paths), and none feel redundant or excessive.
The tool surface covers the core lifecycle well: scanning, checking, SBOM generation, compliance, policy evaluation, remediation, and threat intel. Minor gaps exist, such as a dedicated tool to update threat intel or manage vulnerability exceptions, but these are not critical to the primary workflows.
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
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.