topai-mcp-suite

Overview Schema Source Related Servers Discussions Admin

dockerlean_wasm_audit

Read-onlyIdempotent

Audit Dockerfiles for layer bloat, cache-busting RUN ordering, root user risks, missing multi-stage builds, and excessive image footprint to reduce container size and security exposure.

Instructions

Statically lints and audits Dockerfiles for layer bloat, cache-busting RUN ordering, root user vulnerabilities, missing multi-stage build patterns, and excessive image footprint. Use when: Reviewing container configurations, CI/CD pipeline Dockerfiles, or developer images to minimize image size and security risks. Do not use when: Auditing git diffs or evaluating Terraform infrastructure plans. Alternative: Use agentpr_guard_audit for git diff security, or terracost_blast_evaluate for cloud infrastructure cost deltas. Execution: Runs locally in-memory (<5ms), read-only, idempotent, zero network calls, zero telemetry, air-gapped deterministic.

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": {
      "dockerfileContent": "<dockerfileContent>"
    },
    "name": "dockerlean_wasm_audit"
  }
}

Input Schema

Name	Required	Description	Default
`licenseKey`	No	Optional TopAI Sovereign Pro offline license key (or set TOPAI_LICENSE_KEY env variable).
`dockerfileContent`	Yes	Full UTF-8 content of the Dockerfile to audit for layer efficiency and security.

Output Schema

Name	Required	Description
`report`	Yes	Detailed container layer analysis, detected anti-patterns, and severity scores.
`markdown`	Yes	Formatted Markdown audit report with remediation instructions.
`efficiencyNotice`	Yes	Overall lean score summary (0-100 scale).

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.0.6Oct 22, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / dockerfileContent / description

Previous value: -"Content of the Dockerfile"New value: +"Full UTF-8 content of the Dockerfile to audit for layer efficiency and security."

addedInput schema / properties / licenseKey

Added value: +{
+  "description": "Optional TopAI Sovereign Pro offline license key (or set TOPAI_LICENSE_KEY env variable).",
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "efficiencyNotice": {
+      "description": "Overall lean score summary (0-100 scale).",
+      "type": "string"
+    },
+    "markdown": {
+      "description": "Formatted Markdown audit report with remediation instructions.",
+      "type": "string"
+    },
+    "report": {
+      "description": "Detailed container layer analysis, detected anti-patterns, and severity scores.",
+      "type": "object"
+    }
+  },
+  "required": [
+    "report",
+    "markdown",
+    "efficiencyNotice"
+  ],
+  "type": "object"
+}

First observedv0.1.0Oct 18, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint:false and openWorldHint:false, so the safety profile is covered. The description still adds genuinely new operational facts: in-memory execution under 5ms, zero network calls, zero telemetry, and air-gapped determinism — relevant for CI trust decisions. It does not restate what happens on invalid Dockerfile content, which keeps it from a 5.

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?

Front-loaded with the core capability, then cleanly segmented into Use when / Do not use when / Alternative / Execution labels — very scannable. Slightly overbuilt at the tail, where 'zero telemetry, air-gapped deterministic' partially re-states the no-network claim and the openWorldHint annotation.

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?

An output schema exists, so return-value shape needn't be explained, and the description covers capability, routing, and runtime properties. The only residual gap is that it never indicates what a caller should expect regarding license enforcement for the optional `licenseKey` parameter, which matters for a tool that may silently degrade.

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?

Schema description coverage is 100% and both parameters carry their own descriptions, so the schema does the heavy lifting. The description adds nothing about `dockerfileContent` (e.g., whether partial snippets are acceptable) or the optional `licenseKey` gating behavior, so baseline 3 applies.

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?

States a specific verb pair (lints and audits) plus the precise resource (Dockerfiles) and enumerates the five concrete defect classes it detects (layer bloat, cache-busting RUN ordering, root user, missing multi-stage, image footprint). No sibling tool operates on Dockerfiles, and the description makes that domain ownership unmistakable.

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?

Provides explicit 'Use when' triggers (reviewing container configs, CI/CD Dockerfiles, developer images) and explicit exclusions ('Do not use when: Auditing git diffs or evaluating Terraform infrastructure plans'). It then names the correct substitutes by name — `agentpr_guard_audit` and `terracost_blast_evaluate` — which are both actual siblings, so routing is unambiguous.

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

Deploy Server