Skip to main content
Glama
jeneric
by jeneric

defense_details

Return MITRE's text for ATT&CK defenses named by id: mitigations (M1026), detection strategies (DET0103) and analytics (AN0286), as listed under protect.mitigations and detect in a defenses_for_technique answer or under each technique in a…

Instructions

Return MITRE's text for ATT&CK defenses named by id: mitigations (M1026), detection strategies (DET0103) and analytics (AN0286), as listed under protect.mitigations and detect in a defenses_for_technique answer or under each technique in a techniques_for_actor answer. ids takes up to 10 per call, matched case-insensitively. A mitigation returns its description and how many techniques it covers; with technique_id it also returns MITRE's text about that mitigation on that technique as technique_description, which is null when that mitigation is not paired with that technique (a revoked id answers for its replacement, reported in technique.redirected_from). A detection strategy returns every analytic in full: description, platforms, log_sources (name, channel and data component) and mutable_elements, the tunables a detection engineer sets. An analytic id returns that analytic alone. Analytics say what to collect, not how to enable it: the enabling steps are in the vendor's documentation. not_found lists ids that matched nothing; if none match, the call is refused. Quote MITRE's text as written and label anything you add as your own. 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
idsYes
technique_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

A4.6/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 load and does so richly: per-id-family return shapes, technique_description being null when a mitigation is not paired with the technique, revoked ids answering for their replacement via technique.redirected_from, not_found listing unmatched ids, outright refusal when nothing matches, and a {"status": "not_ready"} fallback instead of an error. It even discloses a semantic caveat that analytics describe what to collect, not how to enable it.

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 action and the id families, then moving into return shapes and edge cases. It is a dense wall of text with long compound sentences, but nearly every clause conveys a distinct behavioral fact rather than repeating structured data.

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 and no annotations, yet the description specifies what comes back for each id family, the fields of a detection strategy and analytic, the null/redirect edge cases, the not_found contract, and the not_ready state. An agent has everything needed to call and interpret this correctly.

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 coverage is 0%, so the description must compensate, and it does: ids is documented as taking up to 10 case-insensitively matched identifiers, and technique_id is documented as adding technique_description to the response. It does not state that technique_id is only meaningful for mitigations (not detection strategies or analytics), leaving a small ambiguity.

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 and resource — return MITRE's text for ATT&CK defenses named by id — and enumerates the three id families it accepts (M1026 mitigations, DET0103 detection strategies, AN0286 analytics). It also tells the agent where those ids come from (protect.mitigations / detect in a defenses_for_technique answer), which separates it from the sibling defenses_for_technique that discovers rather than resolves ids.

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?

Usage context is clear: this is the detail-lookup step after you already hold ids from defenses_for_technique or techniques_for_actor, and chunking is bounded at 10 ids per call. It never explicitly names an alternative tool or states a when-not-to-use condition, so it stops short of the top tier.

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