📌Overview

Purpose: The Datadog MCP Server aims to facilitate incident management and integrate essential functionalities of the Datadog API into a cohesive framework.

Overview: The Datadog MCP Server provides an efficient interface to interact with various Datadog services, enabling users to manage incidents, monitors, logs, dashboards, and metrics seamlessly. This server is designed for extensibility, allowing for easy integration with additional Datadog APIs as needed.

Key Features:

• Observability Tools: Access crucial monitoring features such as incident management, logging, dashboards, and metrics from Datadog through a unified MCP server.

• Extensible Design: The framework allows for easy integration with future Datadog API features, ensuring adaptability and relevance as new tools and functionalities emerge.

---

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.

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

Features

• Observability Tools: Leverage key Datadog monitoring features, such as incidents, monitors, logs, dashboards, and metrics, through the MCP server.
• Extensible Design: Easily integrates with additional Datadog APIs for seamless future feature expansion.

Tools

1. list_incidents

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

2. get_incident

   • Retrieve details about a specific incident.
   • Inputs:
     • incident_id (string): Incident ID.
   • Returns: Incident details (title, status, timestamps, etc.).

3. get_monitors

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

4. get_logs

   • Search and retrieve logs.
   • Inputs:
     • query (string): Logs query string.
     • from (number): Start time in epoch seconds.
     • to (number): End time in epoch seconds.
     • limit (optional number): Max logs to return (default 100).
   • Returns: Array of matching logs.

5. list_dashboards

   • Get a list of dashboards.
   • Inputs:
     • name (optional string): Filter by name.
     • tags (optional array): Filter by tags.
   • Returns: Array of dashboards with URLs.

6. get_dashboard

   • Retrieve a specific dashboard.
   • Inputs:
     • dashboard_id (string): Dashboard ID.
   • Returns: Dashboard details including widgets.

7. query_metrics

   • Retrieve metrics data.
   • 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 timeframe.

8. list_traces

   • Retrieve APM traces.
   • Inputs:
     • query (string): Trace query string.
     • from (number): Start time in epoch seconds.
     • to (number): End time in epoch seconds.
     • limit (optional number): Max traces to return (default 100).
     • sort (optional string): Sort order (default '-timestamp').
     • service (optional string): Filter by service.
     • operation (optional string): Filter by operation.
   • Returns: Array of matching traces.

9. list_hosts

   • Get list of hosts.
   • Inputs:
     • filter (optional string): Search filter.
     • sort_field (optional string): Field to sort by.
     • sort_dir (optional string): Sort direction (asc/desc).
     • start (optional number): Pagination offset.
     • count (optional number): Max hosts (max 1000).
     • from (optional number): UNIX timestamp for search start.
     • include_muted_hosts_data (optional boolean): Include muted hosts info.
     • include_hosts_metadata (optional boolean): Include metadata (version, platform, etc).
   • Returns: Array of hosts with details.

10. get_active_hosts_count

    • Get total number of active hosts.
    • Inputs:
      • from (optional number): Seconds back to count from (default 2h).
    • Returns: Count of active and up hosts.

11. mute_host

    • Mute a host.
    • Inputs:
      • hostname (string): Host name.
      • message (optional string): Muting message.
      • end (optional number): POSIX timestamp for mute end.
      • override (optional boolean): Replace existing mute if true.
    • Returns: Success status and confirmation.

12. unmute_host

    • Unmute a host.
    • Inputs:
      • hostname (string): Host name.
    • Returns: Success status and confirmation.

13. list_downtimes

    • List scheduled downtimes.
    • Inputs:
      • currentOnly (optional boolean): Only active downtimes if true.
      • monitorId (optional number): Filter by monitor ID.
    • Returns: Array of downtimes with details.

14. schedule_downtime

    • Schedule a downtime.
    • Inputs:
      • scope (string): Scope (e.g. 'host:my-host').
      • start (optional number): Start UNIX timestamp.
      • end (optional number): End UNIX timestamp.
      • message (optional string): Downtime message.
      • timezone (optional string): Timezone (e.g. 'UTC').
      • monitorId (optional number): Monitor ID to mute.
      • monitorTags (optional array): Monitor tags for filtering.
      • recurrence (optional object): Recurrence settings:
        • type (string): Recurrence type ('days', 'weeks', 'months', 'years').
        • period (number): Repeat interval (>=1).
        • weekDays (optional array): Days of week (for weekly).
        • until (optional number): UNIX timestamp to end recurrence.
    • Returns: Scheduled downtime details.

15. cancel_downtime

    • Cancel a scheduled downtime.
    • Inputs:
      • downtimeId (number): Downtime ID.
    • Returns: Confirmation of cancellation.

16. get_rum_applications

    • Get all RUM applications.
    • Inputs: None.
    • Returns: List of RUM applications.

17. get_rum_events

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

18. get_rum_grouped_event_count

    • Search, group, and count RUM events by a dimension.
    • Inputs:
      • query (optional string): Query filter (default "*").
      • from (number): Start time.
      • to (number): End time.
      • groupBy (optional string): Grouping dimension (default "application.name").
    • Returns: Grouped event counts.

19. get_rum_page_performance

    • Get page view performance metrics.
    • Inputs:
      • query (optional string): Query filter (default "*").
      • from (number): Start time.
      • to (number): End time.
      • metricNames (array of strings): Metrics to retrieve (e.g., 'view.load_time').
    • Returns: Performance metrics: average, min, max, count.

20. get_rum_page_waterfall

    • Retrieve RUM page waterfall data.
    • Inputs:
      • applicationName (string): Application filter.
      • sessionId (string): Session filter.
    • Returns: Waterfall data for 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)

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"

Installation

Installing via Smithery

To install Datadog MCP Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @winor30/mcp-server-datadog --client claude

Manual Installation

pnpm install
pnpm build
pnpm watch   # for development with auto-rebuild

Usage with Claude Desktop

Add the following to your claude_desktop_config.json:

On MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json

Example configuration:

{
  "mcpServers": {
    "datadog": {
      "command": "/path/to/mcp-server-datadog/build/index.js",
      "env": {
        "DATADOG_API_KEY": "<YOUR_API_KEY>",
        "DATADOG_APP_KEY": "<YOUR_APP_KEY>",
        "DATADOG_SITE": "<YOUR_SITE>" // Optional
      }
    }
  }
}

Or specify via npx:

{
  "mcpServers": {
    "mcp-server-datadog": {
      "command": "npx",
      "args": ["-y", "@winor30/mcp-server-datadog"],
      "env": {
        "DATADOG_API_KEY": "<YOUR_API_KEY>",
        "DATADOG_APP_KEY": "<YOUR_APP_KEY>",
        "DATADOG_SITE": "<YOUR_SITE>" // Optional
      }
    }
  }
}

Debugging

MCP servers communicate over standard input/output, which can be tricky to debug. We recommend using the MCP Inspector. You can run it with:

npm run inspector

The inspector provides a URL to open in your browser for logs and manual requests.

Contributing

Contributions are welcome! Feel free to open an issue or pull request with suggestions, bug reports, or improvements.

License

This project is licensed under the Apache License, Version 2.0.