Skip to main content
Glama
FlemingJohn

cyber-mcp-tools

by FlemingJohn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Cyber MCP — 918 techniques, 918 detections, 2,017 mitigations, 154 countermeasures, sourced from attack.mitre.org and d3fend.mitre.org

Cyber MCP Tools

An MCP server over MITRE ATT&CK and MITRE D3FEND — the attack side and the defence side of the same graph, joined on technique id, built so an agent can query them without dragging either dataset into its context window.

918 techniques          enterprise 697 · mobile 124 · ICS 97
918 detection strategies with 2,053 analytics
2,017 mitigations       each with technique-specific guidance
1,251 actors            groups, malware, tools, campaigns
369 techniques          with D3FEND countermeasures (154 distinct)

ATT&CK v19.2. Ten tools. No network calls at runtime.

Official sources — MITRE ATT&CK · MITRE D3FEND · ATT&CK STIX data · D3FEND ontology

Quickstart

git clone https://github.com/FlemingJohn/cyber-mcp-tools
cd cyber-mcp-tools
npm install
npm run build:data     # derives data/ from the MITRE sources
npm run build

Then point a client at it:

{
  "mcpServers": {
    "cyber-mcp-tools": {
      "command": "node",
      "args": ["/absolute/path/to/cyber-mcp-tools/dist/index.js"]
    }
  }
}

Or, if deployed over HTTP, skip all of the above:

claude mcp add --transport http cyber-mcp-tools https://cyber-mcp-tools.vercel.app/mcp

Live at https://cyber-mcp-tools.vercel.app

Per-client setup for Claude Code, Claude Desktop, Cursor and Antigravity is in INSTALL.md.

Related MCP server: MITRE ATT&CK MCP Server

The tools

Tool

Does

Typical cost

attack_search

Find techniques by text, platform or tactic

~130 tok

attack_get

One technique by id

~390 tok

attack_detection

Detection strategy, optionally with analytics

~30 / ~340 tok

attack_mitigations

Mitigations with technique-specific guidance

~200 tok

attack_related

Paginated graph walk: usedBy, subtechniques, parent

~380 tok

attack_actor

Group, malware, tool or campaign lookup

~450 tok

attack_meta

Version, counts, valid filter values

~35 tok

defend_countermeasures

D3FEND countermeasures, with parent roll-up

~73 tok

defend_search

Browse by defensive tactic, or reverse lookup

~55 tok

defend_meta

Coverage, and which domains have none

~44 tok

A full triage — search, read, detection, mitigations — costs about 2.1k tokens.

Why it is built this way

Loading ATT&CK with everything attached is roughly 1.46 million tokens. Every design decision here exists to make that impossible rather than merely discouraged.

Search returns summaries, never descriptions. Twenty results cost ~645 tokens. The same twenty as full objects cost ~17,130. Same navigational value, 26x cheaper.

Fan-out is paginated. T1105 is used by 520 actors, about 34,201 tokens if inlined. attack_related returns 25 and tells you the total, for ~379 tokens.

The expensive shape is never the default. defend_countermeasures on T1055 is 73 tokens; detail: true is 4,477. attack_detection is ~30 tokens without analytics and ~340 with.

Ten tools, not eighty. Tool schemas sit in context on every turn, so breadth lives in parameters rather than in new tools.

Two things most ATT&CK tooling gets wrong

x_mitre_detection no longer exists. ATT&CK v19 removed the prose detection field — zero of the 697 live Enterprise techniques carry it. Detection moved into first-class objects reached through a chain:

technique ←detects─ detection-strategy → analytic → log sources + tunable fields

Tooling written before v19 still reads the old field and silently returns nothing. This server walks the chain, so attack_detection returns the exact log channels to query and the parameters that need tuning per environment.

D3FEND maps at sub-technique level, inconsistently. T1055 Process Injection has no direct countermeasure, but ten of its children do. Ask a naive implementation and it reports "no defences exist" — confidently, and wrongly. defend_countermeasures always reports both the direct hits and which sub-techniques are covered.

What it cannot do

It never sees your environment. No logs, no telemetry, no deployed controls. It is a reference brain, not a detector. Anything it suggests needs validating against your real systems before anyone acts on it.

Analytics are detection ideas, not queries. They are not SPL, KQL or Sigma, and their tunable fields are deliberately unfilled because only you know your baseline.

D3FEND covers 40% of ATT&CK and none of mobile. 549 of 918 techniques have no countermeasure mapped. That is a gap in the mapping, not evidence a technique is undefendable — an important distinction, and one the tools are careful about.

The data is a snapshot. ATT&CK v19.2, frozen at build time. Refreshing means pulling the sources and rebuilding.

MITRE's own disclaimer applies and is reproduced in NOTICE: ATT&CK does not enumerate every technique, and covering it does not guarantee defensive coverage.

Where the data comes from

ATT&CK (attack.mitre.org) is read from a local clone of mitre-attack/attack-stix-data — three STIX 2.1 bundles. Set ATTACK_STIX_DATA to point elsewhere; it defaults to ../attack-stix-data.

D3FEND (d3fend.mitre.org) comes from the published inference output of the d3fend-ontology, vendored into the repo. The ontology itself asserts no direct ATT&CK links — the defence-to-attack edge is inferred by a reasoner over shared digital artifacts, so only the published inference result carries them.

Both builds are offline. Nothing is fetched at build or request time.

Development

npm run build:attack   # rebuild data/attack from the STIX bundles
npm run build:defend   # rebuild data/defend from the D3FEND mappings
npm run build:data     # both
npm run build          # compile to dist/
npm run dev            # run from source over stdio
npm run typecheck      # src and api
npm run inspect        # 23 cases through the MCP Inspector CLI
npm run inspect:ui     # the Inspector web client

npm run inspect drives the server through the reference MCP client and exits non-zero on failure, so it works as a CI gate. It checks that tools respond, that filters filter, that unknown ids fail cleanly, that known-empty cases return empty rather than erroring, and that no tool exceeds its token budget.

Architecture notes and the traps worth knowing before changing anything are in AGENTS.md. Worked call orders for triage, detection engineering, threat intel and gap analysis are in SKILLS.md.

License

The code is MIT — see LICENSE.

Everything under data/ is derived from MITRE ATT&CK and MITRE D3FEND. Both permit redistribution, including commercially, and both require their notices travel with any copy. Those notices are in NOTICE and must stay with any redistribution or deployment.

ATT&CK and D3FEND are registered trademarks of The MITRE Corporation. This project is not affiliated with, endorsed by, or sponsored by MITRE.

Available Tools

10 tools
attack_actorLook up a threat group, malware or toolB

Find a group, malware, tool or campaign by ATT&CK id or name. Spans all domains, since many actors operate in more than one.

ParametersJSON Schema
NameRequiredDescriptionDefault
idOrNameYesATT&CK id such as G0007, or a name such as APT28
techniquesNoInclude the technique ids used

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds the behavioral note that the tool 'spans all domains' (i.e., results are not domain-restricted), which is useful. However, it does not mention side effects (though a lookup is presumably safe), response format, or any limitations such as pagination or access requirements. It is adequate but not rich.

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 concise—two sentences—with the primary purpose front-loaded. The second sentence adds context about cross-domain operation, which is relevant for agent decision-making but not essential. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple lookup tool with two parameters and no output schema, the description covers the core purpose and one behavioral trait (cross-domain). However, it does not mention what results are returned (e.g., attributes, relationship info) or how the techniques flag affects output, leaving gaps an agent might need to infer. It is minimally complete but not comprehensive.

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?

The input schema has 100% coverage, with clear descriptions for both parameters: idOrName accepts a string like 'G0007' or 'APT28', and techniques is a boolean flag. The description does not add further semantic detail beyond what the schema already provides, so a baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Find') and resource ('a group, malware, tool or campaign'), and specifies the lookup by ATT&CK id or name. It is clear and distinct from sibling tools that focus on techniques, detections, or mitigations, though it doesn't explicitly name those alternatives.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus its siblings. The description implies it is for actor/malware/tool lookups, but does not state when NOT to use it or mention alternatives for techniques or other entities. This forces the agent to infer applicability from the title and resource list.

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

attack_detectionGet detection strategy for a techniqueA

Return the ATT&CK v19 detection strategy for a technique. With analytics, includes log sources and tunable fields.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesATT&CK technique id
analyticsNoInclude full analytic detail

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses that 'with analytics' the output includes log sources and tunable fields, which is a useful behavioral detail. However, it does not explicitly state that this is a read-only operation, nor does it mention error handling (e.g., what happens if the technique id is invalid). The word 'Return' implies a safe read, but more transparency would be better.

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?

The description is only two sentences and gets to the point immediately. The primary purpose is stated first, and the conditional nuance about analytics follows. There is zero fluff, and every word earns its place.

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?

For a retrieval tool with two parameters (one required) and no output schema, the description is quite complete. It explains what the tool returns and the effect of the optional parameter. It does not mention return format or error behavior, but these are not critical for a straightforward fetch operation. The description is adequate for an agent to use the tool 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 description coverage is 100%, so both parameters are documented. The description adds meaning for the 'analytics' parameter by clarifying that it includes 'log sources and tunable fields', which goes beyond the schema's vague 'Include full analytic detail'. This extra explanation helps the agent understand the impact of setting analytics to true. The 'id' parameter is already clear in 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 states a specific action ('Return the ATT&CK v19 detection strategy') and a specific resource ('for a technique'), and distinguishes this tool from siblings like attack_mitigations and attack_related by focusing on detection strategy. The version number (v19) adds precision. An agent can clearly tell what this tool does.

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 gives clear context that this tool is for detection strategy, which implies it is not for mitigations or related techniques. However, it does not explicitly name alternatives or state when not to use it. The sibling list makes the separation obvious, but no explicit exclusion is given.

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

attack_getGet one ATT&CK techniqueA

Fetch a single technique by ATT&CK id such as T1055 or T1055.011. Ids are unique across domains.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesATT&CK technique id
includeSubtechniquesNo

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions id uniqueness, which is a useful constraint, but omits critical traits such as whether the operation is read-only, how missing ids are handled, or what the response structure looks like. This is a significant gap for a fetch tool.

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?

The description is exceptionally concise, with two short sentences that front-load the core action and provide a clarifying note. There is zero redundancy; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple fetch tool with two parameters and no output schema, the description adequately covers the primary id input but fails to explain the includeSubtechniques parameter or any aspects of the response. Given the absence of annotations and output schema, this is a notable incompleteness that could lead to incorrect invocation.

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?

The description adds value to the id parameter through concrete examples and the uniqueness statement, but the includeSubtechniques parameter is completely unexplained. With schema description coverage at 50%, the description compensates only partially, leaving one parameter semantically empty.

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 the verb 'Fetch', the resource 'single technique', and the key discriminator 'by ATT&CK id'. The inclusion of concrete examples (T1055, T1055.011) and the note that ids are unique across domains firmly distinguishes it from sibling tools like attack_search and attack_related.

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

Usage Guidelines3/5

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

It implies usage when a specific id is known, but it does not explicitly mention when to prefer alternatives such as attack_search for broad queries or attack_related for linked techniques. There is no explicit when-not-to-use guidance, leaving the agent to infer the intended context.

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

attack_metaATT&CK dataset version and valid filter valuesA

Return the dataset version and counts, plus the valid tactic slugs and platform names for filtering.

ParametersJSON Schema
NameRequiredDescriptionDefault
sectionNoall

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does convey a read-only 'Return' action and lists the returned data categories. It does not mention side effects, auth, rate limits, or how the optional section parameter changes the response, though for a metadata tool the core behavior is reasonably clear.

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?

The description is a single sentence with no filler or redundant clauses. It front-loads the main behavior and lists the output categories efficiently, making every word useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, with one optional enum parameter and no output schema, and the description covers the main return groups. It still leaves gaps: how the section parameter selects subsets, the default behavior, and the response structure are not explicitly described.

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 0%, so the description must compensate. It adds meaning by mapping outputs to version, tactics, and platforms and explains that tactic slugs and platform names are filter values. It does not explicitly explain the 'all' option or clarify what 'counts' refers to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Return') and concrete resources (dataset version, counts, tactic slugs, platform names), so an agent can identify this as a metadata/info tool. It is clearly distinct from the search and content siblings, though it does not explicitly name a sibling or say what it is not.

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

Usage Guidelines3/5

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

The phrase 'valid tactic slugs and platform names for filtering' implies when to use this tool: before filtering by tactics or platforms. However, it gives no explicit when-not-to-use guidance or alternatives, such as when to prefer attack_search or defend_meta.

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

attack_mitigationsGet mitigations for a techniqueA

Return mitigations for a technique, including how each one applies to that specific technique.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesATT&CK technique id
includeGeneralNoInclude the generic mitigation text

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does convey that the tool is read-only in nature ('Return mitigations') and that the output is tailored to the specific technique. It does not elaborate on response structure, potential errors, or any other behavioral constraints, but for a simple query tool this is a modest gap rather than a serious one.

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?

The description is a single front-loaded sentence that starts with the core action and resource, then adds one valuable qualifier about the output. There is no filler, redundant explanation, or unnecessary length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read-only tool with fully documented schemas, the description is mostly adequate. However, since there is no output schema, the description leaves some ambiguity about the exact return shape—for example, whether mitigations come as objects, strings, or keyed by ID—so the qualitative 'including how each one applies' only partially compensates.

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%, so both parameters are already documented: 'id' is the ATT&CK technique id and 'includeGeneral' controls inclusion of generic mitigation text. The description itself adds no direct parameter-level meaning, so the baseline score of 3 is appropriate.

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 uses a specific verb ('Return') and resource ('mitigations for a technique'), and adds a distinctive clause about showing how each mitigation applies to the given technique. This clearly separates it from sibling tools like attack_related, attack_search, or defend_countermeasures.

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

Usage Guidelines3/5

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

The description implies the tool should be used when a caller needs mitigations for a specific ATT&CK technique, and the 'including how each one applies' clause suggests it provides more targeted context than a generic list. However, it does not explicitly state when to prefer this over sibling tools such as defend_countermeasures or attack_related, nor does it name any exclusions.

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

defend_countermeasuresGet D3FEND countermeasures for a techniqueA

Return MITRE D3FEND countermeasures that counter an ATT&CK technique. D3FEND maps mostly at sub-technique level, so a parent id reports which of its children are covered. Pass detail for the full artifact-level payload. Mobile techniques have no D3FEND coverage.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesATT&CK technique id such as T1055 or T1055.001
detailNoInclude every countermeasure from covered sub-techniques, which can be large

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It covers key behaviors: D3FEND maps at sub-technique level, parent IDs report child coverage, the detail flag returns full artifact payloads (and can be large), and mobile techniques have no coverage. This is substantial transparency for a simple read tool, though it stops short of describing error handling or empty results.

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?

Three sentences with zero waste. The purpose is front-loaded, followed by the most critical behavioral caveat (sub-technique mapping) and the parameter flag. Every sentence adds necessary information, and the structure is easy to parse.

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?

For a straightforward read tool with no output schema, the description covers the essential edge cases: parent/child mapping, mobile exclusion, and the detail flag's impact on response size. An agent can call this tool correctly without additional information. It does not detail the exact return format, but the schema-less design makes that less critical.

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 100% for both parameters, but the description adds real value: it explains the id parameter's semantics (parent vs. sub-technique resolution) and the detail parameter's purpose ('full artifact-level payload') beyond the schema's 'Include every countermeasure...' note. This enhances an agent's understanding of what each parameter controls.

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 the verb 'Return' with a specific resource (MITRE D3FEND countermeasures) and the target (an ATT&CK technique). It distinguishes itself from siblings by explicitly focusing on D3FEND countermeasures, which none of the attack_* tools cover. The sub-technique mapping and mobile caveat further clarify its scope.

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 gives concrete guidance on when to use it: for any ATT&CK technique, with notes on parent vs. sub-technique handling and mobile exclusion. While it doesn't explicitly name alternatives, the context implies this is the dedicated countermeasure lookup tool, distinct from the search and metadata siblings. The guidance is sufficient for an agent to select it correctly.

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

defend_metaD3FEND dataset coverage and limitsA

Return how much of ATT&CK the D3FEND mapping actually covers, including which domains have no coverage.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are present, so the description carries the behavioral burden. It clearly frames the operation as read-only via 'Return' and exposes an honest behavioral nuance by saying 'actually covers' and 'no coverage,' indicating it reports real gaps rather than nominal coverage. It does not discuss data freshness or response granularity, but nothing is hidden about side effects.

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?

One focused sentence, front-loads the action and subject, and ends with the most decision-relevant detail (no-coverage domains). No filler or redundant restatement of the name/title.

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?

For a no-parameter metadata tool with no output schema, this gives enough for an agent to select and invoke it: the target dataset, the comparison to ATT&CK, and the expected negative result. It is not a 5 because 'how much' is ambiguous—count, percentage, or per-domain breakdown—and no output schema exists to resolve that.

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?

The input schema has zero properties and the 0-parameter baseline applies; there are no parameter semantics for the description to add. The 100% schema coverage means the empty schema already fully documents the lack of inputs.

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 uses a concrete verb and object: 'Return how much of ATT&CK the D3FEND mapping actually covers.' It also adds a distinguishing deliverable—'which domains have no coverage'—so it reads differently from sibling tools like defend_search or defend_countermeasures.

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

Usage Guidelines3/5

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

There is no explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. The intended use case (checking D3FEND coverage and limits) is implied by the title and the phrase 'mapping actually covers,' but the agent must infer when this beats defend_search or attack_meta.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 10 tool updatesv1.0.0
    • First observedattack_actor
    • First observedattack_detection
    • First observedattack_get
    • First observedattack_meta
    • First observedattack_mitigations
    • First observedattack_related
    • First observedattack_search
    • First observeddefend_countermeasures
    • First observeddefend_meta
    • First observeddefend_search
Deploy Server
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

TDQS

A3.7/5.0

Scored across 10 tools

Disambiguation4/5

The attack_* and defend_* prefixes cleanly separate the ATT&CK and D3FEND domains, and search/get/actor/related have clear targets. The only mild ambiguity is among attack_detection, attack_mitigations, and defend_countermeasures, since all three describe defensive response content, though each names a distinct framework or strategy type.

Naming Consistency3/5

Names consistently use lowercase snake_case and the attack_/defend_ prefixes, which is a recognizable pattern. However, the second part mixes nouns (actor, meta, mitigations), verbs (get, search), and adjectives (related), so it does not follow a single verb_noun convention.

Tool Count5/5

Ten tools is a well-scoped size for a MITRE ATT&CK/D3FEND knowledge server. Each tool covers a distinct retrieval need without feeling padded or redundant.

Completeness5/5

The surface covers technique lookup and search, actor lookup, relationship traversal, detections, mitigations, D3FEND countermeasures, and metadata for both datasets. This provides a comprehensive read-only workflow for threat-intel queries with no obvious dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • ATT&CK MCP Server

    alex-llm
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables querying the MITRE ATT\&CK framework for adversarial tactics, techniques, mitigations, and detection methods through natural language, supporting both ID-based and fuzzy name-based searches.
    3
    -

  • MITRE ATT&CK MCP Server

    stoyky
    F
    license
    B
    quality
    D
    maintenance
    Provides comprehensive access to the MITRE ATT\&CK knowledge base with 50+ tools for querying threat actors, malware, and techniques, including automatic ATT\&CK Navigator layer generation for threat analysis and visualization.
    55
    44
    -

  • MITRE ATT&CK MCP Server

    imouiche
    A
    license
    A
    quality
    D
    maintenance
    Enables AI-native access to the MITRE ATT\&CK framework, allowing LLMs and agents to query techniques, threat groups, software, and generate ATT\&CK Navigator layers for threat intelligence and security workflows.
    65
    39 npm
    5
    Apache 2.0