Datadog

Datadog

winor30

Connects to your Datadog account to query metrics, logs, dashboards, monitors, and incidents directly from chat interfaces. Requires Datadog API and application keys.

Integrates with Datadog's API to enable incident management, including listing and retrieving incident information for system monitoring and observability workflows.

1391,023 views67Local (stdio)

What it does

  • Query Datadog metrics and metadata
  • Search and filter logs with advanced options
  • Retrieve dashboard definitions and configurations
  • Access monitor data and alert states
  • Search events within specific timeframes
  • View incident management data

Best for

DevOps teams debugging production issuesSRE workflows for monitoring and alertingData analysts exploring system metricsIncident response and troubleshooting
Supports both Datadog v1 and v2 APIsScoped API keys for improved security

About Datadog

Datadog is a community-built MCP server published by winor30 that provides AI assistants with tools and capabilities via the Model Context Protocol. Integrate Datadog monitor for streamlined incident management. List and get incident info to enhance your observability It is categorized under developer tools, analytics data.

How to install

You can install Datadog in your AI client of choice. Use the install panel on this page to get one-click setup for Cursor, Claude Desktop, VS Code, and other MCP-compatible clients. This server runs locally on your machine via the stdio transport.

License

Datadog is released under the Apache-2.0 license. This is a permissive open-source license, meaning you can freely use, modify, and distribute the software.

Datadog MCP Server

DISCLAIMER: This is a community-maintained project and is not officially affiliated with, endorsed by, or supported by Datadog, Inc. This MCP server utilizes the Datadog API but is developed independently as part of the Model Context Protocol ecosystem.

NPM VersionBuild and Testcodecovsmithery badge

MCP server for the Datadog API, enabling incident management and more.

mcp-server-datadog MCP server

Features

  • Observability Tools: Provides a mechanism to leverage key Datadog monitoring features, such as incidents, monitors, logs, dashboards, and metrics, through the MCP server.
  • Extensible Design: Designed to easily integrate with additional Datadog APIs, allowing for seamless future feature expansion.

Tools

  1. list_incidents

    • Retrieve a list of incidents from Datadog.
    • Inputs:
      • filter (optional string): Filter parameters for incidents (e.g., status, priority).
      • pagination (optional object): Pagination details like page size/offset.
    • Returns: Array of Datadog incidents and associated metadata.
  2. get_incident

    • Retrieve detailed information about a specific Datadog incident.
    • Inputs:
      • incident_id (string): Incident ID to fetch details for.
    • Returns: Detailed incident information (title, status, timestamps, etc.).
  3. get_monitors

    • Fetch the status of Datadog monitors.
    • Inputs:
      • groupStates (optional array): States to filter (e.g., alert, warn, no data, ok).
      • name (optional string): Filter by name.
      • tags (optional array): Filter by tags.
    • Returns: Monitors data and a summary of their statuses.
  4. get_logs

    • Search and retrieve logs from Datadog.
    • Inputs:
      • query (string): Datadog logs query string.
      • from (number): Start time in epoch seconds.
      • to (number): End time in epoch seconds.
      • limit (optional number): Maximum number of logs to return (defaults to 100).
    • Returns: Array of matching logs.
  5. list_dashboards

    • Get a list of dashboards from Datadog.
    • Inputs:
      • name (optional string): Filter dashboards by name.
      • tags (optional array): Filter dashboards by tags.
    • Returns: Array of dashboards with URL references.
  6. get_dashboard

    • Retrieve a specific dashboard from Datadog.
    • Inputs:
      • dashboard_id (string): ID of the dashboard to fetch.
    • Returns: Dashboard details including title, widgets, etc.
  7. query_metrics

    • Retrieve metrics data from Datadog.
    • Inputs:
      • query (string): Metrics query string.
      • from (number): Start time in epoch seconds.
      • to (number): End time in epoch seconds.
    • Returns: Metrics data for the queried timeframe.
  8. list_traces

    • Retrieve a list of APM traces from Datadog.
    • Inputs:
      • query (string): Datadog APM trace query string.
      • from (number): Start time in epoch seconds.
      • to (number): End time in epoch seconds.
      • limit (optional number): Maximum number of traces to return (defaults to 100).
      • sort (optional string): Sort order for traces (defaults to '-timestamp').
      • service (optional string): Filter by service name.
      • operation (optional string): Filter by operation name.
    • Returns: Array of matching traces from Datadog APM.
  9. list_hosts

    • Get list of hosts from Datadog.
    • Inputs:
      • filter (optional string): Filter string for search results.
      • sort_field (optional string): Field to sort hosts by.
      • sort_dir (optional string): Sort direction (asc/desc).
      • start (optional number): Starting offset for pagination.
      • count (optional number): Max number of hosts to return (max: 1000).
      • from (optional number): Search hosts from this UNIX timestamp.
      • include_muted_hosts_data (optional boolean): Include muted hosts status and expiry.
      • include_hosts_metadata (optional boolean): Include host metadata (version, platform, etc).
    • Returns: Array of hosts with details including name, ID, aliases, apps, mute status, and more.
  10. get_active_hosts_count

    • Get the total number of active hosts in Datadog.
    • Inputs:
      • from (optional number): Number of seconds from which you want to get total number of active hosts (defaults to 2h).
    • Returns: Count of total active and up hosts.
  11. mute_host

    • Mute a host in Datadog.
    • Inputs:
      • hostname (string): The name of the host to mute.
      • message (optional string): Message to associate with the muting of this host.
      • end (optional number): POSIX timestamp for when the mute should end.
      • override (optional boolean): If true and the host is already muted, replaces existing end time.
    • Returns: Success status and confirmation message.
  12. unmute_host

    • Unmute a host in Datadog.
    • Inputs:
      • hostname (string): The name of the host to unmute.
    • Returns: Success status and confirmation message.
  13. list_downtimes

    • List scheduled downtimes from Datadog.
    • Inputs:
      • currentOnly (optional boolean): Return only currently active downtimes when true.
      • monitorId (optional number): Filter by monitor ID.
    • Returns: Array of scheduled downtimes with details including scope, monitor information, and schedule.
  14. schedule_downtime

    • Schedule a downtime in Datadog.
    • Inputs:
      • scope (string): Scope to apply downtime to (e.g. 'host:my-host').
      • start (optional number): UNIX timestamp for the start of the downtime.
      • end (optional number): UNIX timestamp for the end of the downtime.
      • message (optional string): A message to include with the downtime.
      • timezone (optional string): The timezone for the downtime (e.g. 'UTC', 'America/New_York').
      • monitorId (optional number): The ID of the monitor to mute.
      • monitorTags (optional array): A list of monitor tags for filtering.
      • recurrence (optional object): Recurrence settings for the downtime.
        • type (string): Recurrence type ('days', 'weeks', 'months', 'years').
        • period (number): How often to repeat (must be >= 1).
        • weekDays (optional array): Days of the week for weekly recurrence.
        • until (optional number): UNIX timestamp for when the recurrence ends.
    • Returns: Scheduled downtime details including ID and active status.
  15. cancel_downtime

    • Cancel a scheduled downtime in Datadog.
    • Inputs:
      • downtimeId (number): The ID of the downtime to cancel.
    • Returns: Confirmation of downtime cancellation.
  16. get_rum_applications

    • Get all RUM applications in the organization.
    • Inputs: None.
    • Returns: List of RUM applications.
  17. get_rum_events

    • Search and retrieve RUM events from Datadog.
    • Inputs:
      • query (string): Datadog RUM query string.
      • from (number): Start time in epoch seconds.
      • to (number): End time in epoch seconds.
      • limit (optional number): Maximum number of events to return (default: 100).
    • Returns: Array of RUM events.
  18. get_rum_grouped_event_count

    • Search, group and count RUM events by a specified dimension.
    • Inputs:
      • query (optional string): Additional query filter for RUM search (default: "*").
      • from (number): Start time in epoch seconds.
      • to (number): End time in epoch seconds.
      • groupBy (optional string): Dimension to group results by (default: "application.name").
    • Returns: Grouped event counts.
  19. get_rum_page_performance

    • Get page (view) performance metrics from RUM data.
    • Inputs:
      • query (optional string): Additional query filter for RUM search (default: "*").
      • from (number): Start time in epoch seconds.
      • to (number): End time in epoch seconds.
      • metricNames (array of strings): Array of metric names to retrieve (e.g., 'view.load_time', 'view.first_contentful_paint').
    • Returns: Performance metrics including average, min, max, and count for each metric.
  20. get_rum_page_waterfall

    • Retrieve RUM page (view) waterfall data filtered by application name and session ID.
    • Inputs:
      • applicationName (string): Application name to filter events.
      • sessionId (string): Session ID to filter events.
    • Returns: Waterfall data for the specified application and session.

Setup

Datadog Credentials

You need valid Datadog API credentials to use this MCP server:

  • DATADOG_API_KEY: Your Datadog API key
  • DATADOG_APP_KEY: Your Datadog Application key
  • DATADOG_SITE (optional): The Datadog site (e.g. datadoghq.eu)
  • DATADOG_SUBDOMAIN (optional): The Datadog subdomain (e.g. <your-subdomain>.datadoghq.com)
  • DATADOG_STORAGE_TIER (optional): Logs storage tier for v2 logs searches. Supported values: indexes, online-archives, or flex.

Export them in your environment before running the server:

export DATADOG_API_KEY="your_api_key"
export DATADOG_APP_KEY="your_app_key"
export DATADOG_SITE="your_datadog_site" # Optional
export DATADOG_SUBDOMAIN="your_datadog_subdomain" # Optional


---

*README truncated. [View full README on GitHub](https://github.com/winor30/mcp-server-datadog).*

Alternatives

Related Skills

Browse all skills
mcp-developer

Use when building MCP servers or clients that connect AI systems with external tools and data sources. Invoke for MCP protocol compliance, TypeScript/Python SDKs, resource providers, tool functions.

0
datadog-automation

Automate Datadog tasks via Rube MCP (Composio): query metrics, search logs, manage monitors/dashboards, create events and downtimes. Always search tools first for current schemas.

0
ccxt-typescript

CCXT cryptocurrency exchange library for TypeScript and JavaScript developers (Node.js and browser). Covers both REST API (standard) and WebSocket API (real-time). Helps install CCXT, connect to exchanges, fetch market data, place orders, stream live tickers/orderbooks, handle authentication, and manage errors. Use when working with crypto exchanges in TypeScript/JavaScript projects, trading bots, arbitrage systems, or portfolio management tools. Includes both REST and WebSocket examples.

0
dotnet-backend

.NET/C# backend developer for ASP.NET Core APIs with Entity Framework Core. Builds REST APIs, minimal APIs, gRPC services, authentication with Identity/JWT, authorization, database operations, background services, SignalR real-time features. Activates for: .NET, C#, ASP.NET Core, Entity Framework Core, EF Core, .NET Core, minimal API, Web API, gRPC, authentication .NET, Identity, JWT .NET, authorization, LINQ, async/await C#, background service, IHostedService, SignalR, SQL Server, PostgreSQL .NET, dependency injection, middleware .NET.

64
supabase-developer

Build full-stack applications with Supabase (PostgreSQL, Auth, Storage, Real-time, Edge Functions). Use when implementing authentication, database design with RLS, file storage, real-time features, or serverless functions.

59
data-storytelling

Transform data into compelling narratives using visualization, context, and persuasive structure. Use when presenting analytics to stakeholders, creating data reports, or building executive presentations.

13