# io.github.jeneric/stig-mcp (pypi · stig-mcp)

MCP server mapping MITRE ATT&CK® -> NIST 800-53r5 -> DISA STIG fix/check steps

- Trust score: 79/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-03

## Components

- pypi · `stig-mcp`: 79/100 (this document), [markdown](https://verifymcp.io/servers/jeneric-stig-mcp/stig-mcp.md), [page](https://verifymcp.io/servers/jeneric-stig-mcp/stig-mcp)

## Channel facts

- Registry: `pypi`
- Package: `stig-mcp`
- Version: `0.1.2`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-03.

- **Supply Chain Security**: 100/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - Runs setuptools.build_meta at install time, a recognised build step with no custom scripting around it.
  - 2 of 30 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 100/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to jeneric/STIG-MCP).
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 0 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 67/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 1642 tokens (~205/item across 8 items; 8 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 10/100
  - Stability observed for 3 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 67/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 8 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 8 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## Install

### How do I install the io.github.jeneric/stig-mcp server?

io.github.jeneric/stig-mcp runs locally as a PyPI package, launched with uvx stig-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add jeneric-stig-mcp -- uvx stig-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "jeneric-stig-mcp": {
      "command": "uvx",
      "args": [
        "stig-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "jeneric-stig-mcp": {
      "command": "uvx",
      "args": [
        "stig-mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add jeneric-stig-mcp -- uvx stig-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "jeneric-stig-mcp": {
      "type": "local",
      "command": [
        "uvx",
        "stig-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add jeneric-stig-mcp --command uvx --arg stig-mcp
```

### Hermes

```yaml
mcp_servers:
  jeneric-stig-mcp:
    command: "uvx"
    args: ["stig-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "jeneric-stig-mcp": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "stig-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add jeneric-stig-mcp -t stdio -c uvx -a stig-mcp
```

### Other

```json
{
  "mcpServers": {
    "jeneric-stig-mcp": {
      "command": "uvx",
      "args": [
        "stig-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-03 (score 79, +16)

- [security improvement] Malware scan: unverified → pass

### 2026-10-02 (score 63, 0)

- [security improvement] Malware scan: unverified → pass
- [functional] Package version: 0.1.1 → 0.1.2

### 2026-10-01 (score 63, +1)

- [functional improvement] Stability: unverified → 0.03
- [functional] Package version: 0.1.0 → 0.1.1

### 2026-09-30 (score 62)

First indexed and scored.

## MCP tools (8)

### `mitigations_for_technique` (~329 tokens)

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 parameters:

- `severity`
- `stig_ids`
- `system_description`
- `technique_id` (string, required)

### `techniques_for_actor` (~327 tokens)

List an ATT&CK actor's techniques, optionally expanded with mitigations for given
systems. actor is an ATT&CK group id, name or alias; case, spacing, punctuation and
a trailing "Group" or "Team" are ignored, and actor.matched_as then names what
matched. actor.also_matches, when present, lists other groups the same label loosely
names. A misspelling is not corrected: the error names the closest groups, so call
again with the group id of the one meant. The answer opens with summary, which
counts the techniques; with include_mitigations it adds the same counts
mitigations_for_technique gives, across every technique. Use those counts rather
than counting lists yourself. controls lists each control once with its rule ids,
and findings lists each finding once, without check or fix text (call
finding_details for those). Each technique lists its control ids grouped by where
the mapping came from ("ctid" or "override"). stig_ids accepts at most 200; it and
severity (CAT levels, e.g. ["I"]) are validated always but only take effect with
include_mitigations. To scope a system you cannot name, pass system_description
instead. If the knowledge base is not built yet this returns {"status": "not_ready"}
with the commands to run, rather than an error.

Input parameters:

- `actor` (string, required)
- `include_mitigations` (boolean)
- `severity`
- `stig_ids`
- `system_description`

### `finding_details` (~211 tokens)

Return DISA's check and fix text for STIG findings, with each finding's benchmark,
release and CCIs. ids takes up to 50 rule ids (SV-...r..._rule) or V- ids as listed
under findings in a mitigations_for_technique or techniques_for_actor answer, in any
case. Prefer the V- id: a rule id carries its release's revision and matches only that
release. A V- id that two benchmarks or majors share returns every match, each labeled
with its benchmark. not_found lists ids that matched nothing; if none match, the call
is refused with an error instead. Quote check_text and fix_text as DISA wrote them, and
label anything you add, such as commands or explanations, as your own rather than DISA's.
If the knowledge base is not built yet this returns {"status": "not_ready"} with the
commands to run, rather than an error.

Input parameters:

- `ids` (array, required)

### `resolve_system` (~276 tokens)

Resolve a free-text system description to candidate DISA STIG(s). Returns
'candidates' and 'notes'. limit caps the number of distinct benchmarks returned,
not rows: a benchmark holding more than one STIG major (for example vSphere 8.0)
contributes every major as its own row, so a caller asking for limit=5 may receive
more than 5 rows. Include the product build where one exists (e.g. 'ESXi 8.0 U3');
each candidate reports whether it applies to that build in the 'applicable' field.
When the description names a product version this knowledge base does not hold, a
note in 'notes' says so and names the versions it does hold. A description naming
more than one system is split on 'and' and commas and each part judged separately,
so it can carry one such note per part, each quoting the part it is about. When more
benchmarks tie with the last benchmark shown than limit allows, a note in 'notes'
says how many and suggests calling again with a higher limit.
If the knowledge base is not built yet this returns {"status": "not_ready"} with the
commands to run, rather than an error.

Input parameters:

- `limit` (integer)
- `system_description` (string, required)

### `search_techniques` (~89 tokens)

Search ATT&CK techniques by name or id. Ids and names ATT&CK has revoked also match,
returning the replacement technique with redirected_from set to the old id.
If the knowledge base is not built yet this returns {"status": "not_ready"} with the
commands to run, rather than an error.

Input parameters:

- `limit` (integer)
- `query` (string, required)

### `list_stigs` (~82 tokens)

List the STIGs in the knowledge base, optionally filtered by a substring of the
title, the benchmark id (e.g. RHEL_9_STIG), or the product keywords.
If the knowledge base is not built yet this returns {"status": "not_ready"} with the
commands to run, rather than an error.

Input parameters:

- `filter`

### `install_knowledge_base` (~184 tokens)

Install the prebuilt knowledge base this server answers from. With no arguments, download
the newest release for this server from this project's GitHub releases
(github.com/jeneric/STIG-MCP), verify its SHA-256 and install it; this downloads and
verifies about 5 MB and can take several seconds. It is the only tool besides
check_sources that uses the network. release pins an exact kb-YYYY-MM-DD tag, for
rollback. On a host without network access, pass path (a .sqlite.xz or .sqlite copied from a
release) and sha256 (the value its SHA256SUMS lists); nothing is then requested. Call this
when another tool returns {"status": "not_ready"}, or when check_sources reports "install".

Input parameters:

- `path`
- `release`
- `sha256`

### `check_sources` (~144 tokens)

Check whether a newer prebuilt knowledge base is published than the one installed. This
contacts only this project's GitHub releases (github.com/jeneric/STIG-MCP). action is
"install" (call install_knowledge_base), "upgrade_package" (a newer knowledge base needs a
newer stig-mcp; upgrade_to says which), "build_locally" (nothing usable is installed and no
release exists for this stig-mcp; build with stig-mcp-fetch and stig-mcp-ingest), or
"none"; reason says why. It works even when the knowledge base is not built, and then
not_ready says why and what to run.

## Diagnostics

Captured diagnostic sections: Provenance, Install scripts, Dependencies. The full working is on the page: https://verifymcp.io/servers/jeneric-stig-mcp/stig-mcp#diagnostics

## Score history

- 2026-10-03: 79
- 2026-10-02: 63
- 2026-10-01: 63
- 2026-09-30: 62

## Common questions

### What is the io.github.jeneric/stig-mcp server?

io.github.jeneric/stig-mcp is listed in the public MCP registry as io.github.jeneric/stig-mcp. MCP server mapping MITRE ATT&CK® -> NIST 800-53r5 -> DISA STIG fix/check steps. This page covers its PyPI package (stig-mcp).

### Is the io.github.jeneric/stig-mcp server safe to use?

io.github.jeneric/stig-mcp scores 79 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 3 October 2026. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the io.github.jeneric/stig-mcp server expose?

io.github.jeneric/stig-mcp exposes 8 tools: mitigations_for_technique, techniques_for_actor, finding_details, resolve_system, search_techniques, and 3 more. Their descriptions and schemas cost roughly 1,642 tokens of context every time the server is loaded.

### Is the io.github.jeneric/stig-mcp server still maintained?

io.github.jeneric/stig-mcp is still listed as active in the MCP registry. We last reached this channel on 3 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the io.github.jeneric/stig-mcp server under?

io.github.jeneric/stig-mcp declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- PyPI project: https://pypi.org/project/stig-mcp/
- Socket report: https://socket.dev/pypi/package/stig-mcp
- Repository: https://github.com/jeneric/STIG-MCP
- Changelog RSS feed: https://verifymcp.io/servers/jeneric-stig-mcp/stig-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/jeneric-stig-mcp/stig-mcp.json
- HTML version of this page: https://verifymcp.io/servers/jeneric-stig-mcp/stig-mcp