Skip to main content
Glama
Sign In
MITRE ATT&CK MCP Server

MITRE ATT&CK MCP Server

by imouiche
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_all_parent_techniques

Retrieve parent techniques (main ATT&CK IDs without subtechniques) for enterprise, mobile, or ICS domains. Filter out revoked or deprecated entries and optionally include descriptions.

Instructions

Get all parent techniques (exclude subtechniques) in a given domain.

Parent techniques are the main techniques without a dot in their ATT&CK ID,
e.g., T1566, T1055 (not T1566.001).

Args:
    domain: ATT&CK domain ("enterprise", "mobile", "ics").
    remove_revoked_deprecated: Whether to exclude revoked/deprecated techniques.
    include_description: Whether to include descriptions.

Returns:
    {
      "domain": "<domain>",
      "count": <number of parent techniques>,
      "parent_techniques": [
        {
          "attack_id": "<TXXXX>",
          "name": "<technique name>",
          "stix_id": "<attack-pattern--UUID>",
          "description": "<text or null>",
          "tactics": ["<Tactic 1>", "<Tactic 2>", ...]
        },
        ...
      ],
      "formatted": "<optional human-readable output>",
      "message": "<summary>"
    }

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_all_parent_techniques"
  }
}

Input Schema

NameRequiredDescriptionDefault
domainNoenterprise
include_descriptionNo
remove_revoked_deprecatedNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It explains the input parameters and the complete output structure including fields like formatted and message. It does not explicitly state read-only nature, but the function name and output description imply no side effects. The transparency is good but could be improved by noting safe 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 summary, clarification of parent techniques, and separate args/returns sections. It is slightly verbose but front-loaded with the core purpose. Every sentence adds value, so it earns its length.

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?

Given the output schema is fully described, the description covers all necessary behavioral details. The parameter explanations and output format are comprehensive for a tool with 3 simple parameters. No gaps remain for an agent to guess.

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?

The input schema has 0% description coverage, but the description explains each parameter: domain with example values, remove_revoked_deprecated and include_description as boolean controls. Default values are also specified, adding significant semantic value beyond the schema.

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 clearly states 'Get all parent techniques (exclude subtechniques) in a given domain.' It defines parent techniques via the ATT&CK ID format (no dot), making the tool's purpose specific and distinct from siblings like get_all_techniques and get_all_subtechniques.

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 implicitly differentiates from siblings by focusing on parent techniques, but does not explicitly state when to use this tool versus alternatives. The context of sibling tools includes get_all_techniques and get_all_subtechniques, so the purpose is clear enough for an agent to select correctly.

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