Prowler Cloud for Claude Code

Delete a note from a finding's triage. WARNING: This permanently removes the note and cannot be undone. Requires the `manage_scans` permission on the API key/role.

Start deleting an organization. WARNING: This is a destructive operation. It deletes the organization, its entire OU/folder hierarchy, and marks EVERY linked provider as deleted — removing their scans and findings. It cannot be undone. To detach providers without deleting them, use prowler_cloud_manage_organization_providers first. IMPORTANT: the API task this waits on only marks the organization deleted and dispatches one deletion job per linked provider; the organization row itself is removed by a follow-up job once every provider finishes, and a failure there rolls the whole deletion back. A successful call therefore means "deletion started, organization no longer visible", not "everything is gone" — report it that way, and confirm later with prowler_cloud_list_organizations. Requires the `manage_providers` permission on the API key/role. The result reports `status`: 'deletion_started' when Prowler accepted the deletion and began it, 'unknown' when it was accepted but its progress could not be read. NEVER send the deletion again on 'unknown' — use prowler_cloud_list_organizations to see whether the organization is gone.

Delete a scan configuration. WARNING: This is a destructive operation. Any providers currently attached to this configuration will fall back to the built-in default scan configuration.

Delete a provider's scan schedule. WARNING: This is a destructive operation - it stops recurring scans and resets the scan schedule to its unconfigured defaults. To temporarily stop scans instead, prefer prowler_cloud_set_scan_schedule with scan_enabled=False. Requires the `manage_scans` permission on the API key/role.

Discover the real structure of a cloud provider organization: AWS accounts and OUs, Azure subscriptions and management groups, or GCP projects and folders. Starts a discovery run (or checks an existing one when discovery_id is given) and waits up to wait_seconds for it to finish. On success it returns the discovered accounts/OUs (AWS), subscriptions/management groups (Azure) or projects/folders (GCP), each account, subscription or project with its registration state (`provider_exists`, `apply_status`, `blocked_reasons`) so you can choose what to onboard. If still running after the wait, it returns the discovery id and status — call this tool again with that discovery_id to keep waiting. IMPORTANT: requires org-level credentials to be stored first (see prowler_cloud_create_organization / prowler_cloud_update_organization). Workflow: 1. This tool 2. Review the returned accounts/subscriptions/projects 3. prowler_cloud_apply_organization_discovery with your selection Requires the `manage_providers` permission on the API key/role.

Retrieve a single alert event including its matched rule and scan.

Retrieve a single alert recipient with its confirmation status.

Retrieve an alert rule including its condition DSL and recipient emails.

Retrieve a single finding's triage state by finding UID.

Get one organization in full: attributes, linked providers, credentials status, latest discovery and the OU/management-group/folder hierarchy. The `credentials` field only reports whether org-level credentials are stored and their type — secret values are write-only and never returned. `latest_discovery` carries counts and status only; for the discovered account/project lists use prowler_cloud_discover_organization with the discovery id.

Retrieve a scan configuration including its full configuration body. The 'configuration' body follows the JSON Schema returned by prowler_cloud_get_scan_configuration_schema (one section per provider type).

Describe the keys a valid scan configuration body may set. Returns a compact, per-provider view (one section per provider type) of the configurable keys and their types/constraints. Use it to build the 'configuration' argument for prowler_cloud_create_scan_configuration or prowler_cloud_update_scan_configuration. HOW A SCAN CONFIGURATION BODY IS STRUCTURED The 'configuration' is a two-level mapping: PROVIDER TYPE -> (SETTING KEY -> VALUE). Each top-level key is a provider type ('aws', 'azure', ...); its value is that provider's settings. Example: { "aws": {"excluded_services": ["macie"], "max_ec2_instance_age_in_days": 180}, "azure": {"excluded_services": ["defender"]} } Everything is OPTIONAL and behaves as an OVERRIDE on top of Prowler's built-in defaults, never a full replacement: - Include only the provider types you want to tune; any provider type you omit keeps using its defaults. - Within a section, include only the keys you want to change; any key you omit keeps its default value at scan time. - A partial body is valid and preferred - even a single key for a single provider. You do NOT need to send every provider or every key, and you should not pad the body with defaults you are not intentionally changing. HOW TO READ EACH KEY IN THE RETURNED SCHEMA The response is `{"providers": {<provider_type>: {"description": <text>, "fields": {<key>: <spec>}}}}`. Each <spec> describes one settable key: - "type": JSON type to send - 'integer', 'number', 'boolean', 'string' or 'array'. - "description": what the setting controls. - "enum": when present, the value MUST be one of these; "minimum"/"maximum" are inclusive numeric bounds; "max_length" caps string length. - For arrays: "items_type" is the element type and "items_enum" (when present) is the closed set of allowed elements. "unique_items" (when true) means duplicate elements are rejected; "items_min_length" is the minimum length of each string element (1 means empty strings are rejected). - A missing constraint means "unconstrained"; a missing "default" means the key is unset (null) by default. Two keys recur across most providers: "excluded_checks" and "excluded_services" (lists of check / service identifiers to skip during the scan). Their values are validated against the provider's real catalog - discover valid identifiers with prowler_hub_list_checks and prowler_hub_get_provider_services. Pass `provider_type` to narrow the result to just that provider's section instead of every provider type. An unknown provider type fails with a message listing the valid ones.

Retrieve a provider's scan schedule including all per-frequency fields.

List fired alert events for the tenant.

List alert recipients and their confirmation status.

List the fired alert-event history for a single rule (newest first).

List and filter custom alert rules. IMPORTANT: returns LIGHTWEIGHT rule info without the condition DSL or recipient emails. Use prowler_cloud_get_alert_rule for the full rule.

List the notes attached to a finding's triage, newest first.

List and filter persisted finding triage rows for the tenant. Each row surfaces the triage 'id', finding_uid, check_id, status, notes_count and the owning provider. Use prowler_cloud_get_finding_triage (by finding UID) for a single finding's state, and prowler_cloud_list_finding_triage_notes to read its notes.

List cloud provider organizations registered in Prowler. IMPORTANT: returns LIGHTWEIGHT info per organization (name, type, external id, provider/node counts). Use prowler_cloud_get_organization for the hierarchy, credentials status and latest discovery.

List and filter per-tenant scan configurations. IMPORTANT: This tool returns LIGHTWEIGHT scan configuration information (id, name, attached providers summary, timestamps) WITHOUT the full configuration body. Use prowler_cloud_get_scan_configuration to fetch the complete configuration for a specific entry. Workflow: 1. Use this tool to browse existing scan configurations. 2. Use prowler_cloud_get_scan_configuration with the 'id' for the full body. 3. Use prowler_cloud_create_scan_configuration / prowler_cloud_update_scan_configuration to manage them.

List scan schedules, one per visible provider. IMPORTANT: returns LIGHTWEIGHT scan schedule info (provider_id, frequency, enabled, next/last run). Use prowler_cloud_get_scan_schedule for the full per-frequency fields.

Manually adjust which providers belong to an organization, or to one hierarchy node (OU/management group/folder) within it. IMPORTANT: prowler_cloud_apply_organization_discovery links providers automatically — use this tool only for manual adjustments. A provider can belong to at most ONE organization and ONE node; its type must match the organization's (409 conflict otherwise). Removing a provider from the organization also removes it from any node. Providers are detached, never deleted. Requires the `manage_providers` permission on the API key/role.

Re-send the confirmation email for a pending or unsubscribed recipient. SIDE EFFECT: sends an email. Requires the `manage_alerts` permission.

Set the triage status for a finding, optionally attaching a note. Requires the `manage_scans` permission on the API key/role. Workflow: 1. Use prowler_cloud_get_finding_triage to review the current state. 2. Use this tool to change status (e.g. mark a finding 'risk_accepted'). 3. Use prowler_cloud_create_finding_triage_note to add follow-up notes.

Configure or update a SINGLE provider's recurring scan schedule. Supports partial edits (e.g. pass only scan_enabled=False to pause) and returns the full resulting schedule. Cadence fields not used by the chosen frequency are cleared automatically, so switching frequency is safe. To pause instead of deleting, set scan_enabled=False. To apply one schedule to many providers or a whole group at once, use prowler_cloud_bulk_set_scan_schedules instead. Requires the `manage_scans` permission on the API key/role.

Update an alert rule. Only provided fields change. Requires the `manage_alerts` permission. Changing recipients may send new confirmation emails.

Update the body of an existing note on a finding's triage. To add a new note instead use prowler_cloud_create_finding_triage_note; to remove one use prowler_cloud_delete_finding_triage_note. Requires the `manage_scans` permission on the API key/role.

Update an organization's name or metadata, and/or create or rotate its org-level credentials. IMPORTANT: `org_type` and `external_id` are immutable after creation. With no arguments this returns the current organization unchanged. The attribute update and the credential write are separate API calls, so a rejected credential payload can leave the name/metadata change already applied. That case returns `status: 'partial'` with `updated_fields` and `credentials_error` — relay it instead of assuming nothing changed. Requires the `manage_providers` permission on the API key/role.

Update a scan configuration's name, body, and/or attached providers. IMPORTANT: `provider_ids` is a full replacement set, not additive. Omitting it leaves attachments unchanged; passing it detaches any provider not listed. Returns the stored configuration as saved, including its full body and the providers it ended up attached to - check it to confirm the resulting attachments.

Register a provider to be scanned with Prowler. This tool will register a provider in Prowler, even if the UID is wrong. If the provider is already registered, it will be updated with the new provided alias or credentials if provided. If credentials are provided, they will be added to the indicated provider, if the provider does not exist, it will be created and the credentials will be added to it. If the connection test is successful, the provider will be connected. If the connection test fails, the provider will be created but not connected. The tool always returns the provider details after its registration or update. Example Input: - AWS Static Credentials: ```json { "provider_uid": "123456789012", "provider_type": "aws", "alias": "production-aws-account", "credentials": { "aws_access_key_id": "AKIA...", "aws_secret_access_key": "...", "aws_session_token": "..." } } ``` - AWS Assume Role: ```json { "provider_uid": "987654321098", "provider_type": "aws", "alias": "staging-aws-account", "credentials": { "role_arn": "arn:aws:iam::987654321098:role/ProwlerScanRole", "external_id": "...", "aws_access_key_id": "AKIA...", # Optional "aws_secret_access_key": "...", # Optional "aws_session_token": "...", # Optional "session_duration": 3600, # Optional "role_session_name": "..." # Optional } } ``` - Azure/M365 Static Credentials: ```json { "provider_uid": "a1b2c3d4-e5f6-4a5b-8c9d-0e1f2a3b4c5d", "provider_type": "azure", "alias": "production-azure-subscription", "credentials": { "client_id": "...", "client_secret": "...", "tenant_id": "..." } } ``` - GCP Service Account Account Key: ```json { "provider_uid": "my-gcp-project-prod", "provider_type": "gcp", "alias": "production-gcp-project", "credentials": { "service_account_key": { "type": "service_account", "project_id": "...", "private_key_id": "...", "private_key": "...", "client_email": "...", } } } ``` - Kubernetes Static Credentials: ```json { "provider_uid": "prod-k8s-cluster", "provider_type": "kubernetes", "alias": "production-kubernetes-cluster", "credentials": { "kubeconfig_content": "..." } } ``` - GitHub OAuth App Token: ```json { "provider_uid": "my-organization", "provider_type": "github", "alias": "my-github-organization", "credentials": { "oauth_app_token": "..." } } NOTE: THERE ARE MORE PROVIDER TYPES AND CREDENTIAL TYPES AVAILABLE, PLEASE REFER TO THE Prowler Hub/Prowler Documentation that you can also find in form of tools in this MCP Server.

Create an Amazon S3 integration to export scan outputs to an S3 bucket. After every scan of an attached provider, Prowler uploads the generated reports to 's3://{bucket_name}/{output_directory}/'. IMPORTANT: The connection is checked right after creation, and the result is part of the response. The check writes and deletes a small test object in the bucket, so the credentials need s3:PutObject, s3:ListBucket and s3:DeleteObject on it. Default behavior: - The integration is created enabled - All credential parameters are optional: providing none sends empty credentials, which makes Prowler use the ambient AWS credentials of the deployment. That only works on self-hosted Prowler, Prowler Cloud requires a role or static keys Example Input: - IAM role (recommended): ```json { "bucket_name": "my-security-reports", "output_directory": "prowler", "provider_ids": ["019ac0d6-90d5-73e9-9acf-c22e256f1bac"], "role_arn": "arn:aws:iam::123456789012:role/ProwlerS3Integration", "external_id": "019ac0d6-90d5-73e9-9acf-c22e256f1bac" } ``` - Static credentials: ```json { "bucket_name": "my-security-reports", "aws_access_key_id": "AKIA...", "aws_secret_access_key": "..." } ``` Workflow: 1. Use prowler_search_providers to get the provider UUIDs to attach 2. Use this tool to create the integration 3. Read 'connected' in the response. If it is 'failed', read 'error', then fix the bucket policy or the credentials with prowler_update_integration

Create an AWS Security Hub integration to send findings to Security Hub in ASFF format. After every scan of the attached provider, Prowler pushes its findings to Security Hub in every region where the Prowler partner integration is enabled. IMPORTANT: The Prowler integration must be enabled in AWS Security Hub beforehand, in each region where findings should land. The connection check performed right after creation is what discovers those regions and fills 'enabled_regions'. Default behavior: - The integration is created enabled - Leaving every credential parameter empty makes Prowler reuse the credentials already stored for the provider. This is the recommended setup - send_only_fails defaults to false, so passed findings are sent too Constraints: - Exactly one provider, and it must be an AWS provider - A provider can only have one Security Hub integration. Creating a second one fails with a conflict error Workflow: 1. Use prowler_search_providers with provider_type=['aws'] to get the provider UUID 2. Use this tool to create the integration 3. Read 'enabled_regions' in the response configuration. If it is empty, the Prowler integration is not enabled in Security Hub yet

Create a Jira integration to open Jira work items from Prowler findings. Unlike the other integration types, Jira is tenant-wide: it is not attached to any provider and applies to every finding the role can see. IMPORTANT: Jira integrations do not send anything automatically. Work items are only created on demand with prowler_send_findings_to_jira. IMPORTANT: The connection is checked right after creation, and that check is what discovers the available Jira projects. If 'connected' comes back 'failed', the 'projects' mapping stays empty and no finding can be dispatched. Default behavior: - The integration is created enabled - The configuration is entirely server-generated: 'domain', 'projects' and 'issue_types' Example Input: ```json { "domain": "acme", "user_mail": "security@acme.com", "api_token": "ATATT3xFfGF0..." } ``` Workflow: 1. Use this tool to create the integration 2. Read 'projects' in the response configuration to pick a project key 3. Use prowler_get_jira_issue_types with that project key to pick an issue type 4. Use prowler_send_findings_to_jira to create the work items

Create a new mute rule to mute specific findings with documentation and audit trail. IMPORTANT: This immediately mutes the specified findings AND all previous findings with matching UIDs (this could take some time to complete). The rule is enabled by default. Muting is permanent. Default behavior: - Rule is created in enabled state - Applies to current and previous findings with matching UIDs - Records creator for audit trail The mute rule includes: - Core identification: id (UUID for prowler_get_mute_rule), name, reason - Configuration: enabled status, finding_uids list - Audit trail: user_creator_id (UUID of the Prowler user from the tenant that created the rule), timestamps when the rule was created and last modified Workflow: 1. Use prowler_search_security_findings to identify findings to mute 2. Use this tool with finding IDs, descriptive name, and documented reason 3. Verify with prowler_get_mute_rule to confirm rule creation 4. Check findings are muted with prowler_search_security_findings (filter by muted=true)

Permanently remove an integration from Prowler. WARNING: This is a destructive operation that cannot be undone. The stored credentials are destroyed with it, so the integration has to be recreated from scratch, with its credentials, to be used again. Deletion behavior: - Prowler stops sending results to this destination immediately - Data already exported stays where it is: objects in S3, findings in Security Hub and work items in Jira are not removed - To pause an integration instead, use prowler_update_integration with enabled=False Workflow: 1. Use prowler_get_integration to review what will be deleted 2. Use this tool to permanently remove it 3. Verify with prowler_list_integrations (it should no longer appear)

Delete a mute rule from the system. WARNING: Findings that were muted by this rule REMAIN MUTED after deletion. This only removes the rule itself from management, not the muting effect on findings. The muted findings will stay muted permanently. Deletion behavior: - Rule is permanently removed from the system - Muted findings remain muted (deletion doesn't un-mute them) - Cannot be undone - rule must be recreated to restore Workflow: 1. Use prowler_get_mute_rule to review what will be deleted 2. Use this tool to permanently remove the rule 3. Verify deletion with prowler_list_mute_rules (rule should no longer appear)

Remove the mutelist configuration from the tenant. WARNING: This is a destructive operation that cannot be undone. - The mutelist will need to be re-created with prowler_set_mutelist - New findings from future scans will NOT be muted by the deleted mutelist - Previously muted findings remain muted (deletion doesn't un-mute them) Workflow: 1. Use prowler_get_mutelist to confirm what will be deleted 2. Use this tool to permanently remove the mutelist 3. New scans will no longer apply mutelist-based muting

Permanently remove a registered provider from Prowler. WARNING: This is a destructive operation that cannot be undone. The provider will need to be re-added with prowler_connect_provider if you want to scan it again. Prowler removes the provider and everything attached to it (its scans, findings and resources) in a background task, so a large provider can take longer than the time this tool waits for it. The result includes: - status: 'deleted' when Prowler finished removing the provider, 'in_progress' when the deletion was accepted and is still running - task_id: the background task, present when the deletion was still running NEVER send the deletion again while status='in_progress'. Use prowler_search_providers to check whether the provider is gone.

Retrieve the full content of a Prowler documentation file. Use this after searching to get the complete content of a specific documentation file. Returns: Full content of the documentation file in markdown format.