# Mitigant (remote · mcp.mitigant.io)

Run real, auto-recovered cloud attacks on AWS, Azure and GCP to test your defenses.

- Trust score: 63/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `mcp.mitigant.io`: 63/100 (this document), [markdown](https://verifymcp.io/servers/mitigant-mitigant-mcp/mcp.md), [page](https://verifymcp.io/servers/mitigant-mitigant-mcp/mcp)

## Channel facts

- Endpoint: `https://mcp.mitigant.io/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.1.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, 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-11-05.

- **Endpoint Security**: 57/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (launch_attack).
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 59/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 3865 tokens (~322/item across 12 items; 12 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 37/100
  - Stability observed for 11 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 93/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 79% of tool parameters carry a description.
- **Tool Safety**: 50/100
  - Injection-marker check failed: the description of tool "clean_up_attack" contains an instruction to conceal the call from the user, the text "do not tell the user", at byte 814 of that field.
  - We read all 12 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 13 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the Mitigant MCP server?

Mitigant is a hosted endpoint at https://mcp.mitigant.io/mcp, so there is nothing to install locally. 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 --transport http mitigant-mitigant-mcp 'https://mcp.mitigant.io/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "mitigant-mitigant-mcp": {
      "url": "https://mcp.mitigant.io/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "mitigant-mitigant-mcp": {
      "type": "http",
      "url": "https://mcp.mitigant.io/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.mitigant-mitigant-mcp]
url = "https://mcp.mitigant.io/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "mitigant-mitigant-mcp": {
      "type": "remote",
      "url": "https://mcp.mitigant.io/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add mitigant-mitigant-mcp --url 'https://mcp.mitigant.io/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  mitigant-mitigant-mcp:
    url: "https://mcp.mitigant.io/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "mitigant-mitigant-mcp": {
      "Transport": "http",
      "Url": "https://mcp.mitigant.io/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add mitigant-mitigant-mcp -t streamable-http -u 'https://mcp.mitigant.io/mcp'
```

### Other

```json
{
  "mcpServers": {
    "mitigant-mitigant-mcp": {
      "type": "http",
      "url": "https://mcp.mitigant.io/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## 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-11-05 (score 63, +1)

No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-03 (score 62, +1)

- [security] The server rewrote its instructions, which are the text every model session reads
- [functional] New tool “get_context”

### 2026-11-02 (score 61, 0)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “launch_attack” rewrote its description, which is the text the model reads
- [security] Tool “launch_scenario” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 3083 → 3693
- [functional] New tool “list_recent_attacks”
- [cosmetic] “launch_attack” added an optional parameter “wait_seconds”
- [cosmetic] “launch_scenario” added an optional parameter “wait_seconds”

### 2026-11-01 (score 61, 0)

- [functional] Schema quality: good → excellent
- [cosmetic] “list_attacks” added an optional parameter “demo_only”
- [cosmetic] “list_scenarios” added an optional parameter “demo_only”

### 2026-10-31 (score 61, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-29 (score 60, +1)

No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-27 (score 59, +1)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “get_attack_evidence” rewrote its description, which is the text the model reads

### 2026-10-26 (score 58, 0)

- [functional improvement] Stability: unverified → 0.03

## MCP tools (12)

### `list_attacks` (~582 tokens)

Browse Mitigant's attack actions -- atomic tests that each emulate one attacker technique -- that you can launch on their own against AWS, Azure or GCP. Currently 111 attack actions (AWS 49, Azure 36, GCP 26). Returns each action's attackName (show this to the user) and attackType (an opaque id -- pass this, not attackName, to get_attack_details or launch_attack), what it does, its impact, the MITRE ATT&CK technique it maps to, and its orchestration type (PROVISIONED or INLINE -- see orchestration_filter for what these mean). Optionally filter by cloud service (S3, IAM, ...), category, or orchestration type. Some attack actions run only as steps inside a scenario and appear via list_scenarios / get_scenario_details, not here. Start here to find an attack action to run.

Input parameters:

- `category_filter` (string): Optional: only show attacks in this category. Category names vary by cloud_service and the set is not fixed, so do NOT guess one -- a guessed category simply returns an empty list. Call this tool wit…
- `cloud_service` (string, required): Which cloud provider's attack catalog to list
- `demo_only` (boolean): Optional: when true, only list attacks that can be launched on a demo account. Every returned attack carries an 'allowedOnDemo' field; on a demo account an attack with allowedOnDemo:false is rejected…
- `orchestration_filter` (string): Optional: PROVISIONED attacks create their own target resources, attack them, and delete them -- they do not target your existing infrastructure (they may still read or use existing resources along t…
- `service_filter` (string): Optional: only show attacks targeting this cloud service/resource type. Valid values are per cloud_service and not interchangeable (e.g. AWS object storage is 'S3', GCP's is 'CLOUDSTORAGE', Azure's i…

### `get_attack_details` (~164 tokens)

Full description, impact, MITRE mapping, and orchestration type (PROVISIONED or INLINE -- PROVISIONED attacks create and destroy their own target rather than targeting your existing infrastructure (they may still read or use existing resources along the way), so they're the lower-risk, production-viable choice; INLINE attacks find and attack an existing resource in the account) for one attack, by the action key from list_attacks. Result includes attackName (show this to the user) alongside the attackType you passed in (an opaque id, not for display).

Input parameters:

- `action_key` (string, required): The attack's attackType value (an opaque id, e.g. IAM_CREATE_USER -- not attackName) from list_attacks
- `cloud_service` (string, required)

### `launch_attack` (~363 tokens)

Run an attack against a cloud account connected to Mitigant. Returns the result if it finishes within wait_seconds (default 20); otherwise it returns at once with the attackId and status RUNNING while the attack keeps running -- then poll get_attack_status with that attackId, and never launch it again (that would start a second attack). This performs real actions on real cloud infrastructure -- it is not a simulation. Confirm with the user before calling: if their request could match more than one attack in list_attacks (similar names, or an underspecified description like "the security group attack"), show them the matching candidates with their names and descriptions and have them pick one -- don't guess which attack they meant.

Input parameters:

- `account_no` (string, required): Target account identifier -- AWS account number, Azure subscription ID, or GCP project ID
- `action_key` (string, required): The attack's attackType value to launch (an opaque id, not attackName) -- from list_attacks or get_attack_details
- `cloud_service` (string, required)
- `region` (string): Optional: the region to run the attack in (e.g. us-east-1, eu-west-3). Omit to use the account's default region (the defaultRegion from list_cloud_accounts); passing a region here does not change the…
- `wait_seconds` (integer): Optional: how many seconds to wait for it to finish before returning (default 20). If it has not finished by then the call returns immediately with the attackId and status RUNNING while it keeps runn…

### `list_cloud_accounts` (~214 tokens)

List the cloud accounts available for attack emulation -- any account not listed here cannot be attacked, so check this before guessing an account_no for launch_attack. An empty result means no accounts are onboarded for attack emulation (for that cloud, or at all), not a failure -- the account may still exist in Mitigant for other purposes (e.g. posture scanning) without being eligible here. Each result's accountNo is already the value launch_attack expects; accountName is for display to the user. defaultRegion is the region attacks against that account run in by default (and where their evidence is collected); it can be overridden per attack request, but unless you do, actions target that region. State it when telling the user where an attack will run.

Input parameters:

- `cloud_service` (string): Optional: only list accounts for this cloud provider (AWS, AZURE, or GCP). Omit the field entirely to list accounts across all three; an empty string is tolerated and treated the same as omitting.

### `list_scenarios` (~238 tokens)

List Mitigant's attack scenarios -- multi-step chains that combine several attack actions run in sequence, so treat a scenario as having the combined blast radius of every step. Currently 45 scenarios (AWS 26, Azure 12, GCP 7). Returns each scenario's scenarioName (show this to the user) and scenarioKey (an opaque id -- pass this, not scenarioName, to get_scenario_details or launch_scenario), plus description, impact, and the step-by-step composition (each attack action's name, service, MITRE mapping, and impact). Use this to find a multi-step chain to run; use list_attacks instead for a single attack action.

Input parameters:

- `cloud_service` (string, required): Which cloud provider's scenario catalog to list
- `demo_only` (boolean): Optional: when true, only list scenarios that can be launched on a demo account. Each scenario carries an 'allowedOnDemo' field (a scenario is allowed only when every step is); on a demo account a sc…

### `get_scenario_details` (~113 tokens)

Full details for one attack scenario -- description, impact, and the step-by-step composition, by the scenario key from list_scenarios. A scenario runs several attacks in sequence; this returns every step, not just the first. Result includes scenarioName (show this to the user) alongside the scenarioKey you passed in (an opaque id, not for display).

Input parameters:

- `cloud_service` (string, required)
- `scenario_key` (string, required): The scenario's key (an opaque id) from list_scenarios

### `launch_scenario` (~367 tokens)

Run a multi-step attack chain against a cloud account connected to Mitigant. Returns the result if every step finishes within wait_seconds (default 20); a multi-step scenario usually takes longer, so expect it to return at once with the attackId and status RUNNING while it keeps running -- then poll get_attack_status with that attackId, and never launch it again (that would start a second scenario). This performs real actions on real cloud infrastructure, as several attacks in sequence -- it is not a simulation, and its blast radius is the combined blast radius of every step. Confirm with the user before calling: if their request could match more than one scenario in list_scenarios, show them the matching candidates with their names and descriptions and have them pick one -- don't guess which scenario they meant.

Input parameters:

- `account_no` (string, required): Target account identifier -- AWS account number, Azure subscription ID, or GCP project ID
- `cloud_service` (string, required)
- `region` (string): Optional: the region to run the scenario in (e.g. us-east-1, eu-west-3). Omit to use the account's default region (the defaultRegion from list_cloud_accounts); passing a region here does not change t…
- `scenario_key` (string, required): The scenario's key to launch (an opaque id) -- from list_scenarios or get_scenario_details
- `wait_seconds` (integer): Optional: how many seconds to wait for it to finish before returning (default 20). If it has not finished by then the call returns immediately with the attackId and status RUNNING while it keeps runn…

### `get_attack_status` (~159 tokens)

Get the current report for a previously launched attack, including its clean-up state. Returns the attack report plus a 'cleanup' summary with cleanUpComplete and a plain-language statement. Only tell the user the account is back to its pre-attack state when cleanup.cleanUpComplete is true -- while anything is pending or failed, clean-up is not done, so report it as in progress and check again rather than implying all-clear. A pending clean-up is usually the DELIBERATE inspection window, not a stall: read cleanup.statement and relay it, and poll no faster than that -- a few minutes -- rather than reporting a fault.

Input parameters:

- `attack_id` (string, required): The attackId returned by a previous launch_attack / launch_scenario call

### `list_recent_attacks` (~174 tokens)

List your own recent attack and scenario runs for a cloud account, most recent first, each with its attackId and status. Use this to recover an attackId you no longer have -- for example when a launch_attack / launch_scenario call's connection dropped before it returned, or to check whether a long-running scenario is still running or has failed -- then pass the attackId to get_attack_status, get_attack_evidence or recover_attack. Shows only your own runs, not other users' activity on the account.

Input parameters:

- `account_no` (string, required): Target account identifier -- AWS account number, Azure subscription ID, or GCP project ID
- `cloud_service` (string, required)
- `limit` (integer): Optional: how many recent runs to return (most recent first). Defaults to 20, max 100.

### `get_context` (~118 tokens)

Check this account's context before planning or launching: whether it is a Mitigant DEMO account and what that allows. Call this first on a new connection. If isDemo is true, every attack or scenario with allowedOnDemo=false WILL be rejected at launch -- treat those as not runnable and don't attempt them; use list_attacks' allowedOnDemo field (or list_scenarios demo_only:true) to pick ones that run. Returns no account/org identity, just the demo status, what you can do, and how to upgrade.

### `clean_up_attack` (~208 tokens)

Clean up a previously launched attack, restoring the cloud resources it changed back to their pre-attack state. Clean-up is normally AUTOMATIC after a short, deliberate inspection window (so the team can verify the attack and collect evidence first); calling this kicks it off immediately rather than waiting out that window. It is NOT a fix for a stall, and it ends that window early -- removing the attack's artifacts before the team may have finished inspecting them -- so only use it when the user explicitly wants the account restored now. This triggers clean-up and returns immediately -- clean-up runs in the background, so a success here means the request was accepted, not that clean-up is done. Confirm the account is actually restored by polling get_attack_status until cleanup.cleanUpComplete is true; do not tell the user it is restored based on this call alone.

Input parameters:

- `attack_id` (string, required): The attackId returned by a previous launch_attack / launch_scenario call
- `cloud_service` (string, required)

### `get_attack_evidence` (~204 tokens)

Get the evidence Mitigant collected for a previously launched attack -- what the account's own logging (CloudTrail, GuardDuty) recorded about it. Returns an 'evidence' summary (counts, sources, and a plain-language statement) plus the raw records, each with an evidenceUrl that opens the matching console entry. Use it to show the user what their defenses saw, especially during the clean-up inspection window. Important: an empty or pending result shortly after an attack is normal -- logging delivery lags by minutes, and evidence usually appears within a few minutes -- and an attack whose purpose is to disable logging is expected to leave none, so never report an empty result as the attack leaving no trace; re-check about every minute or two, for up to 30 minutes after the attack, and not more often. Read evidence.statement and relay it.

Input parameters:

- `attack_id` (string, required): The attackId returned by a previous launch_attack / launch_scenario call

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/mitigant-mitigant-mcp/mcp#diagnostics

## Score history

- 2026-11-05: 63
- 2026-11-04: 62
- 2026-11-03: 62
- 2026-11-02: 61
- 2026-11-01: 61
- 2026-10-31: 61
- 2026-10-30: 60
- 2026-10-29: 60
- 2026-10-28: 59
- 2026-10-27: 59
- 2026-10-26: 58
- 2026-10-25: 58

## Common questions

### What is the Mitigant MCP server?

Mitigant is an MCP server listed in the public MCP registry as io.github.mitigant/mitigant-mcp. Run real, auto-recovered cloud attacks on AWS, Azure and GCP to test your defenses. This page covers its hosted endpoint (https://mcp.mitigant.io/mcp).

### Is the Mitigant MCP server safe to use?

Mitigant scores 63 out of 100 on VerifyMCP. 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 Mitigant MCP server expose?

Mitigant exposes 12 tools: list_attacks, get_attack_details, launch_attack, list_cloud_accounts, list_scenarios, and 7 more. Their descriptions and schemas cost roughly 2,904 tokens of context every time the server is loaded.

### Does the Mitigant MCP server require authentication?

No. We connected to Mitigant without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the Mitigant MCP server still maintained?

Mitigant is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://mcp.mitigant.io/mcp
- Authorisation metadata: https://mcp.mitigant.io/.well-known/oauth-protected-resource/mcp
- Repository: https://github.com/mitigant/mitigant-external-api
- Website: https://mitigant.io/mcp
- Changelog RSS feed: https://verifymcp.io/servers/mitigant-mitigant-mcp/mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/mitigant-mitigant-mcp/mcp.json
- HTML version of this page: https://verifymcp.io/servers/mitigant-mitigant-mcp/mcp