Use this server to scan and assess AI/software supply chain security, then act on findings with SBOMs, policies, compliance, remediation, and exposure paths.
Scan: run full static, read-only scans from repo URL, local config, Docker image, existing SBOM, or package; auto-discovers local MCP clients.
Check: look up CVEs for a specific package before installing.
Intel lookup: retrieve one advisory by CVE/GHSA/OSV ID from the local threat-intel database.
Policy check: evaluate policy rules against scan results (severity thresholds, KEV, AI risk, credential exposure, denied packages).
Generate SBOM: produce CycloneDX 1.7 or SPDX 3.0 for AI agent/MCP setups.
Compliance: return compliance posture from persisted tenant evidence or a labelled local scan, with framework/control drill-down.
Remediate: generate package upgrade commands, credential scope-reduction guidance, and unfixable-vulnerability reports.
Exposure paths: retrieve ranked attack-path queue with filters (KEV, severity, credential, node, finding, risk) and summary/full views.
Export/enrich: output JSON, SARIF, CycloneDX, SPDX, JUnit, CSV, Markdown; optionally enrich with NVD CVSS, EPSS, CISA KEV, OpenSSF Scorecard, and integrity verification.
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.
For AppSec and platform engineers responsible for AI agents and MCP servers: scan a repository, correlate its findings with agent and infrastructure context, and prioritize fixes using blast radius and reachability evidence. Open security scanner and self-hosted control plane for AI, MCP, and cloud infrastructure. Local scans need no account.
From the repository you want to inspect:
pip install agent-bom
agent-bom scan .Read the inventory, findings, coverage gaps, and remediation guidance in the terminal.
Save a report with agent-bom scan . -f sarif -o findings.sarif, then
upload it and gate CI.
Run agent-bom doctor if setup fails. See the first-run guide.
No project handy? Run agent-bom scan --demo --offline for a bundled sample.
Exit 1 is expected: the sample trips the security gate. A non-zero exit
can mean a security gate or incomplete assessment; inspect the report and coverage.
See the exit codes.
The recording uses labeled sample data and bundled advisories. Credential references are names, not secret values. Recorded relationships do not prove exploitation or successful data access.
Related MCP server: agent-audit
Which agent uses the vulnerable component? What could it reach? What evidence supports that path? Correlate retained scans by exact, tenant-scoped identities; trace the recorded blast radius from each agent through its MCP servers to packages, findings, credentials and data stores. Inspect each relationship's source and evidence kind, then rescan the same scope to check what changed.
Fictional sample estate. Dashed use, credential and access links are configured or modeled, not observed at runtime; path analysis covers the collected snapshot only.
From agent to verified fix: select Document Intake Agent → inspect CVE-2023-4863 (high, KEV-listed) and the evidence on each arrow → take the proposed remediation → rescan the changed pin and compare snapshots. The comparison verifies the changed input, not a running deployment.
Supporting evidence: one package, three parsed inputs. A repository pin, an
image SBOM and a modeled Kubernetes workload resolve to one pillow@9.0.0. The
image inventory and the deployment occurrence stay separate nodes; the advisory
receipt is open.
Real parsers, modeled infrastructure; a graph path does not prove exploitation.
Explore context, correlation and reachability · Run the reference lab · Reproduce these screenshots
Trace source imports, deployment configuration and CI to a published container and its vulnerable packages:
Follow a public API gateway into a vulnerable workload, its role and a PII bucket:
pip install 'agent-bom[ui]==0.109.0'
agent-bom quickstart --run --offlineRun the server command it prints, then open its graph URL. Offline quickstart skips package-CVE lookup, so zero CVEs is not a clean verdict; use the bundled demo for advisory-backed findings or populate the advisory database.
Your infrastructure, identity, database, and audit boundary. Start a local pilot from a published release checkout:
git clone --depth 1 --branch v0.109.0 https://github.com/koda-ai-studio/agent-bom.git && cd agent-bom
AGENT_BOM_IMAGE_TAG=0.109.0 docker compose up -dOpen http://localhost:3000, then Connections or New Scan. The pilot binds to loopback and retains state in a Docker volume. For cloud accounts, add a scoped read-only connection, verify access, then start a scan. Use the authenticated deployment.
Scan with CLI or CI; export findings, SBOMs and reports.
Centralize inventory, graph evidence, remediation and compliance in your own control plane.
Enforce policy on selected live MCP tool calls through the proxy or gateway.
Docker pilot guide · Compose with PostgreSQL · Choose a deployment · Enterprise controls · 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.
For coding assistants, run agent-bom mcp server.
In Claude Code, install the plugin with /plugin marketplace add koda-ai-studio/agent-bom
then /plugin install agent-bom@agent-bom (details).
Start with eight focused tools in the default profile.
Choose an MCP profile for graph, cloud, runtime or audit work.
Try three investigations: affected agents, exposure receipts and a before/after scan comparison.
Import existing scanner reports without replacing their source evidence.
Prefer an isolated invocation? Use uvx agent-bom scan . or check a dependency
with uvx agent-bom check requests@2.33.0 --ecosystem pypi. Add
pre-commit and CI setup for repeated checks.
Proxy, gateway and fleet · Integration capability matrix · MCP client setup · Smithery setup and manifest
Discovery uses read-only access by default. Explicit disk side-scans create temporary cloud resources. Missing evidence stays unavailable or partial; control mappings are not audit certification.
MITRE technique associations provide investigation context, not proof of an attack. ATLAS mapping receipts retain the weakness association and source catalog hashes; modeled graph paths do not establish observed execution or effective access.
Measured matcher proof · Product boundaries · Permissions · Threat model · Release verification · Graph data model
Contributing · Capabilities and roadmap · Support · Report an inaccurate finding · Apache-2.0
Source version: v0.110.0 · Latest release: v0.109.0 · Changelog
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.
Return compliance posture with its source: the tenant's persisted evidence, or a labelled local scan.
With completed scans in the control plane, ``summary`` is exactly
``/v1/compliance/summary``; ``framework`` adds ``/v1/compliance/{framework}``
and ``control`` pages the driving finding ids from
``/v1/findings?framework=&control=``. Otherwise (or with
source='local_scan') it scans local MCP configurations and labels that scope.
| Name | Required | Description | Default |
|---|---|---|---|
| image | No | Local scan only: Docker image to scan, e.g. 'nginx:1.25'. | |
| limit | No | Driving finding ids per page. | |
| cursor | No | driving_findings.next_cursor from the previous page. | |
| source | No | auto: persisted tenant evidence when it exists, else a labelled local scan. persisted / local_scan force one. | auto |
| control | No | Persisted only: page the finding ids driving this control. | |
| framework | No | Persisted only: add one framework's controls, e.g. 'soc2'. | |
| tenant_id | No | Tenant scope for persisted compliance. Defaults to 'default'. | default |
| config_path | No | Local scan only: MCP client config directory. Auto-discovers if omitted. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only, idempotent, open-world profile, so the description is not carrying the safety burden. It adds real behavioural context beyond that: the auto/persisted/local_scan resolution rule, that local results are labelled by scope, and that framework/control only apply to the persisted path.
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 first sentence is well front-loaded, but the rest is dense with internal REST paths such as ``/v1/compliance/summary`` and ``/v1/findings?framework=&control=`` that an agent does not need in order to choose or call the tool. It also refers to ``summary``, which is not a parameter name, creating ambiguity about whether these are inputs or output fields.
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?
With an output schema present, the description need not explain return values, and coverage for the 8 parameters is complete. The mode-selection logic is explained well; only the absence of sibling routing guidance and the missing mention of a local-scan cost/side-effect profile keep it short of full completeness.
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 a 3 is the baseline, but the description goes further by tying parameters together (framework adds one framework's controls, control pages the finding ids driving it, cursor derives from driving_findings.next_cursor) and by restricting framework/control to persisted mode. That is meaningfully more than the per-parameter schema 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+resource: return compliance posture, and explicitly names the two modes (persisted tenant evidence vs. a labelled local scan). This differentiates it reasonably from scan/check siblings, though it never names those siblings directly to say which to prefer.
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 clear conditional guidance: with completed scans in the control plane the result comes from persisted evidence, otherwise (or when source='local_scan') it falls back to scanning local MCP configurations. It lacks any exclusion against the sibling tools (check, scan, policy_check), which is the main gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the attack-path queue in the dashboard's order, with why each path ranks where it does.
Ranking is ``ranking.order`` (evidence tier, KEV, severity, composite risk,
credential count); every path carries ``rank``, ``evidenceTier``, ``isKev`` and
``severity``. Totals, filters and cursor pages match ``/v1/graph/attack-paths``.
| Name | Required | Description | Default |
|---|---|---|---|
| kev | No | Only paths through a known-exploited finding (true) or none (false). | |
| view | No | summary (default): rank, risk, KEV, evidence tier, endpoints, finding/credential ids. full adds hops, relationships, nodes and edges. | summary |
| limit | No | Maximum ranked exposure paths to return. | |
| cursor | No | pagination.next_cursor; keep the filters unchanged. | |
| node_id | No | Any graph node the path passes through. | |
| scan_id | No | Optional historical scan ID. Omit for the current tenant estate. | |
| min_risk | No | Minimum composite path risk (0-100). | |
| target_id | No | Only paths ending at this graph node id. | |
| tenant_id | No | Tenant scope. Defaults to 'default'. | default |
| finding_id | No | CVE, advisory or finding node id on the path. | |
| source_type | No | Entrypoint entity type, e.g. 'agent'. | |
| min_severity | No | Worst on-path finding at least this severe. | |
| credential_id | No | Credential name or node id exposed on the path. | |
| has_credential | No | Only paths that do (true) or do not (false) expose a credential. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, and the description adds real value: the exact ranking inputs (evidence tier, KEV, severity, composite risk, credential count), the per-path fields, and cursor-page/filter parity with the underlying endpoint. It omits auth or rate-limit notes, but the ranking semantics are the meaningful disclosure here.
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 purpose and the ranking explanation are front-loaded in the first sentence, with the ranking-field detail following. Three sentences for a fourteen-parameter ranked-query tool is appropriately sized, though the second paragraph is dense and slightly redundant with the per-path field list.
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 high-parameter, read-only ranked listing with an output schema, the description supplies what the structured fields cannot: the ordering key composition and the fact that filters/pagination mirror the equivalent REST endpoint. Nothing needed to call it correctly appears to be 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 description coverage is 100%, so the baseline is 3 and the schema already carries all fourteen parameters with per-parameter meaning. The description adds nothing parameter-specific beyond noting that filters and cursor pages behave like '/v1/graph/attack-paths', which is a restatement rather than new syntax or constraint detail.
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 ('Return the attack-path queue') plus the differentiator that makes this tool unique: results are ordered by dashboard ranking and each path explains why it ranks there. No sibling (scan, check, remediate, intel_lookup) overlaps this ranked-exposure-queue role.
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?
Usage is only implied: the mention that totals, filters and cursor pages match '/v1/graph/attack-paths' tells an agent the semantics carry over, but there is no explicit when-to-use statement, no guidance on summary vs full view, and no routing away from siblings like scan or check.
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.12compliance8 fields changedInput schema / properties / config_path / descriptionPrevious value: -"Path to MCP client config directory. Auto-discovers all if omitted."New value: +"Local scan only: MCP client config directory. Auto-discovers if omitted."Input schema / properties / controlAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 64,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Persisted only: page the finding ids driving this control.",
+ "title": "Control"
+}Input schema / properties / cursorAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 512,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "driving_findings.next_cursor from the previous page.",
+ "title": "Cursor"
+}Input schema / properties / frameworkAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 64,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Persisted only: add one framework's controls, e.g. 'soc2'.",
+ "title": "Framework"
+}Input schema / properties / image / descriptionPrevious value: -"Docker image to scan, e.g. 'nginx:1.25'."New value: +"Local scan only: Docker image to scan, e.g. 'nginx:1.25'."Input schema / properties / limitAdded value: +{
+ "default": 50,
+ "description": "Driving finding ids per page.",
+ "maximum": 500,
+ "minimum": 1,
+ "title": "Limit",
+ "type": "integer"
+}Input schema / properties / sourceAdded value: +{
+ "default": "auto",
+ "description": "auto: persisted tenant evidence when it exists, else a labelled local scan. persisted / local_scan force one.",
+ "enum": [
+ "auto",
+ "persisted",
+ "local_scan"
+ ],
+ "title": "Source",
+ "type": "string"
+}Input schema / properties / tenant_idAdded value: +{
+ "default": "default",
+ "description": "Tenant scope for persisted compliance. Defaults to 'default'.",
+ "title": "Tenant Id",
+ "type": "string"
+}exposure_paths13 fields changedInput schema / properties / credential_idAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 512,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Credential name or node id exposed on the path.",
+ "title": "Credential Id"
+}Input schema / properties / cursor / descriptionPrevious value: -"Continue with pagination.next_cursor; keep the risk filter unchanged."New value: +"pagination.next_cursor; keep the filters unchanged."Input schema / properties / finding_idAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 512,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "CVE, advisory or finding node id on the path.",
+ "title": "Finding Id"
+}Input schema / properties / has_credentialAdded value: +{
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only paths that do (true) or do not (false) expose a credential.",
+ "title": "Has Credential"
+}Input schema / properties / kevAdded value: +{
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only paths through a known-exploited finding (true) or none (false).",
+ "title": "Kev"
+}Input schema / properties / limit / descriptionPrevious value: -"Maximum number of ranked exposure paths to return."New value: +"Maximum ranked exposure paths to return."Input schema / properties / min_risk / descriptionPrevious value: -"Minimum path risk score to include."New value: +"Minimum composite path risk (0-100)."Input schema / properties / min_severityAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "critical",
+ "high",
+ "medium",
+ "low"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Worst on-path finding at least this severe.",
+ "title": "Min Severity"
+}Input schema / properties / node_idAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 512,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Any graph node the path passes through.",
+ "title": "Node Id"
+}Input schema / properties / source_typeAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 64,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Entrypoint entity type, e.g. 'agent'.",
+ "title": "Source Type"
+}Input schema / properties / target_idAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 512,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Only paths ending at this graph node id.",
+ "title": "Target Id"
+}Input schema / properties / tenant_id / descriptionPrevious value: -"Tenant ID for the graph snapshot. Defaults to 'default'."New value: +"Tenant scope. Defaults to 'default'."Input schema / properties / viewAdded value: +{
+ "default": "summary",
+ "description": "summary (default): rank, risk, KEV, evidence tier, endpoints, finding/credential ids. full adds hops, relationships, nodes and edges.",
+ "enum": [
+ "summary",
+ "full"
+ ],
+ "title": "View",
+ "type": "string"
+}v1.0.11exposure_paths1 field changedInput schema / properties / scan_id / descriptionPrevious value: -"Optional graph scan ID. Omit to use the latest snapshot."New value: +"Optional historical scan ID. Omit for the current tenant estate."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_statusScored across 8 tools
Most tools have distinct purposes (compliance, policy_check, remediate, exposure_paths, intel_lookup), but scan, check, and generate_sbom overlap: scan already performs per-package CVE lookups and produces an AI-BOM, so an agent could reasonably pick check or generate_sbom when scan would suffice. The descriptions help but boundaries between the broad scan and the narrower check/generate_sbom are blurry.
Names mix verb_noun forms (generate_sbom, intel_lookup, policy_check, exposure_paths) with bare single nouns/verbs (scan, check, compliance, remediate). All are snake_case so casing is consistent, but the verb-vs-noun convention is not uniform, making the pattern only partially predictable.
Eight tools is well within the ideal range and each covers a plausible, non-redundant stage of an AI supply-chain security workflow. The scope feels tight and deliberate rather than padded.
The surface covers the full lifecycle: scan/discover, check dependencies, generate SBOM, assess compliance and policies, look up intel, rank attack paths, and remediate. Minor gaps remain (e.g., no explicit findings retrieval/compare across historical scans beyond cursor paging), but core workflows are covered.
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
Security scanner for AI-written code: SAST, secrets, dependencies, IaC, containers and DAST.