Skip to main content
Glama

MacTech STIG

by com.mactechsolutionsllc.www
OverviewDiscussionsAdmin

Export a DISA .ckl checklist

export_stig_checklist
Read-onlyIdempotent

Generate a DISA STIG Viewer checklist (.ckl XML) for a benchmark, optionally filtered by severity and pre-populated with findings. This is the artifact an assessment actually hands over - STIG Viewer opens it, eMASS ingests it, and a POA&M is written from it. Rules you do not supply a status for come out as Not_Reviewed. Call this when the user wants a checklist, a scan result recorded, or evidence to submit, rather than just to read a rule.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
host_ipNo
productYesWhich benchmark to build the checklist from
findingsNoPer-rule results. Anything omitted stays Not_Reviewed - an unreviewed rule must never be reported as passing.
severityNoLimit to one severity, e.g. high for a CAT I-only checklist
host_fqdnNo
host_nameNoAsset hostname recorded in the checklist

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cklYesThe .ckl XML. Write it to filename rather than pasting it into a reply.
noteYes
filenameYes
benchmarkYes
rule_countYes
status_countsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / findings / description
      Previous value: -"Per-rule results. Anything omitted stays Not_Reviewed — an unreviewed rule must never be reported as passing."New value: +"Per-rule results. Anything omitted stays Not_Reviewed - an unreviewed rule must never be reported as passing."
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "benchmark": {
+      "type": "string"
+    },
+    "ckl": {
+      "description": "The .ckl XML. Write it to filename rather than pasting it into a reply.",
+      "type": "string"
+    },
+    "filename": {
+      "type": "string"
+    },
+    "note": {
+      "type": "string"
+    },
+    "rule_count": {
+      "type": "number"
+    },
+    "status_counts": {
+      "additionalProperties": false,
+      "properties": {
+        "NotAFinding": {
+          "type": "number"
+        },
+        "Not_Applicable": {
+          "type": "number"
+        },
+        "Not_Reviewed": {
+          "type": "number"
+        },
+        "Open": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "Open",
+        "NotAFinding",
+        "Not_Applicable",
+        "Not_Reviewed"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "benchmark",
+    "rule_count",
+    "status_counts",
+    "filename",
+    "note",
+    "ckl"
+  ],
+  "type": "object"
+}
  3. Changed1 schema field changed
    • changedInput schema / properties / product / enum
      Previous value: -[
-  "cisco_ios_router_ndm",
-  "cisco_ios_router_rtr",
-  "cisco_ios_switch_l2s",
-  "cisco_ios_switch_ndm",
-  "cisco_ios_switch_rtr",
-  "ubuntu2204",
-  "rhel8",
-  "rhel9",
-  "windows11",
-  "windows2022"
-]New value: +[
+  "cisco_ios_router_ndm",
+  "cisco_ios_router_rtr",
+  "cisco_ios_switch_l2s",
+  "cisco_ios_switch_ndm",
+  "cisco_ios_switch_rtr",
+  "cisco_ise_nac",
+  "cisco_ise_ndm",
+  "cisco_nxos_switch_l2s",
+  "cisco_nxos_switch_ndm",
+  "cisco_nxos_switch_rtr",
+  "ubuntu2204",
+  "rhel8",
+  "rhel9",
+  "windows11",
+  "windows2022"
+]
  4. Changed1 schema field changed
    • changedInput schema / properties / product / enum
      Previous value: -[
-  "cisco_ios_router_ndm",
-  "rhel8",
-  "rhel9",
-  "windows11",
-  "windows2022"
-]New value: +[
+  "cisco_ios_router_ndm",
+  "cisco_ios_router_rtr",
+  "cisco_ios_switch_l2s",
+  "cisco_ios_switch_ndm",
+  "cisco_ios_switch_rtr",
+  "ubuntu2204",
+  "rhel8",
+  "rhel9",
+  "windows11",
+  "windows2022"
+]
  5. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=true, destructiveHint=false), the description discloses a key behavioral trait: rules without a supplied status default to Not_Reviewed, preventing silent false positives. It also clarifies the checklist is the actual assessment artifact ingested by downstream systems, which adds context 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?

Four tight sentences front-load the action and rationale. Each sentence earns its place: generation, downstream significance, default status behavior, and usage trigger. No filler or repetition of structured fields.

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?

The description covers purpose, output artifact context, default handling, optional filters, and when to invoke the tool. With an output schema present, return-value details are unnecessary, and the remaining parameter meanings are either clear from names or schema descriptions.

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 coverage is 67%, so the description partially carries parameter meaning. It refers to severity filtering and pre-population via findings, but these largely mirror the schema's existing parameter descriptions. It adds no new clarity for host_ip or host_fqdn, which lack schema descriptions, leaving a modest gap.

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 a specific verb-resource pair: 'Generate a DISA STIG Viewer checklist (.ckl XML) for a benchmark.' It also distinguishes the tool from read-only rule lookups by positioning it as the artifact handed over to STIG Viewer/eMASS, clearly separating it from sibling tools like get_stig_rule.

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

Usage Guidelines4/5

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

The description explicitly states when to call it: 'when the user wants a checklist, a scan result recorded, or evidence to submit.' It also gives a when-not signal ('rather than just to read a rule'), though it does not name the exact sibling tool to use instead; naming get_stig_rule would make it fully explicit.

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

All MacTech STIG toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources