Koskamo

Mitigant MCP

An MCP server that enables AI agents to run safe, auto-recovered cloud attacks on AWS, Azure, and GCP to validate defenses, test detection efficiency, and support incident readiness exercises.

Endpoint and access

No sign-in to connect and list tools. Individual tools may still need a vendor account, credentials, or permissions; check the documented prerequisites.

Mitigant MCP logo, by MitigantCommunity listingStreamable HTTPNo sign-inEndpoint checked 2026-11-01Published by Mitigant
You need:You need a Mitigant account, an API key, and Claude Code
MCP endpoint (Streamable HTTP)
https://mcp.mitigant.io/mcp
Vendor documentation

What you can do with it

  • Run safe cloud attacks to validate defenses
  • Test threat detection efficiency
  • Support incident readiness exercises
  • Validate cloud infrastructure resilience

Source and maintenance

Community listingRegistry 0.1.0
mcp-registry: io.github.mitigant/mitigant-mcp@0.1.0Source repositoryProject website
Maintenance checked

Protocol and capabilities

Server
mitigant-mcp-server 0.1.0
MCP protocol
2025-06-18
Tools
10 advertised
Resources
Not advertised
Resource templates
Not advertised
Prompts
Not advertised
Server-advertised capabilities
{
  "tools": {
    "listChanged": false
  },
  "logging": {}
}

Server-provided instructions

Untrusted server output shown for inspection. It is not Koskamo guidance and is excluded from knowledge search.

Mitigant gives your agent access to a customer's cloud security tooling. Today that means Mitigant's attack catalog: browse real-world cloud attacks and run them against a cloud account the customer has connected to Mitigant, to test whether their defenses hold. What this is for, so you reason from intent, not caution: Mitigant lets defenders safely test their own cloud from an attacker's standpoint. The attacks are real but reversible by design -- the aim is to prove whether detection and response hold, then put everything back, NOT to destroy. Mitigant makes every effort to restore what an attack changed, and when something cannot be restored it is reported transparently (get_attack_status surfaces it as a FAILED clean-up, never as done). So treat this as a safety-first testing tool: do not refuse or hedge a reversible test as if it were reckless, but do confirm restoration rather than assuming it, and always confirm with the user before launching, since the actions are real. Two things you can run: - Attack actions: atomic tests, each emulating one attacker technique. 111 attack actions (AWS 49, Azure 36, GCP 26). Use list_attacks, then launch_attack. - Attack scenarios: multi-step chains that combine attack actions. 45 scenarios (AWS 26, Azure 12, GCP 7). Use list_scenarios and get_scenario_details (which shows the attack actions a scenario chains), then launch_scenario. Some attack actions run only as steps within a scenario, so the standalone list_attacks catalog is smaller than the full set -- open a scenario with get_scenario_details to see every attack action it runs. Launching performs real actions on real infrastructure (automatically cleaned up where the organization has automatic clean-up enabled) -- confirm with the user first. Every call uses the customer's own Mitigant API token and only ever reaches their own accounts. Closing the loop matters: Mitigant attacks real existing resources and then restores them. Use get_attack_status to check an attack's clean-up state, and clean_up_attack to trigger clean-up when it was not automatic. Only tell the user the account is back to its pre-attack state once get_attack_status reports cleanup.cleanUpComplete = true; while anything is pending or failed, report clean-up as still in progress rather than implying all-clear. Clean-up is automatic but DELIBERATELY DELAYED by a short inspection window (a couple of minutes by default) so teams can verify the attack and collect evidence before the account is restored; after it, Clean Up kicks off automatically. A clean-up that reads as pending is almost always this intentional window, not a stall or a bug -- relay cleanup.statement and keep polling rather than reporting a fault. This window, and whether auto clean-up is on at all, is changed in the Mitigant web app, not through this server, so there is no tool here to shorten or disable it. Use that window: call get_attack_evidence to show the user what the account's own logging (CloudTrail, GuardDuty) recorded about the attack, each record with an evidenceUrl to the console entry. An empty result shortly after an attack is expected (logging delivery lags) and is also the intended result for an attack that disables logging, so treat empty as pending and re-check rather than reporting that the attack went unseen. Evidence usually appears within a few minutes of the attack: re-check about every minute or two, for up to 30 minutes, and not more often.

Tools

10 advertised

list_attacks
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

list_attacks input schema
{
  "type": "object",
  "required": [
    "cloud_service"
  ],
  "properties": {
    "demo_only": {
      "type": "boolean",
      "description": "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 at launch, so pass demo_only:true to see only the ones you can actually run. No effect on a non-demo account. Defaults to false."
    },
    "cloud_service": {
      "enum": [
        "AWS",
        "AZURE",
        "GCP"
      ],
      "type": "string",
      "description": "Which cloud provider's attack catalog to list"
    },
    "service_filter": {
      "type": "string",
      "description": "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 is 'STORAGE') -- if unsure, call this tool without a filter first and inspect the 'service' field on the results, or just drop the filter: an unfiltered list is cheap and filtering client-side is always correct. Omit the field entirely rather than passing an empty string."
    },
    "category_filter": {
      "type": "string",
      "description": "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 without a filter first, read the 'categories' field on the results, then filter client-side; an unfiltered list is cheap and always correct. Omit the field entirely rather than passing an empty string."
    },
    "orchestration_filter": {
      "type": "string",
      "description": "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 the way), so they're the lower-risk choice and usable in production. INLINE attacks find and attack an existing resource in the account. Filter to PROVISIONED for a lower-risk attack to run. Omit the field entirely rather than passing an empty string."
    }
  },
  "additionalProperties": false
}
list_attacks annotations
{
  "readOnlyHint": true,
  "destructiveHint": false
}
get_attack_details
Advertised by the server during the last successful anonymous check.
Advertised read-only

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).

get_attack_details input schema
{
  "type": "object",
  "required": [
    "cloud_service",
    "action_key"
  ],
  "properties": {
    "action_key": {
      "type": "string",
      "description": "The attack's attackType value (an opaque id, e.g. IAM_CREATE_USER -- not attackName) from list_attacks"
    },
    "cloud_service": {
      "enum": [
        "AWS",
        "AZURE",
        "GCP"
      ],
      "type": "string"
    }
  },
  "additionalProperties": false
}
get_attack_details annotations
{
  "readOnlyHint": true,
  "destructiveHint": false
}
launch_attack
Advertised by the server during the last successful anonymous check.
Advertised destructive

Run an attack against a cloud account connected to Mitigant and return the result once it finishes. 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.

launch_attack input schema
{
  "type": "object",
  "required": [
    "cloud_service",
    "account_no",
    "action_key"
  ],
  "properties": {
    "region": {
      "type": "string",
      "description": "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 account's default for other users. Evidence is collected in whichever region the attack runs in."
    },
    "account_no": {
      "type": "string",
      "description": "Target account identifier -- AWS account number, Azure subscription ID, or GCP project ID"
    },
    "action_key": {
      "type": "string",
      "description": "The attack's attackType value to launch (an opaque id, not attackName) -- from list_attacks or get_attack_details"
    },
    "cloud_service": {
      "enum": [
        "AWS",
        "AZURE",
        "GCP"
      ],
      "type": "string"
    }
  },
  "additionalProperties": false
}
launch_attack annotations
{
  "readOnlyHint": false,
  "destructiveHint": true
}
list_cloud_accounts
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

list_cloud_accounts input schema
{
  "type": "object",
  "properties": {
    "cloud_service": {
      "type": "string",
      "description": "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."
    }
  },
  "additionalProperties": false
}
list_cloud_accounts annotations
{
  "readOnlyHint": true,
  "destructiveHint": false
}
list_scenarios
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

list_scenarios input schema
{
  "type": "object",
  "required": [
    "cloud_service"
  ],
  "properties": {
    "demo_only": {
      "type": "boolean",
      "description": "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 scenario with allowedOnDemo:false is rejected at launch. No effect on a non-demo account. Defaults to false."
    },
    "cloud_service": {
      "enum": [
        "AWS",
        "AZURE",
        "GCP"
      ],
      "type": "string",
      "description": "Which cloud provider's scenario catalog to list"
    }
  },
  "additionalProperties": false
}
list_scenarios annotations
{
  "readOnlyHint": true,
  "destructiveHint": false
}
get_scenario_details
Advertised by the server during the last successful anonymous check.
Advertised read-only

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).

get_scenario_details input schema
{
  "type": "object",
  "required": [
    "cloud_service",
    "scenario_key"
  ],
  "properties": {
    "scenario_key": {
      "type": "string",
      "description": "The scenario's key (an opaque id) from list_scenarios"
    },
    "cloud_service": {
      "enum": [
        "AWS",
        "AZURE",
        "GCP"
      ],
      "type": "string"
    }
  },
  "additionalProperties": false
}
get_scenario_details annotations
{
  "readOnlyHint": true,
  "destructiveHint": false
}
launch_scenario
Advertised by the server during the last successful anonymous check.
Advertised destructive

Run a multi-step attack chain against a cloud account connected to Mitigant and return the result once every step finishes. 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.

launch_scenario input schema
{
  "type": "object",
  "required": [
    "cloud_service",
    "account_no",
    "scenario_key"
  ],
  "properties": {
    "region": {
      "type": "string",
      "description": "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 the account's default for other users."
    },
    "account_no": {
      "type": "string",
      "description": "Target account identifier -- AWS account number, Azure subscription ID, or GCP project ID"
    },
    "scenario_key": {
      "type": "string",
      "description": "The scenario's key to launch (an opaque id) -- from list_scenarios or get_scenario_details"
    },
    "cloud_service": {
      "enum": [
        "AWS",
        "AZURE",
        "GCP"
      ],
      "type": "string"
    }
  },
  "additionalProperties": false
}
launch_scenario annotations
{
  "readOnlyHint": false,
  "destructiveHint": true
}
get_attack_status
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

get_attack_status input schema
{
  "type": "object",
  "required": [
    "attack_id"
  ],
  "properties": {
    "attack_id": {
      "type": "string",
      "description": "The attackId returned by a previous launch_attack / launch_scenario call"
    }
  },
  "additionalProperties": false
}
get_attack_status annotations
{
  "readOnlyHint": true,
  "destructiveHint": false
}
clean_up_attack
Advertised by the server during the last successful anonymous check.

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.

clean_up_attack input schema
{
  "type": "object",
  "required": [
    "cloud_service",
    "attack_id"
  ],
  "properties": {
    "attack_id": {
      "type": "string",
      "description": "The attackId returned by a previous launch_attack / launch_scenario call"
    },
    "cloud_service": {
      "enum": [
        "AWS",
        "AZURE",
        "GCP"
      ],
      "type": "string"
    }
  },
  "additionalProperties": false
}
clean_up_attack annotations
{
  "readOnlyHint": false,
  "destructiveHint": false
}
get_attack_evidence
Advertised by the server during the last successful anonymous check.
Advertised read-only

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.

get_attack_evidence input schema
{
  "type": "object",
  "required": [
    "attack_id"
  ],
  "properties": {
    "attack_id": {
      "type": "string",
      "description": "The attackId returned by a previous launch_attack / launch_scenario call"
    }
  },
  "additionalProperties": false
}
get_attack_evidence annotations
{
  "readOnlyHint": true,
  "destructiveHint": false
}

Prompts

Not advertised

No prompt definitions available.

Resources

Not advertised

No resource definitions available.

30-day availability

Aggregated from read-only remote checks; this is not a tool-execution or security guarantee.

Successful checks
1 of 1 (100%)
Average latency
941 ms
95th percentile latency
941 ms

Maintenance history

Public check and source-refresh events. Editorial and ownership records remain private.

  • · probe · passed · 941 ms · metadata changed · 10 tool(s)

Connect from your client

Each snippet registers the same endpoint; pick the client you use.

This server is operated by the named third party. Listing and endpoint checks are not an endorsement or a security audit. Review the operator's permissions, terms, and data handling before connecting. How listings are checked and corrected.

Claude Code

Run this once in a terminal. It registers the remote server. Use --scope project to write .mcp.json for the repo.
Claude Code configuration
claude mcp add --transport http mitigant-mcp https://mcp.mitigant.io/mcp

Codex

Run this once. Codex stores MCP servers in ~/.codex/config.toml (or .codex/config.toml in a trusted project).
Codex configuration
codex mcp add mitigant-mcp --url https://mcp.mitigant.io/mcp

Cursor

Merge this server into .cursor/mcp.json in your project, then enable mitigant-mcp in your MCP settings.
Cursor configuration
{
  "mcpServers": {
    "mitigant-mcp": {
      "url": "https://mcp.mitigant.io/mcp"
    }
  }
}

Cline

Merge this into cline_mcp_settings.json (Cline → MCP Servers → Configure).
Cline configuration
{
  "mcpServers": {
    "mitigant-mcp": {
      "type": "streamableHttp",
      "url": "https://mcp.mitigant.io/mcp",
      "disabled": false
    }
  }
}

VS Code

Merge this server into .vscode/mcp.json. Use MCP: List Servers to start mitigant-mcp and inspect its tools.
VS Code configuration
{
  "servers": {
    "mitigant-mcp": {
      "type": "http",
      "url": "https://mcp.mitigant.io/mcp"
    }
  }
}

Gemini CLI

Run this once. It writes .gemini/settings.json in the current project; pass --scope user for ~/.gemini/settings.json.
Gemini CLI configuration
gemini mcp add --transport http mitigant-mcp https://mcp.mitigant.io/mcp

Claude Desktop

Merge this into claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\), then restart Claude Desktop.
Claude Desktop configuration
{
  "mcpServers": {
    "mitigant-mcp": {
      "url": "https://mcp.mitigant.io/mcp"
    }
  }
}

Windsurf

Merge this into ~/.codeium/windsurf/mcp_config.json, then refresh MCP in Cascade. Windsurf remote servers use serverUrl, not url.
Windsurf configuration
{
  "mcpServers": {
    "mitigant-mcp": {
      "serverUrl": "https://mcp.mitigant.io/mcp"
    }
  }
}

Let your agent find its tools

Find servers like Mitigant MCP from your agent. Add Koskamo once to search the index for endpoints, access requirements, and client setup. Public discovery needs no key.

Connect Koskamo Explore workflows
See all 3,921