Skip to main content
Glama
L337-org

docker-mcp-server

by L337-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

scout_compare

Read-only

Compare two container image references to identify CVE differences after a rebuild, filtering by severity and excluding unchanged packages for a clear vulnerability delta.

Instructions

Compare two image references and report the CVE delta.

Exactly one of to, to_env, or to_latest=True must be supplied to identify the comparison target. Use it after a rebuild to check the new image against the old (scout_cves scans a single image). Does not raise on a non-zero CLI exit (a missing scout plugin or a timeout still raises) - inspect raw.stderr. Raises ToolInputError if to names a local directory/archive while the call has to run on a remote ssh:// host (no local scout plugin): the file is not staged, so it would resolve against that host's filesystem instead.

Args: image: The new / candidate image reference to: Compare against this image reference, directory, or archive (a local directory/archive only when the CLI runs on this host - see above) to_env: Compare against an image associated with this Scout environment to_latest: Compare against the latest scan of image only_severity: Filter to these severities (omit for all) ignore_unchanged: Exclude unchanged packages from the diff format: Output format; only "json" (the default) is parsed into result platform: Platform of the image to analyze

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNo
imageYes
formatNojson
to_envNo
platformNo
to_latestNo
only_severityNo
ignore_unchangedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.2.5
    • addedInput schema / properties / format / enum
      Added value: +[
+  "json",
+  "markdown",
+  "text"
+]
    • addedInput schema / properties / only_severity / items / enum
      Added value: +[
+  "critical",
+  "high",
+  "medium",
+  "low",
+  "unspecified"
+]
  2. First observedv1.9.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: it does not raise on non-zero CLI exit, it raises ToolInputError for a remote-host/local-file mismatch, and it explains that only 'json' format is parsed into result. This is meaningful disclosure of edge-case behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is well-structured with a one-line summary, a clear usage paragraph, and a compact Args list. It is longer than minimal, but every sentence earns its place: the one-of constraint, the rebuild use case, the non-zero exit behavior, and the remote-host caveat are all non-obvious and necessary. The Args section is slightly redundant with the schema but adds semantic context.

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

Completeness4/5

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

For a tool with 8 parameters, no output schema, and 0% schema description coverage, the description covers the critical invocation constraints (one-of target, format parsing, error behavior) and the return shape. It could add a bit more on only_severity/ignore_unchanged semantics, but the schema enums and parameter names carry much of that weight. The return dict is explicitly documented.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It does: it explains the semantic role of image ('new / candidate'), the one-of constraint among to/to_env/to_latest, the meaning of to_latest ('latest scan of image'), and the format behavior ('only json is parsed into result'). It does not detail only_severity or ignore_unchanged, but those are fairly self-explanatory from their names and schema enums.

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 ('Compare'), a specific resource ('two image references'), and the output ('report the CVE delta'). It also distinguishes itself from the sibling scout_cves by explicitly noting that scout_cves scans a single image, so an agent can tell them apart.

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 gives explicit when-to-use guidance: 'Use it after a rebuild to check the new image against the old' and names the alternative (scout_cves) with the condition that selects it. It also specifies the exact one-of constraint for to/to_env/to_latest, which is critical for correct invocation.

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