Skip to main content
Glama
aws-security-mcp

aws-security-mcp

by jowhee327

scan_group

Runs predefined security scanner groups for specific compliance or defense scenarios, enabling read-only multi-account AWS organization scans.

Instructions

Run a predefined group of security scanners for a specific scenario (e.g., MLPS compliance, network defense). Read-only. Supports multi-account org scanning.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "group": "<group>"
    },
    "name": "scan_group"
  }
}

Input Schema

NameRequiredDescriptionDefault
langNoReport language (default: zh)
groupYesScan group ID: mlps3_precheck, hw_defense, exposure, data_encryption, least_privilege, log_integrity, disaster_recovery, idle_resources, tag_compliance, new_account_baseline, container_security, aggregation
regionNoAWS region to scan (default: server region)
org_modeNoEnable multi-account scanning via AWS Organizations
providerNoCloud provider to scan (default: aws). With huaweicloud, `region` is a Huawei Cloud region ID (e.g. cn-north-4); omit it or pass "all" to scan every region project of the account. Huawei Cloud Phase 1 is single-account (org_mode falls back to the current account with a warning). With alicloud (EXPERIMENTAL — not yet validated against a live account), region is an Alibaba Cloud region ID (e.g. cn-hangzhou); omit or "all" to scan every region; single-account only in this phase. With azure (EXPERIMENTAL — not yet validated against a live account), the China cloud (21Vianet) is the default; set AZURE_CLOUD=global for public cloud. region is an Azure subscription ID; omit or "all" to scan every visible subscription.
role_nameNoIAM role name to assume in child accounts (default: AWSSecurityMCPAudit)
account_idsNoSpecific account IDs to scan (default: all org accounts)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.10.0
    • changedInput schema / properties / provider / description
      Previous value: -"Cloud provider to scan (default: aws). With huaweicloud, `region` is a Huawei Cloud region ID (e.g. cn-north-4); omit it or pass \"all\" to scan every region project of the account. Huawei Cloud Phase 1 is single-account (org_mode falls back to the current account with a warning)."New value: +"Cloud provider to scan (default: aws). With huaweicloud, `region` is a Huawei Cloud region ID (e.g. cn-north-4); omit it or pass \"all\" to scan every region project of the account. Huawei Cloud Phase 1 is single-account (org_mode falls back to the current account with a warning). With alicloud (EXPERIMENTAL — not yet validated against a live account), region is an Alibaba Cloud region ID (e.g. cn-hangzhou); omit or \"all\" to scan every region; single-account only in this phase. With azure (EXPERIMENTAL — not yet validated against a live account), the China cloud (21Vianet) is the default; set AZURE_CLOUD=global for public cloud. region is an Azure subscription ID; omit or \"all\" to scan every visible subscription."
    • changedInput schema / properties / provider / enum
      Previous value: -[
      -  "aws",
      -  "huaweicloud"
      -]New value: +[
      +  "aws",
      +  "huaweicloud",
      +  "alicloud",
      +  "azure"
      +]
  2. Changed1 schema field changedv0.9.0
    • addedInput schema / properties / provider
      Added value: +{
      +  "description": "Cloud provider to scan (default: aws). With huaweicloud, `region` is a Huawei Cloud region ID (e.g. cn-north-4); omit it or pass \"all\" to scan every region project of the account. Huawei Cloud Phase 1 is single-account (org_mode falls back to the current account with a warning).",
      +  "enum": [
      +    "aws",
      +    "huaweicloud"
      +  ],
      +  "type": "string"
      +}
  3. Changed1 schema field changedv0.8.0
    • changedInput schema / properties / group / description
      Previous value: -"Scan group ID: mlps3_precheck, hw_defense, exposure, data_encryption, least_privilege, log_integrity, disaster_recovery, idle_resources, tag_compliance, new_account_baseline, aggregation"New value: +"Scan group ID: mlps3_precheck, hw_defense, exposure, data_encryption, least_privilege, log_integrity, disaster_recovery, idle_resources, tag_compliance, new_account_baseline, container_security, aggregation"
  4. First observedv0.7.6

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description carries the full burden; it does add the key safety claim 'Read-only' and notes multi-account org scanning, which an agent could not otherwise know. However, it says nothing about runtime/duration, whether findings are persisted or must be saved via save_results, or any throttling or permission prerequisites for cross-account role assumption.

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?

Three short sentences, front-loaded with the action and scenario, then the read-only guarantee, then the org capability. Nothing is redundant, though the middle and final sentences are terse enough to feel like tags rather than explanation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, multi-cloud scanning tool with no annotations and no output schema, the description covers intent and safety but leaves the return shape (findings list vs. report artifact) and follow-up flow (e.g., generate_report/save_results) unspecified. Adequate to select the tool, thin for invoking it confidently at scale.

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 100% and the parameter descriptions are unusually rich (group enum values, provider/region semantics, org_mode fallbacks), so the schema does the heavy lifting. The description only gestures at 'group' and org scanning, adding no syntax or format detail beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb ('Run') and resource ('predefined group of security scanners') scoped to a scenario such as MLPS compliance or network defense. It is distinguishable from single-scanner siblings like scan_public_access_verify, though it never explicitly contrasts itself with the closely related scan_all or scan_and_report.

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

Usage Guidelines3/5

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

The scenario framing implies when to reach for this tool (bundled compliance/defense checks rather than one-off scans), but there is no explicit guidance on when to prefer scan_all, a single scan_* tool, or scan_and_report. It also omits that group IDs must be discovered via list_groups.

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