Run real, auto-recovered cloud attacks on AWS, Azure and GCP to test your defenses.
Scored across 10 tools
Each tool has a clearly distinct role: discovery (list_attacks, list_scenarios, list_cloud_accounts), static details (get_attack_details, get_scenario_details), execution (launch_attack, launch_scenario), and post-launch state (get_attack_status, get_attack_evidence, clean_up_attack). The attack-vs-scenario split is consistently mirrored across list/get/launch tools, and descriptions emphasize boundaries such as status vs details vs evidence.
All tool names use snake_case with a predictable verb_noun or verb_phrase structure: list_*, get_*, launch_*, clean_up_*. There are no mixed conventions or vague names.
Ten tools is well-scoped for a cloud attack emulation server, covering discovery, details, launch, status, evidence, cleanup, and account selection without feeling bloated or thin.
The atomic attack lifecycle is thoroughly covered: list, inspect, launch, check status, collect evidence, and clean up. However, scenarios have list/get/launch tools but no dedicated scenario-level status, evidence, or cleanup tool, leaving a notable post-launch gap for multi-step chains.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| attack_id | Yes | The attackId returned by a previous launch_attack / launch_scenario call | |
| cloud_service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only say readOnlyHint=false and destructiveHint=false, but the description adds the critical async semantics: the call returns immediately, cleanup runs in the background, and success means only that the request was accepted. It also warns that this ends the inspection window early and removes artifacts, which is exactly the behavioral context an agent needs beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded: the core action comes first, followed by safety conditions and the return-value caveat. It is a bit long and restates the inspection-window rationale more than once, but every sentence ultimately supports correct use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an async mutation with no output schema, the description covers what is needed: what it does, when it should and should not be used, that it is asynchronous, and how to verify completion via get_attack_status. Nothing important is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, and the description does not discuss either parameter. attack_id is documented in the schema, but cloud_service has no description in either place beyond its enum values. The description adds no meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Clean up a previously launched attack, restoring the cloud resources it changed back to their pre-attack state.' That clearly distinguishes it from the launch_* and get_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit use conditions ('only use it when the user explicitly wants the account restored now'), explains the default automatic behavior and why this call overrides it, and rules out misuse ('It is NOT a fix for a stall').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| action_key | Yes | The attack's attackType value (an opaque id, e.g. IAM_CREATE_USER -- not attackName) from list_attacks | |
| cloud_service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnly/destructive annotations already cover safety, and the description adds substantive context the annotations don't: the PROVISIONED vs INLINE distinction with a risk explanation that materially affects interpretation of results. It doesn't cover error behavior on an invalid key or cloud_service mismatch, so it isn't fully complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded, but the single sentence is overloaded with deeply nested parentheticals explaining orchestration type, which makes it hard to parse. The content earns its place, but the structure could be split into separate sentences or bullets.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates what the result contains (attackName, attackType) and explains the orchestration-type field. Gaps remain around invalid-key behavior and whether cloud_service must match the value used in list_attacks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, but the description compensates by explaining that action_key is the opaque attackType id rather than the human-readable attackName, and that the result echoes back both values. The cloud_service enum is self-explanatory and needs no elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: it returns the full description, impact, MITRE mapping, and orchestration type for one attack, keyed by action_key. It clearly distinguishes itself from list_attacks (the source of the key) and implicitly from get_attack_status/get_attack_evidence by declaring which fields it returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent where the required action_key comes from ('the action key from list_attacks') and warns that the returned attackType is an opaque id, not for display, while attackName should be shown to the user. There's no explicit when-not or statement of alternatives such as get_attack_evidence, but the call context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 result shortly after an attack is normal -- logging delivery lags by 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 instead. Read evidence.statement and relay it.
| Name | Required | Description | Default |
|---|---|---|---|
| attack_id | Yes | The attackId returned by a previous launch_attack / launch_scenario call |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only safety, and the description adds substantial context beyond them: the return shape (counts, sources, plain-language statement, raw records with evidenceUrl), a delivery-lag caveat, and a specific adversarial case where empty is expected. The warning against misinterpreting empty results is exactly the kind of behavioral detail structured fields cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then return shape, then usage, then the critical caveat. No sentence is filler — even the 'relay evidence.statement' instruction changes agent behavior. Dense but appropriately so for the number of behavioral warnings it must convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must describe returns, and it does — summary object, raw records, evidenceUrl semantics. Combined with the empty-result interpretation guidance, an agent has everything needed to call and correctly report on this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single attack_id parameter already documents that it comes from launch_attack / launch_scenario, so the description adds little parameter-level meaning. Baseline 3 is appropriate when the schema fully carries this load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
A specific verb and resource — evidence Mitigant collected for a previously launched attack — scoped further by naming the data source (the account's own CloudTrail/GuardDuty logging). That framing clearly separates it from get_attack_details and get_attack_status, which concern the attack object rather than observed telemetry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it: to show the user what their defenses saw, especially during the clean-up window. It also gives a strong do-not (never report an empty result as the attack leaving no trace, re-check instead). It does not name an alternative sibling for adjacent needs, which is the only thing keeping this from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| attack_id | Yes | The attackId returned by a previous launch_attack / launch_scenario call |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description goes well beyond that: it names the field to gate the all-clear on (cleanUpComplete), explains that pending or failed clean-up is not a failure state, discloses that a pending window is often the deliberate inspection window, and gives a polling cadence. That is exactly the operational context annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, and each following sentence carries a distinct instruction: return shape, gating condition, and polling guidance. It is on the longer side for a one-parameter read tool, and the clean-up caution is repeated in slightly different words, but nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must cover return values, and it does: the attack report plus a cleanup summary with cleanUpComplete and a plain-language statement. An agent knows what to read and how to interpret the key flag. It stops short of describing the rest of the attack report's contents, which is the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter attack_id has 100% schema description coverage, including where the value comes from ('returned by a previous launch_attack call'), so the description's constraint isn't compensating for anything missing. The description adds no new parameter information beyond the schema. A baseline 3 is appropriate when the schema already does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Get the current report for a previously launched attack') and scopes it further by naming the clean-up state that this tool adds. That meaningfully separates it from siblings like get_attack_evidence and clean_up_attack, but the description never explicitly contrasts it with get_attack_details, which an agent could easily confuse it with. Clear purpose, incomplete sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to report clean-up as complete ('Only ... when cleanup.cleanUpComplete is true') and when not to ('while anything is pending or failed ... report it as in progress'). It also tells the agent to poll 'no faster than ... a few minutes' and to read cleanup.statement rather than flagging a fault. What it lacks is a pointer to the sibling tool that actually starts clean-up (clean_up_attack), so an agent seeing a stuck clean-up has no explicit next step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| scenario_key | Yes | The scenario's key (an opaque id) from list_scenarios | |
| cloud_service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds that all steps are returned and that scenarioName should be shown while scenarioKey is opaque. It does not discuss errors, missing keys, or permission/rate-limit behavior, so it is not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the resource and return scope, then the display caveat. Every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 gives a useful partial return map (description, impact, step-by-step composition, scenarioName). It leaves cloud_service semantics and the full return shape unaddressed, but is largely sufficient for a read-only retrieval call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; the description reinforces scenario_key's origin from list_scenarios and its opaque/display distinction, adding real meaning. The required cloud_service parameter is not explained beyond its enum in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific retrieval action for one attack scenario, including description, impact, and step-by-step composition, and pins lookup to the scenario_key from list_scenarios. The sentence 'A scenario runs several attacks in sequence; this returns every step' distinguishes it from attack-level detail tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use after list_scenarios by requiring the key from that tool, and clarifies this is for full scenario composition rather than a listing. It does not explicitly name when to prefer get_attack_details or how cloud_service affects the lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | 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 | Yes | Target account identifier -- AWS account number, Azure subscription ID, or GCP project ID | |
| action_key | Yes | The attack's attackType value to launch (an opaque id, not attackName) -- from list_attacks or get_attack_details | |
| cloud_service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, but the description adds crucial context beyond that: it performs real actions on real cloud infrastructure, is not a simulation, and is synchronous (returns once it finishes). The user-confirmation requirement is a behavioral constraint not captured by any annotation, and it directly complements the destructive flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and scope, then the safety warning, then disambiguation guidance. Every sentence earns its place; the final clause is long but carries the most important operational constraint so the density is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 says only that the result is returned on completion, without describing its shape — but sibling tools (get_attack_evidence, get_attack_status) plausibly cover retrieval. Safety, blocking behavior, and prerequisite tooling are all covered, leaving only the result payload underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% with detailed per-field descriptions (region default behavior, account identifier formats, action_key being attackType vs attackName). The description only alludes to action_key selection via list_attacks, adding little beyond what the schema already states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Run an attack against a cloud account connected to Mitigant') and its scope ('return the result once it finishes'), which distinguishes it from siblings like launch_scenario, get_attack_status, and get_attack_evidence. An agent can tell exactly what this does 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use conditions and a disambiguation procedure: confirm with the user first, and if the request could match multiple entries in list_attacks, show candidates with names and descriptions rather than guessing. It names the concrete alternative tool (list_attacks) and the failure mode ('the security group attack') it prevents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | 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 | Yes | Target account identifier -- AWS account number, Azure subscription ID, or GCP project ID | |
| scenario_key | Yes | The scenario's key to launch (an opaque id) -- from list_scenarios or get_scenario_details | |
| cloud_service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already marking this destructive and non-read-only, the description adds critical operational context: it performs real actions on real cloud infrastructure, is not a simulation, and has the combined blast radius of every step. It also adds a confirmation requirement and ambiguity-handling instructions, which are valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the tool action, then immediately states the real-world destructive impact, then gives the confirmation and scenario-selection requirement. Every sentence contributes operational value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive multi-step tool, it covers the essential warning, blast radius, confirmation behavior, and scenario selection process. It is not fully complete because there is no output schema and the description only briefly says it returns the result after every step, without describing the result shape or any cleanup path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, with region, account_no, and scenario_key already well described in the schema. The description reinforces that scenario_key comes from list_scenarios or get_scenario_details, but it does not add much parameter-level meaning beyond the schema, and cloud_service has no description in either place.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: run a multi-step attack chain against a cloud account connected to Mitigant. It clearly implies a scenario-based, multi-step operation, but it does not explicitly contrast itself with the sibling launch_attack tool, so sibling differentiation is incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives strong pre-call guidance: confirm with the user, and if the request could match multiple scenarios from list_scenarios, show candidates and have the user pick one. However, it does not explicitly say when to use launch_scenario instead of launch_attack or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| cloud_service | Yes | Which cloud provider's attack catalog to list | |
| service_filter | No | 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 | No | 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 | No | 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. |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| cloud_service | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark this as a safe read-only operation, but the description adds important behavioral context beyond that: unlisted accounts are not attackable, empty results are valid, and accounts may still exist for other purposes such as posture scanning. It also documents the defaultRegion semantics for subsequent attacks, which is not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and the launch_attack dependency. Every sentence carries operational value: empty-result interpretation, accountNo/accountName roles, and defaultRegion behavior are all relevant and not repeated elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description still explains the important returned fields: accountNo, accountName, and defaultRegion. It also covers the empty-result case and the distinction between eligibility for attack emulation and existence in Mitigant, so the agent has enough context to call and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single optional cloud_service parameter is fully documented in the schema, including enum-like allowed values and empty-string handling. The description does not add further parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: list the cloud accounts available for attack emulation. It also distinguishes this preparatory lookup from the sibling launch_attack by explaining that account_no must come from this list before launching an attack.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to check this tool before guessing an account_no for launch_attack, and explains that unlisted accounts cannot be attacked. It also clarifies that an empty result is not a failure, which prevents the agent from misinterpreting a valid empty response.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| cloud_service | Yes | Which cloud provider's scenario catalog to list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful context beyond that: scenario blast radius is cumulative across steps, the current catalog size is broken down by cloud provider, and the return values include scenarioName, scenarioKey, description, impact, and step composition. This is substantial behavioral detail for a read-only listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core distinction and usage guidance, then efficiently covers counts, return fields, ID handling, and the sibling alternative. Despite being dense, every sentence provides actionable information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still explains the returned fields clearly. Annotations cover the safety profile, the single required parameter is fully documented in the schema, and the description supplies the missing routing and return-shape context an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the enum description already states that cloud_service selects the provider catalog. The description adds value by noting the current scenario counts per provider (AWS 26, Azure 12, GCP 7), giving the agent useful expectations about the result set for each enum value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List ... attack scenarios') and immediately defines what a scenario is: a multi-step chain combining several attack actions. It explicitly distinguishes scenarios from single attacks by pointing to list_attacks, so an agent can route between the two siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance ('Use this to find a multi-step chain to run') and names the alternative ('use list_attacks instead for a single attack action'). It also clarifies downstream usage by saying scenarioKey, not scenarioName, should be passed to get_scenario_details or launch_scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
clean_up_attackget_attack_detailsget_attack_evidenceget_attack_statusget_scenario_detailslaunch_attacklaunch_scenariolist_attackslist_cloud_accountslist_scenariosThreat modeling, code/cloud/pipeline scanning, shadow-AI discovery, compliance checks and fixes.
Test your AI agents for security and safety weaknesses, and re-verify the fixes.
Threat modeling, code, API & cloud security, shadow-AI & compliance governance.
Discover exposed assets, leaked secrets, APIs & client-side vulns across your attack surface
Add one secure layer between your agents and this server.
