---
title: Security MCP Tools
description: >-
  Use AI agents to investigate security signals and analyze security findings
  with the Datadog MCP Server's security toolset.
breadcrumbs: Docs > Datadog Security > Security MCP Tools
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Security MCP Tools

{% callout %}
# Important note for users on the following Datadog sites: app.ddog-gov.com, us2.ddog-gov.com

{% alert level="danger" %}
This product is not supported for your selected [Datadog site](https://docs.datadoghq.com/getting_started/site.md). ({% placeholder "user-datadog-site-name" /%}).
{% /alert %}

{% /callout %}

## Overview{% #overview %}

The [Datadog MCP Server](https://docs.datadoghq.com/mcp_server.md) lets AI agents query your security data through the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/). The `security` toolset gives AI clients like Cursor, Claude Code, and OpenAI Codex access to your security signals and findings, so you can investigate threats and analyze your security posture using natural language.

{% alert level="info" %}
This page covers the `security` toolset of the remote Datadog MCP Server. For the Code Security MCP Server, which runs locally and scans source code during development, see [Code Security MCP Server](https://docs.datadoghq.com/security/code_security/dev_tool_int/mcp_server.md).
{% /alert %}

### Use cases{% #use-cases %}

You can use the `security` toolset to:

- **Analyze and understand security signals**: Ask your AI agent to surface recent high-severity Cloud SIEM signals, App & API Protection alerts, or Workload Protection threats, and get a summary of patterns and affected resources.
- **Triage security signals**: Update triage state or assignee across a set of matching signals in bulk.
- **Analyze your security posture**: Query findings across Cloud Security with SQL to understand the distribution of misconfigurations, vulnerabilities, and identity risks across your environment.
- **Investigate specific findings**: Retrieve full details for a set of findings to understand scope, affected resources, and remediation context.
- **Triage security findings**: Create Jira issues, ServiceNow tickets, or Case Management cases for findings. Assign findings to team members, or mute false positives and accepted risks.
- **Correlate signals and findings**: Cross-reference active security signals with open findings to determine whether an alert is tied to a known posture issue.
- **Inspect and manage detection rules**: List, retrieve, create, update, and delete detection rules to understand and manage the logic generating signals.
- **Manage suppressions**: Create, update, and delete suppressions to silence noisy rules for specific conditions without disabling them entirely.
- **Respond to attacks with App & API Protection**: Block or unblock IPs, users, and user agents on the denylist, and suppress false positives with passlist exclusion filters.
- **Remediate vulnerabilities with an AI agent**: Pull library vulnerability findings, including code location and remediation guidance, and pass them to your AI agent to apply patches directly in your codebase.
- **Investigate indicators of compromise (IoCs)**: Search and retrieve IP addresses, domains, URLs, and file hashes matched against threat intelligence feeds. Review individual indicators and update their triage state.

## Quickstart{% #quickstart %}

The `security` toolset is not enabled by default. You can enable it by adding a parameter to your URL, which allows security tools to interact with your AI client.

1. [Set up the Datadog MCP Server](https://docs.datadoghq.com/mcp_server/setup.md).
1. When connecting to the Datadog MCP Server, add `security` to the `toolsets` parameter. For example, for your [Datadog site](https://docs.datadoghq.com/getting_started/site.md) ({% placeholder "user-datadog-site-name" /%}), use:
   ```text
   https://mcp.<YOUR_DATADOG_SITE>/v1/mcp?toolsets=core,security
   ```

{% alert level="warning" %}
`?toolsets=security` must be in the URL. Otherwise, security tools are not available to your AI client, even if the MCP Server is otherwise connected and working.
{% /alert %}

## Available tools{% #available-tools %}

The `security` toolset exposes the following tools to your AI client. Each tool performs a specific action on your security data. When you ask a question in natural language, your AI client calls these tools on your behalf to retrieve the information it needs. For general information on how to use MCP tools, see the [Datadog MCP Server Overview](https://docs.datadoghq.com/mcp_server.md).

### Security Signals{% #security-signals %}

{% dl %}

{% dt %}
`get_datadog_security_signals_schema`
{% /dt %}

{% dd %}
Returns the available fields and their types for security signals. Signal types map to `@workflow.rule.type` values such as `Log Detection`, `Application Security`, and `Workload Security`.
{% /dd %}

{% dd %}
*Permissions required: `Security Signals Read`*
{% /dd %}

{% dt %}
`search_datadog_security_signals`
{% /dt %}

{% dd %}
Searches and retrieves security signals from Datadog, including Cloud SIEM signals, App & API Protection signals, and Workload Protection signals. Use this to surface and investigate suspicious activity.
{% /dd %}

{% dd %}
*Permissions required: `Security Signals Read`*
{% /dd %}

{% dt %}
`analyze_datadog_security_signals`
{% /dt %}

{% dd %}
Analyzes security signals using SQL for aggregations, grouping, and trend analysis. Use this for counts, top-N breakdowns, and time-based questions. To list signals or retrieve a single signal, use `search_datadog_security_signals` or `get_datadog_security_signal` instead. Call `get_datadog_security_signals_schema` first to discover queryable fields.
{% /dd %}

{% dd %}
*Permissions required: `Security Signals Read`, `Timeseries`*
{% /dd %}

{% dt %}
`get_datadog_security_signal`
{% /dt %}

{% dd %}
Retrieves the full details of a single security signal by ID, including attributes, rule information, triage state, tags, and case correlations. Use `search_datadog_security_signals` to find signal IDs first.
{% /dd %}

{% dd %}
*Permissions required: `Security Signals Read`*
{% /dd %}

{% dt %}
`update_datadog_security_signals_triage`
{% /dt %}

{% dd %}
Updates the triage state or assignee of one or more security signals in bulk (up to 500 signals). Accepts either a list of signal IDs or a filter query matching all signals to update.
{% /dd %}

{% dd %}
*Permissions required: `Security Signals Write`*
{% /dd %}

{% /dl %}

### IoC Explorer{% #ioc-explorer %}

{% dl %}

{% dt %}
`search_datadog_security_ioc_indicators`
{% /dt %}

{% dd %}
Lists [IoC Explorer](https://docs.datadoghq.com/security/cloud_siem/triage_and_investigate/ioc_explorer.md) indicators (IP addresses, domains, URLs, and file hashes) matched against threat intelligence feeds. Use this to surface and investigate indicators of compromise in your environment.
{% /dd %}

{% dd %}
*Permissions required: `Security Signals Read`*
{% /dd %}

{% dt %}
`get_datadog_security_ioc_indicator`
{% /dt %}

{% dd %}
Retrieves full details for a single [IoC Explorer](https://docs.datadoghq.com/security/cloud_siem/triage_and_investigate/ioc_explorer.md) indicator by value, including score, category, Autonomous System (AS) information, GeoIP data, log sources, and signal counts.
{% /dd %}

{% dd %}
*Permissions required: `Security Signals Read`*
{% /dd %}

{% dt %}
`get_datadog_security_ioc_schema`
{% /dt %}

{% dd %}
Returns available filterable fields and their values for [IoC Explorer](https://docs.datadoghq.com/security/cloud_siem/triage_and_investigate/ioc_explorer.md). Omit `filter` to list available fields; supply `filter` to get values with counts. Use `query` to scope results to a subset of indicators.
{% /dd %}

{% dd %}
*Permissions required: `Security Signals Read`*
{% /dd %}

{% dt %}
`update_datadog_security_ioc_indicator_triage`
{% /dt %}

{% dd %}
Sets the triage state of an [IoC Explorer](https://docs.datadoghq.com/security/cloud_siem/triage_and_investigate/ioc_explorer.md) indicator to mark it as reviewed or not reviewed.
{% /dd %}

{% dd %}
*Permissions required: `Security Signals Write`*
{% /dd %}

{% /dl %}

### Security Findings{% #security-findings %}

{% dl %}

{% dt %}
`get_datadog_security_findings_schema`
{% /dt %}

{% dd %}
Returns the available fields and their types for security findings. Call this before using `analyze_datadog_security_findings` to discover which fields you can filter and group by. Supports filtering by finding type.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Findings Read`*
{% /dd %}

{% dt %}
`analyze_datadog_security_findings`
{% /dt %}

{% dd %}
Primary tool for analyzing security findings using SQL. Queries live data from the last 24 hours with support for aggregations, filtering, and grouping. Call `get_datadog_security_findings_schema` first to discover available fields.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Findings Read`, `Timeseries`*
{% /dd %}

{% dt %}
`search_datadog_security_findings`
{% /dt %}

{% dd %}
Retrieves full security finding objects. Use this when you need complete finding details or when SQL-based analysis is not sufficient. Prefer `analyze_datadog_security_findings` for most analysis tasks.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Findings Read`*
{% /dd %}

{% dt %}
`get_datadog_security_findings_ticket_suggestions`
{% /dt %}

{% dd %}
Returns ranked project suggestions for ticketing security findings. Shows available Case Management, Jira, and ServiceNow projects with usage data. Call this before `create_datadog_security_findings_ticket` to discover which project to use.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Findings Read`, `Cases Read`*
{% /dd %}

{% dt %}
`create_datadog_security_findings_ticket`
{% /dt %}

{% dd %}
Creates a Case Management case, Jira issue, or ServiceNow ticket for security findings. Requires specific finding IDs and a project ID. Use `get_datadog_security_findings_ticket_suggestions` first to discover available projects.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Findings Write`, `Cases Read`, `Cases Write`*
{% /dd %}

{% dt %}
`detach_datadog_security_findings_ticket`
{% /dt %}

{% dd %}
Detaches security findings from their linked case or ticket. Since Jira and ServiceNow tickets are linked through Case Management, detaching the case also detaches any downstream ticket.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Findings Write`, `Cases Write`*
{% /dd %}

{% dt %}
`mute_datadog_security_findings`
{% /dt %}

{% dd %}
Mutes or unmutes security findings to suppress them from alerts and dashboards. Requires a mute reason (`PENDING_FIX`, `FALSE_POSITIVE`, `ACCEPTED_RISK`, or `OTHER`) and supports an optional description and expiration date.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Findings Write`*
{% /dd %}

{% dt %}
`assign_datadog_security_findings`
{% /dt %}

{% dd %}
Assigns or unassigns security findings to a user. Assignment cascades to any linked cases. Omit the assignee ID to unassign.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Findings Write`*
{% /dd %}

{% /dl %}

### Detection Rules{% #detection-rules %}

{% dl %}

{% dt %}
`get_datadog_security_detection_rules_schema`
{% /dt %}

{% dd %}
Returns the authoring reference and schema for detection rules. Covers supported rule types, detection methods, query syntax, tag conventions, and field names that can be used as search facets. Use this before authoring or querying detection rules. Currently supported rule types: log detection and API security.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Rules Read`*
{% /dd %}

{% dt %}
`get_datadog_security_detection_rules`
{% /dt %}

{% dd %}
Retrieves security detection rules. Supports two modes: provide `rule_id` to get the full definition of a single rule by ID, or omit `rule_id` to list rules (optionally filtered with `query` and token-limited with `max_tokens`). The two modes are mutually exclusive.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Rules Read`*
{% /dd %}

{% dt %}
`create_datadog_security_detection_rule`
{% /dt %}

{% dd %}
Creates a new detection rule. Call `get_datadog_security_detection_rules_schema` first to fetch the required payload grammar, then supply a complete rule payload. On success, returns the full rule including its server-assigned ID.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Rules Write`*
{% /dd %}

{% dt %}
`update_datadog_security_detection_rule`
{% /dt %}

{% dd %}
Updates an existing custom detection rule by replacing it entirely. Use this to enable or disable a rule, change thresholds, add cases, and more. Call `get_datadog_security_detection_rules` first to fetch the current rule body, modify the fields you need to change, and submit the full updated object. Cannot update Datadog-shipped default rules. On success, returns the full updated rule.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Rules Write`*
{% /dd %}

{% dt %}
`delete_datadog_security_detection_rules`
{% /dt %}

{% dd %}
Deletes one or more custom detection rules by ID. Only custom (non-default) rules can be deleted. Each rule is authorized individually; rules that cannot be deleted appear in `failed_rules` without aborting the batch. Returns `deleted_rules` and `failed_rules`.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Rules Write`*
{% /dd %}

{% /dl %}

### Suppressions{% #suppressions %}

{% dl %}

{% dt %}
`get_datadog_security_suppressions`
{% /dt %}

{% dd %}
Retrieves security monitoring suppressions. Supports three modes: list all suppressions, get a single suppression by ID, or get suppressions affecting a specific detection rule. Suppressions prevent detection rules from generating signals for matching conditions.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Suppressions Read`*
{% /dd %}

{% dt %}
`create_datadog_security_suppression`
{% /dt %}

{% dd %}
Creates a new suppression rule that prevents a detection rule from generating signals matching specific conditions. At least one of `suppression_query` or `data_exclusion_query` must be provided.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Suppressions Write`*
{% /dd %}

{% dt %}
`update_datadog_security_suppression`
{% /dt %}

{% dd %}
Updates an existing suppression rule. Only changes provided fields. Providing `version` enables optimistic concurrency control to prevent overwriting concurrent edits.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Suppressions Write`*
{% /dd %}

{% dt %}
`delete_datadog_security_suppression`
{% /dt %}

{% dd %}
Deletes a suppression rule.
{% /dd %}

{% dd %}
*Permissions required: `Security Monitoring Suppressions Write`*
{% /dd %}

{% /dl %}

### App & API Protection{% #app--api-protection %}

{% dl %}

{% dt %}
`get_datadog_security_passlist`
{% /dt %}

{% dd %}
Returns all WAF exclusion filter (passlist) entries for the organization to review existing suppressions.
{% /dd %}

{% dd %}
*Permissions required: `Application Security Management Protect Read`*
{% /dd %}

{% dt %}
`upsert_datadog_security_passlist`
{% /dt %}

{% dd %}
Creates or updates a WAF exclusion filter (passlist) entry to suppress noisy rules on a specific service or endpoint.
{% /dd %}

{% dd %}
*Permissions required: `Application Security Management Protect Write`*
{% /dd %}

{% dt %}
`delete_datadog_security_passlist`
{% /dt %}

{% dd %}
Deletes an existing WAF exclusion filter (passlist) entry.
{% /dd %}

{% dd %}
*Permissions required: `Application Security Management Protect Write`*
{% /dd %}

{% dt %}
`get_datadog_security_denylist`
{% /dt %}

{% dd %}
Lists blocked IPs, users, and user agents (denylist entries), with optional filtering.
{% /dd %}

{% dd %}
*Permissions required: `Application Security Management Protect Read`*
{% /dd %}

{% dt %}
`upsert_datadog_security_denylist_entry`
{% /dt %}

{% dd %}
Adds or updates a denylist block for an IP, user, or user agent with an expiration.
{% /dd %}

{% dd %}
*Permissions required: `Application Security Management Protect Write`*
{% /dd %}

{% dt %}
`delete_datadog_security_denylist_entry`
{% /dt %}

{% dd %}
Unblocks a previously denylisted entity by setting its expiration in the past.
{% /dd %}

{% dd %}
*Permissions required: `Application Security Management Protect Write`*
{% /dd %}

{% /dl %}

## Further reading{% #further-reading %}

- [Set Up the Datadog MCP Server](https://docs.datadoghq.com/mcp_server/setup.md)
- [Datadog MCP Server Overview](https://docs.datadoghq.com/mcp_server.md)
- [IoC Explorer](https://docs.datadoghq.com/security/cloud_siem/triage_and_investigate/ioc_explorer.md)
- [Security Signals](https://docs.datadoghq.com/security/threats/security_signals.md)
- [Security Findings](https://docs.datadoghq.com/security/guide/findings-schema.md?tab=library_vulnerability)
- [Detection Rules](https://docs.datadoghq.com/security/detection_rules.md)
- [Suppressions](https://docs.datadoghq.com/security/suppressions.md)