agent-bom escanea repositorios y cadenas de suministro de software en SCA, secretos,
IaC y contenedores; inventaría agentes de IA, MCP, modelos y conjuntos de datos; y conecta
fuentes de nube, identidad, Snowflake y datos de solo lectura. Normaliza esa evidencia
en un modelo de Hallazgo + UnifiedGraph, correlaciona el riesgo alcanzable y luego lleva
el trabajo a través del propietario, la corrección, la verificación, la evidencia de cumplimiento o la política de ejecución.
punto de entrada de agente o herramienta → servidor MCP → paquete → hallazgo → impacto → propietario → corrección → verificar
Ejecuta ad hoc localmente o en CI, o usa tu plano de control autoalojado para escaneos programados o conectados, historial, asignaciones y aplicación en tiempo de ejecución. El código fuente y las credenciales sin procesar permanecen dentro del límite de ejecución controlado por el cliente; las relaciones recopiladas, inferidas, estáticas y de tiempo de ejecución permanecen distintas; la evidencia incompleta permanece explícita.
Inicio rápido · Flujo de evidencia · Matriz de capacidades de integración · Prueba del comparador medido · Arquitectura del plano de control
Related MCP server: agent-audit
Rol | Comienza aquí | Resultado principal |
AppSec / seguridad de producto |
| Escanea dependencias, secretos, IaC e imágenes del repositorio; controla CI con hallazgos alcanzables |
Ingeniero de IA / ML |
| Inventaría agentes, clientes y servidores MCP, habilidades, modelos y conjuntos de datos antes de que se publiquen |
Seguridad en la nube |
| Conecta una fuente de nube o Snowflake de solo lectura, luego evalúa inventario, postura y evidencia de identidad |
Plataforma / DevOps |
| Centraliza evidencia, asigna propietario y SLA, remedia y verifica |
GRC / auditoría |
| Revisa mapeos de control y exporta evidencia con brechas explícitas |
Liderazgo / CISO |
| Revisa postura, cobertura, riesgo material y cambios a lo largo del tiempo |
La ingeniería de seguridad y el GRC siguen siendo flujos de trabajo separados: los hallazgos y la alcanzabilidad no se presentan como certificación de auditoría. Consulta límites del producto.
Las capturas a continuación usan un entorno de muestra etiquetado visiblemente; los escaneos en vivo usan los mismos contratos de Hallazgo + UnifiedGraph. Selecciona cualquier imagen para la prueba a tamaño completo.
Continúa con la aplicación en tiempo de ejecución en la galería completa del producto · Protocolo de captura
Empieza aquí. Esta es la puerta de entrada: dos comandos, sin cuenta, sin configuración. La muestra sin conexión se completa sin descargar una base de datos de avisos y muestra la forma de salida del inventario, los hallazgos y el radio de explosión.
pip install agent-bom
agent-bom scan --demo --offlineLa muestra contiene intencionalmente un paquete conocido como malicioso, por lo que el estado de salida 1 es esperado
y el informe impreso está completo. Escanea un repositorio a continuación:
agent-bom scan .El escaneo del repositorio muestra inventario, hallazgos e impacto alcanzable.
agent-bom scan . y agent-bom scan -p . son el mismo comando; PATH es un
alias de --project.
¿Necesitas un escaneo sin conexión? Primero siembra la base de datos de avisos de paquetes más pequeña:
agent-bom db update --osv-ecosystem PyPI
agent-bom scan . --offlineSi esa base de datos falta o no se puede leer, el escaneo escribe un artefacto parcial
cuando se establece -o y sale con 1; por lo tanto, CI no puede confundir la cobertura de avisos no disponible
con un escaneo limpio.
En una base de datos nueva, ese comando cubre solo el ecosistema seleccionado; los paquetes
de otros ecosistemas permanecen como brechas de cobertura sin conexión explícitas. Repite
--osv-ecosystem para un repositorio políglota, o usa
agent-bom db update --source osv para el archivo de todos los ecosistemas de OSV. El archivo
completo puede superar 1 GB, puede tardar varios minutos y muestra progreso en vivo con
el total exacto cuando el servidor lo proporciona. Ejecuta el más amplio
agent-bom db update cuando también necesites fuentes de distribución, probabilidad de explotación y
vulnerabilidades conocidas explotadas.
Una salida distinta de cero es un veredicto, no un fallo. scan sale con 0 cuando nada
coincide con una puerta, y con 1 cuando algo coincide: un umbral --fail-on-* que estableciste, un
paquete conocido como malicioso o un escaneo que no se completó. El informe se imprime
completo de cualquier manera, y la última línea nombra la puerta que coincidió. Contrato completo de
códigos de salida.
Guarda un artefacto con agent-bom scan . -f sarif -o findings.sarif, o sigue
la guía de primera ejecución para formatos y uso en CI.
Prueba el escáner sin instalarlo, luego verifica un paquete antes de agregarlo:
uvx agent-bom scan .
uvx agent-bom check requests@2.33.0 --ecosystem pypicheck devuelve un veredicto previo a la instalación de permitir/no seguro/incompleto; scan cubre el
repositorio más la configuración de IA/MCP descubierta. Para hacer que tanto las puertas de dependencias como las de secretos
sean automáticas para un equipo, fija los hooks de consumidor incluidos:
repos:
- repo: https://github.com/msaad00/agent-bom
rev: v0.102.0
hooks:
- id: agent-bom-secrets
- id: agent-bom-scanEjecuta pre-commit install una vez. Los hooks instalan agent-bom en su propio
entorno aislado, por lo que los contribuyentes no necesitan una instalación global separada.
Comportamiento de hooks y ejemplos de CI.
Quieres | Ve a |
Escanear tu repositorio |
|
Un panel en tu portátil | |
Un despliegue compartido (Docker, Helm, EKS, Snowflake) | Autoalojamiento tabla |
Controlar una solicitud de extracción | |
Darle herramientas a un agente de IA |
|
Conectar una cuenta de nube |
|
Usa la muestra curada y explícitamente sintética cuando solo quieras inspeccionar la forma de salida:
agent-bom scan --demo --offlineLa muestra contiene intencionalmente un paquete conocido como malicioso, que falla de forma cerrada.
Inicia el plano de control de bucle local:
pip install 'agent-bom[ui]'
agent-bom servePara un despliegue compartido, usa la ruta documentada de Docker o Helm y configura identidad real, TLS, PostgreSQL, cifrado y claves de auditoría antes de exponerlo.
Destino | Empieza aquí |
Docker Compose | Compose de plataforma — PostgreSQL, secretos divididos, trabajo de migración |
Docker Compose (evaluación) | Compose piloto — solo loopback, SQLite, sin autenticación |
Helm / Kubernetes |
|
EKS | |
Snowflake SPCS / Native App |
|
Air-gapped |
Los ejemplos apuntan a esta versión candidata; confirma la disponibilidad de la versión antes de copiar un pin exacto. De lo contrario, usa la última versión que se muestra en PyPI.
Resumen de implementación · Configuración empresarial · Conexiones en la nube
Necesidad | Primera acción | Artefacto o siguiente paso |
GitHub CI |
| SARIF, resumen de PR y un código de salida de política |
Evidencia en la nube |
| Referencia de conexión almacenada; ejecuta escaneos desde el plano de control |
Puerta de enlace en tiempo de ejecución |
| Eventos de auditoría de permitir, advertir y bloquear |
Interfaz de agente |
| 84 herramientas MCP, 6 recursos y 8 indicaciones de flujo de trabajo |
Distribución de agente | Metadatos de instalación específicos del registro |
El modo servidor MCP expone 84 herramientas MCP, 6 recursos y 8 indicaciones de flujo de trabajo, todo de solo lectura: el descubrimiento y el análisis nunca modifican un objetivo escaneado.
Configura YDC_API_KEY para habilitar la herramienta MCP opcional youcom_search para contexto web y de noticias en vivo junto con la base de datos local de inteligencia de amenazas. Es la única herramienta que envía tu consulta a un tercero, está desactivada a menos que se configure la clave, y la solicitud está fijada al origen de You.com mediante TLS, por lo que la clave no puede redirigirse a otro host mediante configuración.
La CLI, Docker, la API, el chart de Helm, el servidor MCP, la puerta de enlace y el SDK son superficies de distribución del mismo producto. La vía de Snowflake SPCS / Native App se ejecuta dentro de la cuenta de Snowflake del cliente; es un objetivo de implementación propiedad del cliente, no un servicio alojado por agent-bom. Snowflake y Snowpark también siguen siendo integraciones de conector y tiempo de ejecución para los otros perfiles de implementación.
Superficie | Obtenerlo |
Paquete de Python |
|
Contenedor |
|
Kubernetes |
|
GitHub Action | |
Servidor MCP |
|
Registros MCP | |
SDKs | Python · TypeScript · Go |
Descubrimiento de solo lectura por defecto; las decisiones de escritura en tiempo de ejecución son separadas y explícitas.
Las credenciales son de solo escritura donde se almacenan, están cifradas en reposo y nunca se devuelven en las respuestas de la API.
Las rutas de la API y del plano de control están limitadas por inquilino y protegidas por autenticación fuera del modo local explícito.
La evidencia faltante se muestra como no disponible o parcial, nunca se convierte en un cero factual.
Los ejemplos públicos y las capturas de pantalla usan solo identificadores sintéticos deterministas.
Modelo de amenazas · Verificación de versiones · Política de seguridad · Modelo de seguridad MCP
¿Atascado o no sabes dónde corresponde una pregunta? SUPPORT.md tiene el enrutamiento y una declaración honesta de qué respuesta esperar.
Para contribuir, empieza con CONTRIBUTING.md, AGENTS.md y los problemas abiertos.
Con licencia Apache-2.0.
Check a specific package for known CVEs before installing.
Queries OSV.dev for vulnerabilities in the given package. Use this
before installing an MCP server or dependency to verify it is safe.
Args:
package: Package name with optional version, e.g. "express@4.18.2",
"@modelcontextprotocol/server-filesystem@2025.1.14",
or just "requests" (resolves @latest).
ecosystem: Package ecosystem — "npm", "pypi", "go", "cargo",
"maven", "nuget", "rubygems", "composer", "swift",
"pub", "hex", "conda", "deb", "apk", or "rpm".
Defaults to "npm".
Returns:
JSON with package, version, ecosystem, vulnerability count,
and vulnerability details (id, severity, cvss, fix version, summary).
| Name | Required | Description | Default |
|---|---|---|---|
| offline | No | Use only the local advisory database. An explicit version is required; registry resolution and publication checks are disabled. | |
| package | Yes | Package name with optional version, e.g. 'express@4.18.2', '@modelcontextprotocol/server-filesystem@2025.1.14', or 'requests' (resolves @latest). | |
| version | No | Optional package version when omitted from ``package`` (e.g. package='flask', version='0.12.2'). Prefer embedding in ``package`` as 'flask@0.12.2' or 'flask==0.12.2' when possible. | |
| ecosystem | No | Package ecosystem: 'npm', 'pypi', 'go', 'cargo', 'maven', 'nuget', 'rubygems', 'composer', 'swift', 'pub', 'hex', 'conda', 'deb', 'apk', or 'rpm'. | npm |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is covered structurally. The description adds genuine value by disclosing the external dependency on OSV.dev (an outbound network query) and documenting the JSON return shape. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The key purpose is front-loaded in the first line, followed by a tight context sentence and structured Args/Returns blocks. It earns its length with the OSV.dev source note, usage guidance, and return-format disclosure, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich annotations, an output schema, and 100% parameter coverage, the description covers what matters beyond structure: external data source, when to invoke, and expected return fields. The only minor gap is that the offline/version parameters are not surfaced in the description text, though the schema fully documents them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented structurally and the baseline is 3. The description reinforces package/ecosystem with concrete examples but omits the offline and version parameters entirely from its Args section. It adds convenience, not new meaning, on top of the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise 'Check a specific package for known CVEs before installing' — a specific verb, resource, and scoping constraint. It clearly separates this single-package advisory check from broad siblings like scan or registry_lookup by framing it as a targeted, pre-installation safety verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this before installing an MCP server or dependency to verify it is safe' gives an explicit trigger condition and intended moment of use. However, it does not name any alternative tools or state when NOT to use it, leaving an agent to infer the boundary against scan/policy_check/marketplace_check on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OWASP LLM Top 10 / OWASP MCP Top 10 / MITRE ATLAS / NIST AI RMF compliance posture.
Scans local MCP configurations, maps findings to 47 security controls
across four AI security frameworks, and returns per-control
pass/warning/fail status with an overall compliance score.
Args:
config_path: Path to a specific MCP config directory.
If not provided, auto-discovers all local agent configs.
image: Docker image reference to scan (e.g. "nginx:1.25").
Returns:
JSON with overall_score (0-100), overall_status (pass/warning/fail/no_data),
and per-control details for OWASP LLM Top 10 (10 controls),
OWASP MCP Top 10 (10 controls), MITRE ATLAS (13 techniques),
and NIST AI RMF (14 subcategories). Plus a nist_800_53_catalog line:
the vendor-asserted, catalog-backed NIST SP 800-53 Rev 5 score over
evaluated controls only (with ISO-27001-by-id attribution), scored
independently and NOT folded into overall_score.
| Name | Required | Description | Default |
|---|---|---|---|
| image | No | Docker image to scan, e.g. 'nginx:1.25'. | |
| config_path | No | Path to MCP client config directory. Auto-discovers all if omitted. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable context about scan behavior, return structure, and the notable fact that the nist_800_53_catalog score is independently scored and NOT folded into overall_score. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args and Returns sections, front-loaded with purpose. It is somewhat verbose, especially the Returns details, given that a full output schema exists. However, the special NIST 800-53 scoring nuance justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with two optional parameters and an output schema, the description fully explains scope, control mapping, return structure, and the separate NIST score. It leaves no critical gaps for an agent to understand what the tool does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The paragraph text essentially restates schema descriptions (config_path auto-discovers, image is a Docker reference) without adding new semantics or edge-case guidance. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Get OWASP LLM Top 10 / OWASP MCP Top 10 / MITRE ATLAS / NIST AI RMF compliance posture.' It clearly states what it does (scans MCP configurations, maps to 47 controls) and distinguishes itself from sibling tools like scan or cis_benchmark by naming unique frameworks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: scans local MCP configs with optional config_path or image, auto-discovers if omitted. However, it does not explicitly mention when to prefer this tool over alternatives or provide exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return ranked ExposurePath JSON for headless security agents.
This is the agent-native graph surface: Claude, Cursor, Codex,
Windsurf, Cortex, and other MCP clients can request the same
investigation objects used by the dashboard without scraping UI state.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of ranked exposure paths to return. | |
| cursor | No | Continue with pagination.next_cursor; keep the risk filter unchanged. | |
| scan_id | No | Optional graph scan ID. Omit to use the latest snapshot. | |
| min_risk | No | Minimum path risk score to include. | |
| tenant_id | No | Tenant ID for the graph snapshot. Defaults to 'default'. | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior, so the description doesn't need to repeat that. It adds minimal extra context: it returns JSON and is agent-native. There is no mention of error conditions, rate limits, or specific response format nuances, but the annotations cover the safety profile. The description doesn't contradict annotations and adds slight value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core action ('Return ranked ExposurePath JSON') in the first sentence, followed by a brief context sentence about its purpose. No wasted words; it's well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a rich output schema and all parameters have descriptions, the description doesn't need to explain return values or parameter syntax. It adequately conveys the tool's purpose and intended use case. The only minor gap is that it doesn't explicitly mention the ranking logic or graph snapshot behavior, but those are covered by 'min_risk' and 'scan_id' descriptions in the schema. Overall, it's sufficiently complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema descriptions cover 100% of parameters, so the schema itself fully documents each parameter's purpose. The description adds no additional parameter-specific meaning beyond what's already in the schema. With high schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return ranked ExposurePath JSON for headless security agents.' It specifies a concrete verb, resource, and audience. It also mentions it's the 'agent-native graph surface' and distinguishes it from UI scraping, which differentiates it from sibling tools that might simulate UI interactions or other analysis functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for agents to obtain investigation objects without scraping UI state, implying it's the preferred method for programmatic access. However, it does not explicitly exclude alternatives or name sibling tools like 'scan' or 'intel_lookup' for comparison. Still, the context is strong enough to guide an agent on when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Software Bill of Materials (SBOM) for your AI agent setup.
Discovers AI agents and MCP servers, extracts all package dependencies,
and generates a standards-compliant SBOM.
Args:
format: SBOM format — "cyclonedx" (CycloneDX 1.7) or "spdx" (SPDX 3.0).
config_path: Path to a specific MCP config directory.
If not provided, auto-discovers all local agent configs.
Returns:
JSON string containing the SBOM in the requested format.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | SBOM format: 'cyclonedx' (CycloneDX 1.7) or 'spdx' (SPDX 3.0). | cyclonedx |
| config_path | No | Path to MCP client config directory. Auto-discovers all if omitted. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that the tool discovers agents and servers, extracts dependencies, and generates a standards-compliant SBOM, which is consistent with read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and uses a clear structure with bullet points for arguments and return. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (mentioned in signals) and two optional parameters, the description provides complete context: what the tool does, how parameters work, and the return format. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description adds value by specifying the exact format values ('cyclonedx' and 'spdx') and clarifying config_path auto-discovery behavior, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a Software Bill of Materials (SBOM) for AI agent setups, with specific details on discovering agents, MCP servers, and extracting dependencies. It distinguishes itself from sibling tools like 'scan' or 'inventory' by focusing on SBOM generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (to generate an SBOM) and explains config_path auto-discovery. However, it does not mention when not to use it or compare to alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one advisory from the local threat-intel database.
| Name | Required | Description | Default |
|---|---|---|---|
| advisory_id | Yes | CVE, GHSA, or OSV advisory ID, e.g. CVE-2024-1234 or GHSA-abcd-1234-wxyz. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds 'local threat-intel database' context, indicating no external fetch. No contradiction. However, it doesn't detail behavior on missing IDs or performance considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence that is front-loaded and free of redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simplicity (1 param, output schema exists, annotations rich), the description is nearly complete. Minor gap: no mention of error handling or edge cases like invalid IDs, but output schema likely covers return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema's parameter description already provides detailed format guidance (e.g., 'CVE-2024-1234 or GHSA-abcd-1234-wxyz'). The tool description adds no new parameter-level information beyond 'one advisory,' so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Look up one advisory from the local threat-intel database.' It specifies a specific verb (look up) and resource (advisory from a local database), distinguishing it from siblings like intel_match which likely handle multiple matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific advisory ID is known, but lacks explicit guidance on when to use this tool versus alternatives like intel_match or intel_sources. No mention of when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a security policy against current scan results.
Runs a scan, then evaluates the provided policy rules against the
findings. Policies can gate on severity thresholds, CISA KEV status,
AI risk flags, credential exposure, and denied packages.
Args:
policy_json: JSON string containing policy rules. Example:
{"rules": [{"id": "no-critical", "severity_gte": "critical",
"action": "fail"}, {"id": "no-kev", "kev": true, "action": "fail"}]}
Returns:
JSON with passed (bool), violations list, failure_count, and
warning_count.
| Name | Required | Description | Default |
|---|---|---|---|
| policy_json | Yes | JSON string containing policy rules, e.g. {"rules": [{"id": "no-critical", "severity_gte": "critical", "action": "fail"}]}. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive, and idempotent behavior. The description adds that it runs a scan and evaluates rules, and specifies the return structure (passed, violations, etc.), which is beyond annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with summary, details, and return info, but is slightly verbose. Could be more concise while retaining key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and existence of output schema, the description covers the essential behavior and expected output. However, it lacks details on error handling or edge cases (e.g., invalid policy_json).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by providing an illustrative example of the policy_json format and listing supported rule types (severity, KEV, etc.), enhancing understanding beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it evaluates a security policy against current scan results, with a specific verb and resource. It distinguishes from sibling tools like 'compliance' or 'code_scan' by focusing on custom policy rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's purpose but lacks explicit guidance on when to use it versus alternatives like 'check' or 'should_i_deploy'. It provides context on policy components but no when-not statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a remediation plan for vulnerabilities in your AI agent setup.
Scans for vulnerabilities, then generates actionable fix commands for
each affected package (npm install, pip install), credential scope
reduction guidance, and reports on unfixable vulnerabilities.
Args:
config_path: Path to a specific MCP config directory.
If not provided, auto-discovers all local agent configs.
image: Docker image reference to scan (e.g. "nginx:1.25").
Returns:
JSON with package_fixes (upgrade commands by ecosystem),
credential_fixes (scope reduction steps), and unfixable items.
| Name | Required | Description | Default |
|---|---|---|---|
| image | No | Docker image to scan, e.g. 'nginx:1.25'. | |
| config_path | No | Path to MCP client config directory. Auto-discovers all if omitted. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavior: scanning for vulnerabilities, generating fix commands (npm install, pip install), credential scope reduction guidance, and reporting unfixable items. Annotations (readOnlyHint=true) align with generating instructions without executing them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, scanning, arguments, returns). It is slightly lengthy but each sentence provides relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers all necessary aspects: scanning, fix generation, optional parameters, and return structure. Together with the input and output schema, the description is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds minimal value beyond the schema. It clarifies behavior for config_path (auto-discovers if omitted) and image, but this is largely repetitive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating remediation plans for vulnerabilities in AI agent setups. It specifies scanning for vulnerabilities and producing fix commands, distinguishing it from sibling tools that focus on scanning alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (after vulnerabilities are found) and describes the optional parameters (config_path, image). However, it does not explicitly mention when not to use or compare to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a full AI supply chain security scan and return an AI-BOM.
Point it at a target with one of:
• repo_url — a public git repo URL (cloned + scanned, no checkout)
• config_path — a local project / MCP-config directory
• image — a Docker image
• sbom_path — an existing CycloneDX/SPDX SBOM
• package — a single package or MCP launch command (pair it with
``ecosystem`` when the spec names no launcher)
With none of these, it auto-discovers local MCP clients (Claude Desktop,
Cursor, Windsurf, VS Code Copilot, OpenClaw, etc.).
It extracts package dependencies, looks up CVEs (online via OSV.dev and
advisory sources unless offline mode is requested or configured),
assesses config security (credential exposure, tool access), computes
blast radius, and returns structured results. Scanning is fully static
and read-only — repository and image contents are parsed, never executed.
Returns:
JSON. By default a bounded summary: counts (packages, agents,
findings by severity/category), top findings, affected paths, and a
result_id. Page any full-fidelity section with
scan(result_id=..., section='findings', offset=0, limit=25).
An incomplete scan (e.g. vulnerability source unavailable) is
returned as an error result whose body is still JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| image | No | Docker image to scan (e.g. 'nginx:1.25', 'ghcr.io/org/app:v1'). | |
| limit | No | Maximum items per page of `section` (1-200). | |
| detail | No | JSON output only. 'summary' (default): counts, top findings, affected paths, and a result_id for paged follow-ups. 'full': the whole AI-BOM document, shortened structurally (still valid JSON, with _truncation metadata) if it exceeds the response budget. | summary |
| enrich | No | Enable NVD CVSS, EPSS probability, and CISA KEV enrichment. | |
| offset | No | Zero-based item offset into `section`. | |
| policy | No | Policy object to evaluate alongside scan results, e.g. {"rules": [{"id": "no-critical", "severity_gte": "critical", "action": "fail"}]}. | |
| offline | No | true: use the local vulnerability DB only and skip registry, OSV, GHSA, and NVIDIA network lookups (requires a populated DB from `agent-bom db update`). false: query those sources online. Omitted: online unless the server operator set AGENT_BOM_OFFLINE or AGENT_BOM_VULN_DB_OFFLINE. | |
| package | No | Direct package or MCP launch command to scan, e.g. 'npx @modelcontextprotocol/server-filesystem@2025.1.14' or '@modelcontextprotocol/server-filesystem'. A bare 'name@version' spec is assumed to be npm — pass ``ecosystem`` for anything else. | |
| section | No | Section of a stored result to page, e.g. 'findings', 'blast_radius', 'packages', 'exposure_paths'. | |
| repo_url | No | Public git repository URL to clone and scan, e.g. 'https://github.com/org/repo'. Maps the repo's dependencies, project structure, secrets, IaC, and AI/MCP usage into an AI-BOM. Static and read-only: the repository is shallow-cloned into a temporary directory, scanned without ever executing its code, then deleted. The fastest way to point this tool at a target — no local checkout required. | |
| ecosystem | No | Ecosystem of ``package`` when the spec does not name a launcher: 'npm', 'pypi', 'go', 'cargo', 'maven', 'nuget', 'rubygems', 'composer', 'swift', 'pub', 'hex', 'conda', 'deb', 'apk', or 'rpm'. Omitted, the ecosystem is inferred from the spec (PEP 440 specifiers such as 'flask==0.12.2' are PyPI) and any assumption is reported in the result warnings. | |
| result_id | No | result_id from a previous scan response. With it, no new scan runs: returns that result's summary, or one page of `section`. | |
| sbom_path | No | Path to existing CycloneDX or SPDX JSON SBOM file to ingest. | |
| scorecard | No | Enrich packages with OpenSSF Scorecard scores (requires resolvable GitHub repos). | |
| db_sources | No | Comma-separated DB sources to sync before scanning (e.g. 'nvd,ghsa,osv,epss,kev'). | |
| transitive | No | Resolve transitive dependencies for npx/uvx packages. | |
| config_path | No | Local directory to scan — a project root or an MCP client config directory. Auto-discovers installed MCP clients if omitted unless no_discover=true. Mutually exclusive with repo_url. | |
| no_discover | No | Disable ambient host MCP-client discovery. Explicit repo/config, image, SBOM, and package targets are still scanned; use this for deterministic CI. | |
| fail_severity | No | Return failure status if vulns at this severity or higher: critical, high, medium, low. | |
| output_format | No | Output format: 'json' (default), 'sarif', 'cyclonedx', 'spdx', 'junit', 'csv', or 'markdown'. | json |
| warn_severity | No | Return warning status (gate_status=warn, exit 0) when vulns at this severity or higher exist. Use with fail_severity for two-tier CI gates, e.g. warn_severity='medium', fail_severity='critical'. | |
| auto_update_db | No | Explicitly refresh the local vuln DB when older than the daily freshness target before scanning. | |
| verify_integrity | No | Verify package SHA-256/SRI hashes and SLSA provenance against registries. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing that the scan is fully static — repo/image contents are 'parsed, never executed', shallow-cloned to a temp dir then deleted — whether network lookups happen (OSV/GHSA/NVD unless offline), and that an incomplete scan is returned as an error result whose body is still JSON. These are exactly the operational traits annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then a scannable bullet list of targets, then behavior, then returns. It is somewhat long, but nearly every sentence carries distinct information; only the returns paragraph slightly overlaps with what the output schema already provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a 23-parameter tool with an output schema: it explains target selection, discovery fallback, network/offline posture, mutation-free execution, gating semantics via fail/warn severity, and the summary-vs-paged-full result model. Nothing an agent needs to choose arguments or interpret a response is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics: the mutually exclusive repo_url/config_path relationship, the package+ecosystem pairing, the auto-discovery default when no target is given, and how result_id/section/offset/limit compose into paging. That linkage is meaningfully more than the per-parameter text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Run a full AI supply chain security scan and return an AI-BOM' — and enumerates the five target modes it accepts. It never names a sibling (e.g. generate_sbom or policy_check), so an agent must infer differentiation from the target list alone rather than being routed explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use guidance via the bulleted target list, notes the mutually exclusive relationship with config_path, and explains the no-target auto-discovery fallback. It also documents the paged follow-up pattern (result_id + section). It stops short of exclusions against sibling tools, so it lands at 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.10scan9 fields changedInput schema / properties / detailAdded value: +{
+ "default": "summary",
+ "description": "JSON output only. 'summary' (default): counts, top findings, affected paths, and a result_id for paged follow-ups. 'full': the whole AI-BOM document, shortened structurally (still valid JSON, with _truncation metadata) if it exceeds the response budget.",
+ "enum": [
+ "summary",
+ "full"
+ ],
+ "title": "Detail",
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "default": 25,
+ "description": "Maximum items per page of `section` (1-200).",
+ "maximum": 200,
+ "minimum": 1,
+ "title": "Limit",
+ "type": "integer"
+}Input schema / properties / offline / anyOfAdded value: +[
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / offline / defaultPrevious value: -trueNew value: +nullInput schema / properties / offline / descriptionPrevious value: -"Use the local vulnerability DB only and skip registry, OSV, GHSA, and NVIDIA network lookups."New value: +"true: use the local vulnerability DB only and skip registry, OSV, GHSA, and NVIDIA network lookups (requires a populated DB from `agent-bom db update`). false: query those sources online. Omitted: online unless the server operator set AGENT_BOM_OFFLINE or AGENT_BOM_VULN_DB_OFFLINE."Input schema / properties / offline / typeRemoved value: -"boolean"Input schema / properties / offsetAdded value: +{
+ "default": 0,
+ "description": "Zero-based item offset into `section`.",
+ "minimum": 0,
+ "title": "Offset",
+ "type": "integer"
+}Input schema / properties / result_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "result_id from a previous scan response. With it, no new scan runs: returns that result's summary, or one page of `section`.",
+ "title": "Result Id"
+}Input schema / properties / sectionAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Section of a stored result to page, e.g. 'findings', 'blast_radius', 'packages', 'exposure_paths'.",
+ "title": "Section"
+}exposure_paths1 field changedInput schema / properties / cursorAdded value: +{
+ "anyOf": [
+ {
+ "maxLength": 4096,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Continue with pagination.next_cursor; keep the risk filter unchanged.",
+ "title": "Cursor"
+}v1.0.5access_reviewai_inventory_scanaisvs_benchmarkanalytics_queryanomaly_scanapprove_exceptionaudit_integrityaudit_queryblast_radiusbrowser_extension_scancis_benchmarkcloud_inventorycloud_side_scancode_scancontext_graphcost_allocationcost_forecastcost_reportcreate_ticketcredential_expirydataset_card_scandiffdrift_incidentsfindings_triagefirewall_checkfleet_scangateway_statusgpu_infra_scangraph_correlategraph_correlation_statusgraph_exportidentity_grant_jitidentity_issueidentity_revokeidentity_revoke_jitidentity_rotateingest_external_scanintel_daily_briefintel_matchintel_sourcesinventoryinventory_assetinventory_listinventory_summarykspm_cluster_posturelicense_compliance_scanlist_exceptionsmarketplace_checkmodel_file_scanmodel_provenance_scannhi_discoverprompt_scanproxy_alertsproxy_statusregistry_lookupregistry_sweep_scanrequest_exceptionrisk_campaign_workflowruntime_blueprint_driftruntime_blueprintsruntime_correlateruntime_evidence_ingestruntime_production_indexshield_break_glassshield_startshield_statusshield_unblockshould_i_deployskill_scanskill_trustskill_verifysync_ticket_statustool_risk_assessmenttraining_pipeline_scanvector_db_scanverifywhereyoucom_searchv0.103.2runtime_evidence_ingest3 fields changedInput schema / properties / operator_roleRemoved value: -{
- "default": "viewer",
- "description": "Operator role for this write action. Must be admin.",
- "title": "Operator Role",
- "type": "string"
-}Input schema / properties / operator_scopesRemoved value: -{
- "default": "",
- "description": "Comma-separated operator scopes. Must include findings:write.",
- "title": "Operator Scopes",
- "type": "string"
-}Input schema / properties / reasonRemoved value: -{
- "default": "",
- "description": "Human audit reason for ingesting runtime evidence.",
- "title": "Reason",
- "type": "string"
-}graph_correlategraph_correlation_statusinventory_list1 field changedInput schema / properties / severityAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Filter by the asset's highest directly linked finding severity.",
+ "title": "Severity"
+}runtime_evidence_ingest3 fields changedInput schema / properties / operator_roleAdded value: +{
+ "default": "viewer",
+ "description": "Operator role for this write action. Must be admin.",
+ "title": "Operator Role",
+ "type": "string"
+}Input schema / properties / operator_scopesAdded value: +{
+ "default": "",
+ "description": "Comma-separated operator scopes. Must include findings:write.",
+ "title": "Operator Scopes",
+ "type": "string"
+}Input schema / properties / reasonAdded value: +{
+ "default": "",
+ "description": "Human audit reason for ingesting runtime evidence.",
+ "title": "Reason",
+ "type": "string"
+}tool_risk_assessment3 fields changedInput schema / properties / allow_command_executionAdded value: +{
+ "default": false,
+ "description": "Explicitly allow launching unblocked stdio server commands. False only connects to HTTP/SSE servers.",
+ "title": "Allow Command Execution",
+ "type": "boolean"
+}Input schema / properties / timeout / maximumAdded value: +60Input schema / properties / timeout / minimumAdded value: +0.1v0.102.0approve_exceptioncheck1 field changedInput schema / properties / offlineAdded value: +{
+ "default": false,
+ "description": "Use only the local advisory database. An explicit version is required; registry resolution and publication checks are disabled.",
+ "title": "Offline",
+ "type": "boolean"
+}gateway_status4 fields changedInput schema / properties / activity_cursorAdded value: +{
+ "default": "",
+ "description": "Opaque cursor from a prior gateway_status activity response.",
+ "title": "Activity Cursor",
+ "type": "string"
+}Input schema / properties / activity_limitAdded value: +{
+ "default": 100,
+ "description": "Maximum activity events to return when include_activity is true.",
+ "maximum": 500,
+ "minimum": 1,
+ "title": "Activity Limit",
+ "type": "integer"
+}Input schema / properties / include_activityAdded value: +{
+ "default": false,
+ "description": "Include the durable, cursor-paged gateway activity feed.",
+ "title": "Include Activity",
+ "type": "boolean"
+}Input schema / properties / include_self_postureAdded value: +{
+ "default": false,
+ "description": "Include this deployment's tenant-scoped operator self-posture evidence.",
+ "title": "Include Self Posture",
+ "type": "boolean"
+}list_exceptionsrequest_exceptionscan2 fields changedInput schema / properties / config_path / descriptionPrevious value: -"Local directory to scan — a project root or an MCP client config directory. Auto-discovers all installed MCP clients if omitted. Mutually exclusive with repo_url."New value: +"Local directory to scan — a project root or an MCP client config directory. Auto-discovers installed MCP clients if omitted unless no_discover=true. Mutually exclusive with repo_url."Input schema / properties / no_discoverAdded value: +{
+ "default": false,
+ "description": "Disable ambient host MCP-client discovery. Explicit repo/config, image, SBOM, and package targets are still scanned; use this for deterministic CI.",
+ "title": "No Discover",
+ "type": "boolean"
+}v0.101.0blast_radius2 fields changedInput schema / properties / scan_idAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional persisted scan scope.",
+ "title": "Scan Id"
+}Input schema / properties / tenant_idAdded value: +{
+ "default": "default",
+ "description": "Tenant scope for persisted findings. Defaults to 'default'.",
+ "title": "Tenant Id",
+ "type": "string"
+}cis_benchmark1 field changedInput schema / properties / region / descriptionPrevious value: -"AWS region (only for provider=aws). Defaults to us-east-1."New value: +"Optional AWS region scope. Omit to evaluate CIS across all enabled AWS regions."cloud_side_scanfindings_triagerisk_campaign_workflowyoucom_searchv0.99.0scan2 fields changedInput schema / properties / ecosystemAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Ecosystem of ``package`` when the spec does not name a launcher: 'npm', 'pypi', 'go', 'cargo', 'maven', 'nuget', 'rubygems', 'composer', 'swift', 'pub', 'hex', 'conda', 'deb', 'apk', or 'rpm'. Omitted, the ecosystem is inferred from the spec (PEP 440 specifiers such as 'flask==0.12.2' are PyPI) and any assumption is reported in the result warnings.",
+ "title": "Ecosystem"
+}Input schema / properties / package / descriptionPrevious value: -"Direct package or MCP launch command to scan, e.g. 'npx @modelcontextprotocol/server-filesystem@2025.1.14' or '@modelcontextprotocol/server-filesystem'."New value: +"Direct package or MCP launch command to scan, e.g. 'npx @modelcontextprotocol/server-filesystem@2025.1.14' or '@modelcontextprotocol/server-filesystem'. A bare 'name@version' spec is assumed to be npm — pass ``ecosystem`` for anything else."v0.98.3create_ticketingest_external_scan1 field changedInput schema / properties / scan_json / descriptionPrevious value: -"JSON string from Trivy, Grype, or Syft scan output"New value: +"JSON string containing tool-agnostic SARIF, CycloneDX, SPDX, Trivy, Grype, or Syft evidence"kspm_cluster_postureruntime_evidence_ingestsync_ticket_statusv0.96.2generate_sbom1 field changedInput schema / properties / format / descriptionPrevious value: -"SBOM format: 'cyclonedx' (CycloneDX 1.6) or 'spdx' (SPDX 3.0)."New value: +"SBOM format: 'cyclonedx' (CycloneDX 1.7) or 'spdx' (SPDX 3.0)."inventory_assetinventory_listinventory_summaryScored across 8 tools
scan and generate_sbom both extract dependencies but differ in output (AI-BOM vs SBOM); compliance and policy_check both evaluate security posture but one maps to frameworks and the other enforces custom rules. Most tools have clearly distinct purposes, though some overlap in the underlying scanning could confuse an agent.
Names mix single verbs (scan, check, remediate), nouns (compliance, exposure_paths), and verb_noun compounds (generate_sbom, policy_check, intel_lookup). The inconsistency in verb style and structure reduces predictability, though all are readable.
8 tools is well-scoped for an AI supply chain security server, covering scanning, checking, compliance, SBOM generation, policy, remediation, intel, and exposure paths. No tool feels redundant or unnecessary.
Core lifecycle is covered: scan, check, generate_sbom, compliance, policy_check, remediate, plus intel_lookup and exposure_paths. Missing a dedicated 'list past scans' or policy management tool, but scan's result_id paging mitigates; minor gaps only.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
AWS cloud security scanners for AI agents — S3, IAM, EC2, EKS, RDS, CloudTrail, CloudWatch Logs
MCP server: static security scanner for MCP servers, agent skills & plugins. 17 attack patterns.