Skip to main content
Glama
Sign In
docker-mcp-server

docker-mcp-server

by L337-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

scout_quickview

Read-only

Summarize a container image's CVE posture with severity counts and base-image status, enabling quick security triage.

Instructions

Render a compact summary of an image's CVE posture.

The fastest triage step - counts per severity plus base-image status. Drill into individual findings with scout_cves, which unlike this tool can emit machine-readable JSON; get upgrade suggestions with scout_recommendations. Output is plain text only: docker scout quickview has no output-format option, so result is always the rendered text rather than a parsed document. Does not raise on a non-zero CLI exit (a missing scout plugin or a timeout still raises) - inspect raw.stderr.

Args: platform: Platform of the image to analyze, e.g. "linux/amd64"

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

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "image": "<image>"
    },
    "name": "scout_quickview"
  }
}

Input Schema

NameRequiredDescriptionDefault
imageYes
platformNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.2.5
    • removedInput schema / properties / format
      Removed value: -{
-  "default": "json",
-  "type": "string"
-}
  2. First observedv1.9.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses important runtime behavior: output is always plain text, `result` is never a parsed document, and non-zero CLI exits do not raise while missing plugins or timeouts do. This adds significant context about error handling and return value semantics that the annotations do not provide.

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 tightly organized and front-loads purpose, then usage guidance, output format, error behavior, and arguments. Every sentence contributes practical guidance without redundant fluff or repetition of schema information.

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?

Given the lack of an output schema, the description fully explains the return shape (`result` and `raw`) and the plain-text nature of the output. It also covers error behavioraaaa, platform usage, and how this tool relates to its siblings, making it complete enough for an agent to invoke correctly.

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

Parameters3/5

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

The schema itself has no parameter descriptions, and the description only documents `platform` with an example ('linux/amd64'). The required `image` parameter is not explicitly explained; it is only implied by the tool's purpose. This partially compensates for the 0% schema coverage but leaves the required parameter underspecified.

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 states a specific verb and resource: 'Render a compact summary of an image's CVE posture' and clarifies the output scope as 'counts per severity plus base-image status'. It also distinguishes the tool from scout_cves and scout_recommendations, preventing ambiguity between siblings.

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?

The description explicitly positions this tool as 'the fastest triage step' and directs users to scout_cves for individual findings or machine-readable JSON inaddition, and to scout_recommendations for upgrade suggestions. This gives clear when-to-use and when-not-to-use guidance, including the plain-text-only limitation.

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