# Datadog MCP for AI Agents AI Agent Connect > Datadog MCP gives your AI agent direct access to your entire observability stack. Query live metrics, search through logs, and manage monitors without leaving your workspace. It turns your agent into an SRE that can triage incidents, audit SLOs, and check infrastructure health in real-time. ## Overview - **Category:** loved-by-devs - **Price:** Free - **Endpoint:** https://edge.vinkius.com/vk_preview_oO12PZpN4jzeqVhbVffRApIi9JBi4zx1zUUaHQvL/ai-agent-connect - **Tags:** full-stack-monitoring, infrastructure-metrics, log-analysis, incident-management, cloud-monitoring, alerting ## Description Imagine you're in the middle of a production incident. Usually, you're jumping between tabs, hunting for a specific log entry, and trying to figure out which alert is actually firing. With this Connector, you can just ask your agent to find the needle in the haystack. It pulls data directly from your Datadog account, so you can see what's happening with your services, hosts, and logs in one place. You can ask it to find all the 5xx errors for a specific service over the last hour or check the CPU usage on your production web servers. It handles the heavy lifting of navigating dashboards and complex query syntax. Because it's listed on the Vinkius catalog, you can get this connected to your favorite AI client in minutes. Instead of manually clicking through the Datadog UI to check SLO compliance or audit alert coverage, your agent does the legwork. It's like having a dedicated SRE sitting next to you, ready to pull reports, silence alerts during maintenance, and summarize incident statuses the second you need them. You don't have to worry about memorizing specific query structures or navigating nested menus. You just describe the problem, and the agent retrieves the relevant data to help you make a call. This turns your workflow from a manual search into a direct conversation with your infrastructure. ## Tools ### check_datadog_status Verify connectivity ### create_event Create an event ### get_dashboard Fetch the specific configuration details for a Datadog dashboard using its unique ID. ### get_incident Get incident details ### get_monitor Retrieve the configuration and status of a specific Datadog monitor. ### list_events List events ### list_incidents View active and recently resolved incidents with severity levels and responder info. ### list_metrics List metrics ### list_monitors Get a full list of all monitors to audit your alerting coverage across the stack. ### mute_monitor Silence a specific monitor during maintenance windows to prevent unnecessary alerts. ### list_slos Audit your Service Level Objectives to track availability targets across different teams. ### query_metrics Run Datadog query syntax to analyze metric trends like CPU or memory usage. ### search_logs Search for log events using filters like service, status, or specific indexed attributes. ### search_monitors Search monitors ### list_hosts See a list of all monitored hosts including their tags and current metric summaries. ### list_dashboards Discover all available dashboards and their widget configurations. ## Prompt Examples **Prompt:** ``` Show me the error logs for the checkout service from the last 15 minutes. ``` **Response:** ``` I've pulled the logs for **checkout-service** from the last 15 minutes. Here are the most recent entries: | Timestamp | Host | Status | Message | | :--- | :--- | :--- | :--- | | 14:02:11 | prod-web-04 | 500 | ConnectionTimeout: upstream service did not respond | | 14:02:15 | prod-web-01 | 500 | ConnectionTimeout: upstream service did not respond | | 14:03:01 | prod-web-04 | 500 | ConnectionTimeout: upstream service did not respond | It looks like there's a recurring timeout issue on host **prod-web-04**. ``` **Prompt:** ``` What's the current status of our production monitors? ``` **Response:** ``` I've checked your production monitors. There are currently **3 active alerts**: * **High CPU Usage on web01** (Metric Alert) - Triggered 12m ago * **API Latency P99 > 500ms** (Query Alert) - Triggered 5m ago * **Database Connection Pool Exhausted** (Service Check) - Critical Would you like me to fetch the logs for the Latency alert? ``` **Prompt:** ``` Summarize the active incidents and who's responding. ``` **Response:** ``` Here is the status of ongoing incidents: **Incident #492: Payment Gateway Timeout** * **Severity:** Critical * **Status:** Active * **Responder:** @jdoe_sre * **Summary:** Users are seeing timeouts during checkout. Investigation is ongoing. **Incident #488: High Disk Usage on Storage-01** * **Severity:** Warning * **Status:** Active * **Responder:** @ops_team * **Summary:** Disk usage is at 88%. Cleanup script is running. ``` ## Capabilities ### Query live metric timeseries Get real-time data on CPU, memory, and custom business metrics using natural language. ### Look through logs Search structured and unstructured log events by service, host, or status code. ### Handle alert monitors Create, update, mute, or unmute monitors to manage your notification volume. ### Audit synthetics and SLOs Check your synthetic test coverage and verify SLA compliance across teams. ### Triage active incidents View ongoing incidents with severity levels, responder info, and resolution status. ### Inventory monitored hosts List all monitored hosts with their tags and current metric summaries. ### Audit team permissions Review user roles and team memberships to maintain organizational security. ## Use Cases ### Rapid Incident Triage An engineer asks the agent to find all 500 errors for the payment service in the last 10 minutes using search_logs. ### Audit Readiness A manager asks the agent to list all monitors and check for missing tags on production hosts using list_monitors. ### Maintenance Window Management An SRE asks the agent to mute all web server monitors for a scheduled database migration using mute_monitor. ### Capacity Planning A developer asks the agent to query the average CPU usage for the last 30 days to plan a scale-up using query_metrics. ## Benefits - Stop switching tabs by querying metrics and searching logs directly within your AI client. - Triage incidents faster by using list_incidents to see severity and responder assignments instantly. - Manage alert fatigue by using mute_monitor and unmute_monitor to handle maintenance windows. - Audit your entire stack quickly using list_monitors and list_slos to ensure coverage. - Get instant host summaries with list_hosts to check environment health during deployments. - Maintain security by using list_users and list_teams to audit permissions and ownership. ## How It Works The bottom line is you get a conversational interface for your entire Datadog observability stack. 1. Subscribe to the Connector and provide your Datadog API and Application keys. 2. Connect the Connector to your preferred AI client like Claude or Cursor. 3. Ask your agent to perform tasks like searching logs or listing active incidents. ## Frequently Asked Questions **Can the Datadog MCP search my logs for specific errors?** Yes, it can search structured and unstructured logs using filters like service name, status codes, and host info. This lets you find specific error patterns without manually navigating the log explorer. **How do I use the Datadog MCP to manage my alerts?** You can create, update, and mute monitors using natural language. This helps you manage alert fatigue and silence specific monitors during planned maintenance windows. **Can I use this to check my SLO compliance?** Yes, the Connector can list your Service Level Objectives so you can verify availability targets across your teams and ensure you're meeting your SLAs. **Is the Datadog MCP good for incident response?** It's great for triage. You can quickly see active incidents, severity levels, and responder assignments without leaving your agent, helping you stay focused on the fix. **Can I audit my Datadog user permissions with this?** Yes, it lets you list users and teams to verify who has access to what, helping you maintain security and audit organizational roles easily. **Can I query my infrastructure metrics using the Datadog MCP?** You can query raw metric timeseries for things like CPU, memory, and custom business metrics using Datadog's query syntax directly through your agent. **What's the difference between Datadog API Key and Application Key?** The **API Key** authenticates your requests to the Datadog platform and is required for all endpoints. The **Application Key** is an additional layer of authorization that controls what actions your integration can perform. Both are generated in Organization Settings > API and Application Keys. Most Datadog API endpoints require both keys. **Can I mute a monitor during a maintenance window?** Yes! Use the `mute_monitor` action with the monitor ID. You can optionally set an `end` timestamp (ISO 8601) for the mute to automatically expire, or specify a `scope` to mute only certain sub-alerts (e.g. 'env:staging'). Use `unmute_monitor` to re-enable notifications. **What query syntax does the metrics endpoint use?** Datadog uses a specific query format: `[function]:[metric]{[tags]}`. For example: `avg:system.cpu.user{host:web01}` returns the average CPU user time for host web01. Common functions include `avg`, `sum`, `max`, `min`, `count`. Time windows are specified in the query as `avg(last_5m):...` or passed as `from`/`to` Unix timestamps to the tool. **Can I silence noisy monitors during scheduled maintenance?** Yes. The `mute_monitor` action silences a specific monitor by its ID, suppressing all alert notifications. This is ideal during deployment windows or planned maintenance. Use `search_monitors` to find the monitor by name or tag first, then mute it by ID. **Does Datadog require two credentials to connect?** Yes. You need your **API Key** (found in Organization Settings > API Keys) and your **Base URL**, which depends on your Datadog site region: `https://api.datadoghq.com` for US1, `https://api.datadoghq.eu` for EU, or `https://api.us3.datadoghq.com` for US3. The API Key is sent via the `DD-API-KEY` header. **Can I run time-series metric queries with custom time ranges?** Yes. The `query_metrics` tool accepts a Datadog metric query string (e.g., `avg:system.cpu.user{host:web-01}`), a start epoch timestamp, and an end epoch timestamp. It returns the time-series data points for that metric across the specified window.