Skip to main content
Glama

Mitigant

by io.github.mitigant
OverviewDiscussionsAdmin

list_attacks

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.

Input Schema

NameRequiredDescriptionDefault
cloud_serviceYesWhich cloud provider's attack catalog to list
service_filterNoOptional: 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_filterNoOptional: 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_filterNoOptional: 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.

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?

Goes well beyond the readOnly/destructive annotations: enumerates the returned fields, warns that attackType is an opaque id and attackName is display-only, notes that unfiltered listing is cheap, and flags that filter values vary per cloud and may silently return empty lists. It also discloses the PROVISIONED vs INLINE risk distinction.

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?

Front-loads the core definition and purpose, with the counts and return fields following. Dense but nearly every clause carries information; the parenthetical about orchestration types deferring to the schema is marginally redundant.

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?

No output schema exists, and the description compensates by naming the fields returned (attackName, attackType, description, impact, MITRE technique, orchestration type). Together with the filter caveats and the routing to launch/describe siblings, an agent has everything needed to call it correctly.

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 coverage is already 100%, so the schema documents all four parameters including the enum. The description adds only light framing ('see orchestration_filter for what these mean', 'filter by cloud service (S3, IAM, ...)'), and its phrasing of cloud-provider filtering as 'optional' is slightly at odds with the required cloud_service parameter. Baseline 3.

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 and resource ('Browse Mitigant's attack actions -- atomic tests that each emulate one attacker technique') and quantifies scope with real counts per cloud. It also distinguishes itself from list_scenarios / get_scenario_details by noting that some attacks appear only as scenario steps.

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

Usage Guidelines5/5

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

Explicitly says 'Start here to find an attack action to run' and routes the agent onward: pass attackType (not attackName) to get_attack_details or launch_attack. It also names the alternative path (list_scenarios / get_scenario_details) for attacks that are not listed here.

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

All Mitigant toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources