---
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
---

# 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 and retrieve detection rule definitions to understand what logic is generating signals.
- **Manage suppressions**: Create, update, and delete suppressions to silence noisy rules for specific conditions without disabling them entirely.
- **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.

## 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 %}

### 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 %}

{% /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 %}

## 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)
- [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)