MCP Panther v2.1.1

Tools

🔧 Enhanced Tools

• Detections: list_detections - Added support for filtering by alert destinations (outputIDs)
  • New output_ids parameter: Filter detections by configured alert destinations
  • outputIDs field now included: All detection responses now include the outputIDs field without requiring separate get_detection calls

Important Note: This feature only supports alert destinations explicitly set on detections in the Console or using the OutputIDs YML setting. This will not account for dynamic severity() overrides in the detection body or the default alert destination routing.

Functionality

🆕 New Features

• Alert Destination Filtering: Filter detections by output IDs (alert destinations)

  • Client-side filtering finds detections with at least one matching outputID
  • Works seamlessly with existing filters (severity, tags, log types, detection types, etc.)
  • Resolves issue #138

  Example Usage:

which rules have alert destination 4b278a55-903a-4e5e-8d40-3c6d064507a0 

⏺ I'll search for rules that have that specific alert destination configured.

⏺ panther - list_detections (MCP)(detection_types: ["rules","scheduled_rules","simple_rules"], output_ids: ["4b278a55-903a-4e5e-8d40-3c6d064507a0"], limit: 1000)
  ⎿  {                             
       "success": true,
       "rules": [
     … +79 lines (ctrl+o to expand)

⏺ I found 2 rules that have the alert destination 4b278a55-903a-4e5e-8d40-3c6d064507a0 configured:

  1. AWS.GuardDuty.BitcoinMining.Demo
    - Display Name: AWS GuardDuty Bitcoin Mining Activity Detected
    - Status: Enabled
    - Severity: HIGH
    - Log Type: AWS.GuardDuty
    - Description: Detects when AWS GuardDuty reports an EC2 instance is likely being used for unauthorized bitcoin or cryptocurrency mining

  2. test_rule2
    - Display Name: test_rule2
    - Status: Disabled
    - Severity: MEDIUM
    - Log Type: Okta.SystemLog
    - Tags: #demo, dev

Contributors

Special thanks to:

• @secrng (Gusto SecOps) - For identifying the need and providing clear use case requirements in issue #138

Migration Guide

For users upgrading from v2.1.0

No breaking changes - this is a backward-compatible enhancement.

No action required - Existing list_detections calls will continue to work exactly as before.