Skip to main content
Glama

mitre-cwe-mcp-server

Retrieve CAPEC attack patterns

cwe_get_attack_pattern
Read-onlyIdempotent

Retrieve CAPEC attack patterns, categories, and views by ID, such as CAPEC-66, CAPEC66, or 66, including Deprecated and Obsolete records; each entry’s type says which. Processes up to 20 distinct IDs within a 24,000-byte response budget and discloses deferred IDs; a CWE ID or an item that is no ID returns in notFound with recovery guidance; only an item holding a control character other than whitespace, or a non-ID item over 150 characters, rejects the whole call. Patterns default to summary, prerequisites, execution, mitigations, and mappings; categories and views default to summary (the category summary or view objective) and relations (members in source order, or a filter-defined view’s source XPath filterDefinition). Views CAPEC-1000 (Mechanisms of Attack) and CAPEC-3000 (Domains of Attack) are entry points for browsing patterns by category. A default section that does not fit the budget is omitted whole and named with its size and a re-call (kind partial). The notes section, outside the defaults, returns recorded MITRE notes. Explicit sections remain complete, including one oversized record with disclosure; an empty array requests an outline. Recorded CWE and ATT&CK mappings are incomplete and do not establish current ATT&CK validation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsYesOne to 200 submitted IDs; up to 20 distinct items are processed within the response budget.
sectionsNoSelected sections; omit for defaults, or pass an empty array for an outline.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoMaximum identifiers processed per call.
errorNoPresent when the call failed. Absent on success.
shownNoIdentifiers processed.
noticeNoWhole-identifier continuation and budget disclosure.
entriesNoFound projected entries in request order.
guidanceNoCall-level guidance: deferred-ID continuation, budget disclosure, and the re-call for parameters the selected sections leave unused.
notFoundNoPer-ID misses; an all-missing batch is success.
truncatedNoWhether the count or response budget deferred identifiers.
provenanceNoLoaded catalog provenance.
totalCountNoDistinct submitted identifiers before the batch cap.
deferredIdsNoDistinct items to submit in a later call: canonical IDs, or the collapsed text of an item that is no ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover read-only/idempotent/open-world, while the description discloses the 24,000-byte budget, deferred-ID reporting, omission of default sections with a named size and 'kind partial' re-call, per-item notFound behavior for CWE IDs, whole-call rejection triggers, and the caveat that recorded ATT&CK mappings are not current validation. That is substantial behavior beyond structured fields.

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?

Purpose and ID formats are front-loaded and nearly every clause carries a distinct constraint. It is, however, a single semicolon-chained block that is hard to parse for a tool with this many conditional behaviors; light structure would improve it without adding 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?

For a batched lookup with an output schema already defining return shape, the description covers the remaining risks: budget truncation, section defaults, per-item error handling, and mapping reliability. Nothing an agent needs to call it correctly is missing.

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%, so the baseline is 3; the description earns above that by documenting the default section set for patterns (summary, prerequisites, execution, mitigations, mappings) versus categories/views (summary plus relations in source order or XPath filterDefinition), which the schema never states. It also explains the notes section as outside the defaults.

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 (retrieve) and resource (CAPEC attack patterns, categories, views) plus accepted ID forms (CAPEC-66, CAPEC66, 66) and the fact that Deprecated/Obsolete records are included. An agent can tell this is a by-ID lookup rather than the sibling cwe_search_attack_patterns sweep without opening the schema.

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?

Gives clear operating context: up to 20 distinct IDs per call, empty array requests an outline, and CAPEC-1000/CAPEC-3000 are named as entry points for browsing by category. It stops short of explicitly routing to cwe_search_attack_patterns when IDs are unknown, so there is no stated alternative path.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.