One-line summary: agent-bom's MCP server provides read-only security scanning, CVE checks, SBOM generation, policy/compliance evaluation, remediation planning, and ranked exposure-path analysis for AI agents, MCP servers, repos, images, packages, and SBOMs.
scan — Run a full AI supply-chain scan against a repo URL, local config/project path, Docker image, existing CycloneDX/SPDX SBOM, or package/MCP launch command (or auto-discover local MCP clients); returns counts, top findings, affected paths, and a result_id for paged follow-ups, with optional enrichment, severity gates, integrity checks, and JSON/SARIF/CycloneDX/SPDX/JUnit/CSV/Markdown output.
check — Look up known CVEs for a specific package/version in a given ecosystem (npm, PyPI, Go, etc.) before installing it.
intel_lookup — Retrieve a single advisory (CVE, GHSA, or OSV ID) from the local threat-intel database.
policy_check — Evaluate policy rules (severity thresholds, CISA KEV, AI risk flags, credential exposure, denied packages) against scan results, returning pass/fail, violations, and warning counts.
generate_sbom — Generate a standards-compliant SBOM (CycloneDX 1.7 or SPDX 3.0) for discovered agents/MCP servers and their dependencies.
compliance — Report compliance posture from persisted tenant evidence or a labelled local scan, with optional per-framework controls and paged driving finding IDs.
remediate — Produce a remediation plan: package upgrade commands by ecosystem, credential scope-reduction guidance, and unfixable vulnerabilities.
exposure_paths — Return the ranked attack-path queue (evidence tier, KEV, severity, composite risk, credentials) with filters by tenant, scan, node, finding, credential, source type, and severity, in summary or full detail.
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.
Open security scanner and self-hosted control plane for AI, MCP, and cloud infrastructure. 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 by blast radius and reachability evidence. Local scans need no account.
From the repository you want to inspect, with uv installed:
uvx agent-bom scan .Read the discovered agents and MCP servers, prioritize the highest-severity findings, and follow the affected package's fix guidance. Review coverage gaps beside the verdict: incomplete evidence is not a clean assessment. What this scan does and does not establish.
Apply a reviewed fix, update the lockfile, then rerun uvx agent-bom scan .
against the same repository to verify the finding changed.
Save a report with uvx agent-bom scan . -f sarif -o findings.sarif, then
upload it and gate CI.
Run uvx agent-bom doctor if setup fails. See the first-run guide
for pip installation, or ask your coding agent with the checkup skill.
In GitHub Actions, the same scan uploads SARIF to code scanning and fails on high or critical findings, the same default gate as the CLI:
permissions:
contents: read
security-events: write
steps:
- uses: actions/checkout@v4
- uses: koda-ai-studio/agent-bom@v0
with:
upload-sarif: 'true'No project handy? Run uvx 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
Area | What you get |
Dependencies | Lockfiles and manifests across Python, JavaScript, Go, Java, .NET, Rust and more, matched against OSV, GitHub advisories and NVD with KEV and EPSS. Ask "am I affected by CVE-X" across every stored scan. |
Code | Findings from Semgrep or any SARIF tool, plus native analysis of AI code (prompt-injection sinks, guardrails, tool exposure) and whether your code reaches the vulnerable function. |
Containers and IaC | Images scanned in bounded memory and time; Dockerfile, Terraform, Kubernetes, Helm and compose risks with exact lines in SARIF. |
AI agents and MCP | Agents, MCP servers, tools and credentials from local configs and agent frameworks, linked to what they can reach. |
Cloud | Read-only collection from AWS, Azure, GCP, Databricks, Snowflake and more, with CIS and best-practice checks in the same graph. |
Runtime | An MCP proxy and gateway that alert on poisoned tools and injected results, or block them with |
Discovery and scanning read from these sources today; the last row lists where evidence can be sent. The list is generated from a code-backed manifest (docs/images/integrations-manifest.json); a test fails if it names anything without an implementation.
Area | Integrations |
AI clients + IDEs | Claude, Codex, Cursor, GitHub Copilot, Windsurf, Cortex Code, Gemini CLI, JetBrains AI, Junie, Amazon Q, Cline, Roo Code, Continue, Zed, Goose, Snowflake CLI, Docker MCP Toolkit, Tabnine, Sourcegraph Cody, Aider, Void, Aide, Trae, Pieces, OpenClaw, mcp-cli |
AI platforms + model hubs | OpenAI, Hugging Face, Ollama, MLflow, W&B, Langfuse, LangSmith |
GPU + neo clouds | CoreWeave, Nebius, Lambda, RunPod, Vast.ai, Crusoe, GPU containers + K8s GPU nodes |
Hyperscalers + Kubernetes | AWS, Azure, GCP, Kubernetes |
Data + vector stores | Snowflake, Databricks, Supabase, Pinecone, Qdrant, Weaviate, Chroma, Milvus |
Identity + SaaS + dev | Okta, GitHub Actions, Vercel, Microsoft Entra ID, Jira, ServiceNow, Slack, Jamf |
Evidence out | ClickHouse, BigQuery, S3, GCS, Azure Blob, Jira tickets, Slack alerts, Vanta, Drata, OCSF syslog |
Product names and logos are trademarks of their owners, used only to identify supported evidence sources. Their use does not imply endorsement or partnership.
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. Open the full-size environment graph.
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. Open the full-size relationship graph.
Explore context, correlation and reachability · Run the reference lab · Reproduce these screenshots
Explain a finding to your team: create an impact brief with affected assets, source receipts, evidence gaps and the next action to review.
Am I affected by a new CVE? Respond to a new CVE: match it against stored scans, including CVEs only NVD has published, and get affected assets with their patch target, possibly affected distro packages to verify, and the blast radius.
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:
Try the demo in your browser: a read-only copy of the UI on labelled sample data, with no install and no backend. Scans, settings and sign-in are turned off there. To open the same graph locally:
pip install 'agent-bom[ui]==0.111.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.111.0 https://github.com/koda-ai-studio/agent-bom.git && cd agent-bom
AGENT_BOM_IMAGE_TAG=0.111.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 other MCP clients, run agent-bom mcp server.
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.
Check a dependency before installing it 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
Ask your coding agent instead of reading a report. In Claude Code:
/plugin marketplace add koda-ai-studio/agent-bom
/plugin install agent-bom@agent-bomIn Codex, run codex plugin marketplace add koda-ai-studio/agent-bom, then
install agent-bom-local from the Plugins Directory. Both plugins run the
pinned agent-bom release locally and send nothing to an agent-bom service.
Ask | Skill |
"Is this project safe to ship?" |
|
"Am I affected by CVE-2025-29927?" |
|
"What have my agents been doing?" |
|
"Are my agent settings too permissive?" |
|
"Give me an AI-BOM" |
|
Add /plugin install agent-bom-guard@agent-bom to block malicious and
typosquatted package installs before Claude runs them.
All skills and their permissions ·
Guard details
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.
Persisted runtime, proxy and gateway activity retains source receipts and bounded time windows in the graph. Exact inventory references can bind records; unresolved identities and collection gaps remain explicit. Recorded activity does not prove execution or grant access. See the runtime evidence boundaries.
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
New here? The first PR in 30 minutes guide and a ready Codespace get you from zero to a passing test without local setup. Start with a good first issue or the contributor roadmap, and ask in #contributors on Discord.
agent-bom wants more maintainers: GOVERNANCE.md lays out the path from contributor to triager, reviewer and maintainer, and MAINTAINERS.md lists who reviews what. If agent-bom gave you useful evidence, a star or a short note in feedback helps other security teams find and trust it.
Contributing · Capabilities and roadmap · Support · Report an inaccurate finding · Apache-2.0
Source version: v0.111.0 · Latest release: v0.111.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, evidence confidence,
composite risk, credential count); every path carries ``rank``, ``evidenceTier``,
``isKev``, ``severity``, ``evidenceConfidence`` and ``rankingFactors``. 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 declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real value by disclosing deterministic dashboard ordering, the exact ranking criteria (evidence tier, KEV, severity, confidence, composite risk, credential count) and the per-path fields emitted. It does not cover cost/latency or the significance of the 0-100 composite risk scale beyond what the schema states.
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 statement, then ranking, then the API-equivalence. The enumerated field list (rank, evidenceTier, isKev, severity, evidenceConfidence, rankingFactors) is partly redundant given an output schema exists, but it is compact and reinforces the ordering story.
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 14-parameter read-only listing tool with a full output schema and rich annotations, the description supplies the one thing structured fields cannot: what the ordering means and why paths sit where they do. Nothing essential for correct invocation 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 description coverage is 100% across all 14 parameters, so the schema carries parameter meaning fully. The description adds only the framing that filters behave like the /v1/graph/attack-paths endpoint; it offers no extra semantics on view modes, severity thresholds, or combining filters.
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?
Specific verb+resource: returns the ranked attack-path queue in dashboard order, and the second sentence explains the ranking semantics. It is clear what the tool produces, but it never names or distinguishes itself from siblings (scan, check, compliance, policy_check), so an agent must infer that this is the graph-based exposure view rather than a scan/compliance run.
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 implied by the content — 'attack-path queue', 'totals, filters and cursor pages match /v1/graph/attack-paths' — but there is no explicit statement of when to choose this over scan, check, or policy_check. The cursor instruction ('keep filters unchanged' semantics) is the only operational guidance, and even that lives in the schema.
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:
• project_path — a local project / repo directory ("scan this repo";
must be inside home or AGENT_BOM_MCP_WORKSPACE_ROOTS)
• repo_url — a public git repo URL (cloned + scanned, no checkout)
• config_path — a local 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. Same sandbox as project_path. Mutually exclusive with project_path and 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. | |
| project_path | No | Local project / repository directory to scan, e.g. the agent's current workspace checkout. Scans dependency manifests and lockfiles, project MCP configs, source AI usage, secrets (values redacted), IaC, and GitHub Actions, statically and read-only. Must resolve (symlinks followed) to an existing directory inside the user's home or a root listed in AGENT_BOM_MCP_WORKSPACE_ROOTS; traversal, symlink escapes, files, and missing paths are refused with AGENTBOM_MCP_VALIDATION_INVALID_PATH. Mutually exclusive with config_path and repo_url. | |
| 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?
Despite annotations already declaring readOnly/idempotent/non-destructive, the description adds real behavioral context: static parsing with no code execution for repos and images, online OSV/registry lookups unless offline mode is requested or operator-configured, and the fact that an incomplete scan still returns JSON in an error result. It also notes secret values are redacted on output.
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 action, then a bulleted target menu, then mechanics, then returns — a good structure for a 24-parameter tool. The Returns block partially restates the `detail`/`section` schema descriptions, which is mild redundancy but useful orientation before an agent opens the schema.
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 very high-complexity tool the description covers the selection decision, execution model, network/offline behavior, error semantics, and the summary-vs-paged result workflow. With an output schema present and full parameter descriptions, nothing an agent needs in order to call it correctly 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 baseline is 3; the description earns extra by organizing the target parameters into a mutually-exclusive selection menu, spelling out the project_path sandbox rule (home or AGENT_BOM_MCP_WORKSPACE_ROOTS) and the ecosystem inference default. Dozens of secondary parameters (enrich, scorecard, verify_integrity, output_format) are only covered by 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?
Opens with a specific verb and resource ('Run a full AI supply chain security scan and return an AI-BOM') and enumerates the six target types it accepts, so an agent knows exactly what it does. It never contrasts itself with nearby siblings such as generate_sbom, check, or exposure_paths, so the boundary with those tools is left implicit.
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 invocation context: pick one target (with examples of the phrasing a user would use), and if none is given it falls back to ambient MCP-client discovery. It also explains the result_id paging path. It stops short of stating when to prefer a sibling tool over this one, which is the only missing piece.
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.14scan2 fields changedInput schema / properties / config_path / descriptionPrevious 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."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. Same sandbox as project_path. Mutually exclusive with project_path and repo_url."Input schema / properties / project_pathAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Local project / repository directory to scan, e.g. the agent's current workspace checkout. Scans dependency manifests and lockfiles, project MCP configs, source AI usage, secrets (values redacted), IaC, and GitHub Actions, statically and read-only. Must resolve (symlinks followed) to an existing directory inside the user's home or a root listed in AGENT_BOM_MCP_WORKSPACE_ROOTS; traversal, symlink escapes, files, and missing paths are refused with AGENTBOM_MCP_VALIDATION_INVALID_PATH. Mutually exclusive with config_path and repo_url.",
+ "title": "Project Path"
+}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 target distinct operations: scan (full audit), check (single package CVE), generate_sbom (SBOM export), policy_check, remediate, compliance, intel_lookup, exposure_paths. However, scan and generate_sbom both 'discover agents and extract dependencies', and policy_check/remediate internally run scans, creating mild overlap in scope. Descriptions do help distinguish them, keeping ambiguity low.
Mix of verb_noun (generate_sbom, intel_lookup, policy_check, exposure_paths) and bare nouns/verbs (scan, check, compliance, remediate). Consistent snake_case style throughout keeps it readable, but the verb-vs-noun convention is not uniform.
Eight tools is well within the ideal 3-15 range for a security scanning server. Each tool covers a distinct stage of the security workflow (scan, check, SBOM, policy, remediation, compliance, intel, attack paths), so each earns its place.
The surface covers the full security lifecycle: scanning, SBOM generation, CVE lookup, policy gating, remediation, compliance, and attack-path analysis. Minor gaps exist—no tools for managing/saving policies, comparing baseline scans, or suppressing/waiving findings—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.