Skip to main content
Glama
jeneric
by jeneric

mitigations_for_technique

Find NIST 800-53r5 controls and DISA STIG mitigations for a MITRE ATT&CK technique, with optional severity or system filters.

Instructions

Return 800-53r5 controls and the DISA STIG findings that mitigate an ATT&CK technique. The answer opens with summary: rules found, rules per CAT, control_counts (how many controls map and how many have rules), cat_i (the CAT I V- ids with their count) and controls_with_rules. Use those counts rather than counting lists yourself. Then each control lists the rule ids of its findings, and findings lists each finding once. Findings carry no check or fix text: call finding_details with their rule ids or V- ids for DISA's exact steps. severity narrows findings to CAT levels, e.g. ["I"]. A technique id ATT&CK has revoked (e.g. T1562) is answered for its replacement, and the response reports the redirect in technique.redirected_from. Include the product build in system_description where one exists (e.g. 'ESXi 8.0 U3'): some products ship two STIG versions with different remediations, and the build selects the one that applies. stig_ids narrows to benchmarks you already know and accepts at most 200; to scope a system you cannot name, pass system_description instead and let the resolver do it. If the knowledge base is not built yet this returns {"status": "not_ready"} with the commands to run, rather than an error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
severityNo
stig_idsNo
technique_idYes
system_descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the response envelope (summary, rules found, cat_i, controls_with_rules), that findings lack check/fix text, that revoked techniques are redirected and reported via technique.redirected_from, and that an unbuilt KB returns {"status": "not_ready"} instead of an error.

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 purpose, then response shape, then parameter guidance. Dense but nearly every sentence adds a distinct behavioral fact; the length is justified by the amount of non-obvious behavior it must convey, though it could be tightened slightly.

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?

No output schema or annotations exist, yet the description sketches the return structure, the redirect field, and the not_ready case, which is everything an agent needs to call and interpret this tool.

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 must compensate, and it documents all four: severity's CAT-level semantics with an example, stig_ids' cap and intended use, system_description's build string format with an ESXi example and rationale, and technique_id's redirect behavior.

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 precise verb+resource pair ('Return 800-53r5 controls and the DISA STIG findings that mitigate an ATT&CK technique') and distinguishes itself from the sibling finding_details by naming what it does not return (check/fix text). An agent can tell exactly what this produces.

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?

Gives explicit routing rules: use finding_details for exact DISA steps, pass system_description when you cannot name a system, use stig_ids only for benchmarks you already know. It also states the 200-item cap and what severity accepts, so the agent knows when each parameter applies.

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