Skip to main content
Glama
L337-org

docker-mcp-server

by L337-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

scout_cves

Read-only

Scan a container image for known CVEs, filtering by severity and fixed versions to produce a focused vulnerability report.

Instructions

List vulnerabilities (CVEs) in an image via Docker Scout.

Anonymous scans work for public images; Hub policy enforcement and richer recommendations need docker login on the host that runs the CLI - this server's host, or the target ssh:// host itself when no local scout plugin is installed. Start with scout_quickview for a per-severity summary; scout_sbom inventories packages without vulnerability matching. Does not raise on a non-zero CLI exit (a missing scout plugin or a timeout still raises) - inspect raw.stderr.

Args: image: Image reference (a tag or a digest) only_fixed: Only report CVEs with a fixed version available only_severity: Filter to these severities (omit for all) ignore_base: Exclude CVEs introduced by the base image format: Parsed into result as JSON: "sarif" (default, the standard vulnerability-report schema), "spdx", "gitlab", "sbom". Returned verbatim as text: "packages" (Scout's own default, grouped by package), "markdown". There is no plain "json" for this subcommand platform: Platform of the image to analyze, e.g. "linux/amd64"

Returns: dict: {"format": , "result": , "raw": }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
imageYes
formatNosarif
platformNo
only_fixedNo
ignore_baseNo
only_severityNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.2.5
    • changedInput schema / properties / format / default
      Previous value: -"json"New value: +"sarif"
    • addedInput schema / properties / format / enum
      Added value: +[
+  "packages",
+  "sarif",
+  "spdx",
+  "gitlab",
+  "markdown",
+  "sbom"
+]
    • addedInput schema / properties / only_severity / items / enum
      Added value: +[
+  "critical",
+  "high",
+  "medium",
+  "low",
+  "unspecified"
+]
  2. First observedv1.9.0

TDQS

A4.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds a meaningful quirk: 'Does not raise on a non-zero CLI exit (a missing scout plugin or a timeout still raises) - inspect raw.stderr.' It also notes anonymous scan limitations, going 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence has a purpose: purpose, auth context, sibling routing, exit behavior, then a clean arg list. It is front-loaded with the core purpose and does not waste words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 parameters and no output schema, the description covers the return structure (dict with format/result/raw), auth requirements, exit behavior, and format nuances. Nothing an agent needs to decide or invoke correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries full burden for parameter meaning. It explains every parameter: image, only_fixed, only_severity, ignore_base, format (including enum values and JSON vs raw text behavior), and platform. This is far beyond the bare schema and is essential for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'List vulnerabilities (CVEs) in an image via Docker Scout' – a specific verb, resource, and domain. It also differentiates from siblings by referencing scout_quickview (summary) and scout_sbom (packages without matching), making the tool's role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to 'Start with scout_quickview for a per-severity summary' and notes scout_sbom covers packages without vulnerability matching. It also explains when authentication matters, giving clear context on when to use this tool vs alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools