agent-bom is an MCP security server for discovering, scanning, correlating, and remediating AI/MCP supply-chain risk.\n\n- Run full static, read-only AI-BOM scans of git repos, local project/MCP configs, Docker images, existing SBOMs, or single packages/MCP launch commands.\n- Auto-discover local MCP clients (Claude Desktop, Cursor, Windsurf, VS Code Copilot, etc.) when no target is given.\n- Check packages for known CVEs via OSV.dev with optional version, ecosystem, and offline mode.\n- Look up CVE, GHSA, or OSV advisories from the local threat-intel database.\n- Return ranked exposure paths from security graph snapshots for headless investigation.\n- Evaluate security policies against scan results, gating on severity, CISA KEV, AI risk, credential exposure, and denied packages.\n- Generate CycloneDX 1.7 or SPDX 3.0 SBOMs for AI agent and MCP server setups.\n- Assess compliance against OWASP LLM Top 10, OWASP MCP Top 10, MITRE ATLAS, and NIST AI RMF controls.\n- Generate remediation plans with package upgrade commands, credential scope reduction guidance, and unfixable vulnerability reports.\n- Output scan results in JSON, SARIF, CycloneDX, SPDX, JUnit, CSV, or Markdown, with optional enrichment from NVD, EPSS, CISA KEV, and OpenSSF Scorecard.
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.
agent-bom finds the AI agents, MCP servers, packages and credentials in a repository, workstation or cloud account, matches packages against vulnerability advisories, and connects findings to recorded agent, tool and credential relationships. Run it as a CLI, in CI, as an MCP server for your assistant, or as a self-hosted dashboard. A recorded relationship is evidence to investigate; it does not prove execution or data access. The map above uses labeled sample data. Light view · Dark view.
Start where you work: scan a repository, run the shared dashboard, or connect your assistant. Apache-2.0; the control plane runs in your own environment.
Your infrastructure, your identity, your database, your audit boundary. From a published release checkout:
git clone --depth 1 --branch v0.107.2 https://github.com/msaad00/agent-bom.git && cd agent-bom
AGENT_BOM_IMAGE_TAG=0.107.2 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 for a shared instance.
Docker pilot · Authenticated deployment · Compose with PostgreSQL · Helm · EKS Terraform · Snowflake Native App preview · Air-gapped bundle · Choose a deployment · Enterprise configuration · Connect cloud accounts
Use CLI or GitHub Action, REST API, or MCP; export SARIF, CycloneDX, SPDX, JSON and HTML. Cloud connectors and fleet sync collect inventory; proxy and gateway deployments add runtime evidence.
Integration capability matrix · MCP client setup · Proxy, gateway and fleet · Smithery setup and manifest
Related MCP server: agent-audit
Scan a repository and keep the evidence:
pip install agent-bom
agent-bom scan . -f json -o scan.jsonOpen scan.json for findings and assessment coverage. For pull requests, use agent-bom scan . -f sarif -o findings.sarif and upload the artifact in CI.
For sample inventory and an exact graph link, run agent-bom quickstart --run --offline. It skips package-CVE lookup; use the bundled demo for advisory-backed examples. Follow the first-run handoff.
agent-bom scan --demo --offline lists sample agents, CVEs with recorded agent, MCP server and credential associations, and policy findings (excerpt from current source; installed-release output may differ):
Security posture: CRIT 7 HIGH 10 MED 6 · all finding categories
5 agents · 10 servers · 23 packages
DISCOVER | Agents
Agent Type Servers Pkgs Creds Vulns
langchain-service custom 2 4 4 4
claude-desktop claude-desktop 2 6 3 5
ANALYZE | Critical Details
CVE-2023-36258 · langchain@0.0.150 · CRITICAL
Fix: upgrade to ≥ 0.0.247
Blast: langchain-service → llm-orchestrator-server → ANTHROPIC_API_KEY, OPENAI_API_KEY
ANALYZE | Graph & Policy Findings (8 occurrences)
CRIT COMBINATION AI agent can reach a credential or privileged tool: langchain-service
HIGH PROMPT_SECURITY Agent calls MCP server without verified identity
MED PROMPT_SECURITY Long-lived static credential on MCP serverThe sample deliberately triggers a security gate (exit 1). Save CI evidence with agent-bom scan . -f sarif -o findings.sarif; check setup with agent-bom doctor. First-run guide · GitHub Action
Give assistants the same evidence: agent-bom mcp server (MCP support is included by default).
Source version: v0.107.2 · Latest release: v0.107.2. Start with eight focused tools, then select a graph, cloud, runtime or audit
profile. The full catalog has 88 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
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. |
Start with Posture, inspect evidence in Top risks, and scope inventory in Assets & coverage. Compliance separates evaluated-control pass rate from assessment coverage. OWASP and MITRE ATLAS risk mappings describe applicability, not control pass/fail. The offline synthetic enterprise estate includes evaluated checks; results do not establish certification or an audit opinion.
Explore Top risks, scoped Inventory, recorded scan history, framework controls and evidence, and the per-agent BOM preview.
Follow CVE-2023-4863 in pillow@9.0.0 through recorded relationships between the service, container, tool, workload identity and modeled data asset. Inspect the source receipts and carry the selected finding into remediation. A recorded path does not by itself prove exploitation or successful data access.
Choose a scope in Summary, then Inspect an entity. Filter by type or severity, set direction and hop limits, and expand bounded pages; incomplete views are labeled. In Context, use Focus here, Back, or an exact identifier. Select a node or arrow to inspect its evidence, freshness and unknowns. Investigate reach & permissions opens permission receipts, CVE prerequisites and related activity; missing exploitability stays not assessed. Investigation workflow.
Connect data locations to security evidence. Explore recorded stores and datasets alongside identities and findings. Distinguish storage, access evidence and collection sources; derived classifications do not prove contents or successful reads. Data and evidence model.
Review findings by priority, affected asset and evidence. Open remediation for 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
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. | |
| 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.