Reading the alert, pulling its events, widening into the data lake with SQL, then opening the detection that fired and its tests is a single chain here rather than three consoles, and the bulk update tools mean a batch of related alerts closes in one call. Two things worth setting up front: the data lake queries want a time filter, since an unbounded SQL query over security logs is expensive wherever you run it, and token permissions are the usual reason a tool fails, which is what get_permissions answers.
Panther's own server for its security platform, covering alerts, the data lake, detections, log sources, schemas and users. Every tool declares the Panther permissions it needs, and get_permissions reports what your token actually holds.
- list_alerts with filtering by date range, severity and status, get_alert for one, and get_alert_events for a sample of the events behind it
- start_ai_alert_triage runs Panther's AI triage on an alert and get_ai_alert_triage_summary retrieves the result
- Alerts worked in bulk: update status, update assignee, or bulk_update_alerts for status, assignee and a comment at once, with Markdown comments added and listed per alert
- get_alert_event_stats aggregates event data across several alerts into time-based groups, which is how a pattern across alerts becomes visible
- query_data_lake runs SQL against the security data lake, with list_databases, list_database_tables and get_table_schema to find your way around it first
- Detections listed with filters on name, state, severity, tags, log types and alert destinations, read in full including their body and tests, and disabled by id
- list_global_helpers and get_global_helper cover the shared Python helpers detections rely on; list_data_models and get_data_model cover the log-type mappings
- Log sources listed with health and integration filters, and HTTP sources read individually
- Log type schemas listed and read in detail, up to five at a time
- Metrics that tell you where the noise is: get_rule_alert_metrics grouped by detection rule, get_severity_alert_metrics by severity, and get_bytes_processed_metrics per log type and source
- Users and roles listed and read, so an assignee or a permission question can be answered in place
- Scheduled queries listed and read by id
A Panther instance and an API token: PANTHER_INSTANCE_URL and PANTHER_API_TOKEN. It runs as uvx mcp-panther, or from the ghcr.io/panther-labs/mcp-panther image, both of which the project recommends pinning to a version for production. The token's Panther permissions decide what works — reading alerts, viewing rules and managing rules or policies are separate grants — and get_permissions exists to diagnose that rather than leaving you guessing at a failure.
One command plus a key — uvx mcp-panther, then supply credentials