Skip to main content
Glama
MCP Datadog Server

MCP Datadog Server

by micaelmalta

MCP Datadog Server

A Model Context Protocol (MCP) server that exposes Datadog APIs to AI assistants and code editors via tools.

Overview

The server provides MCP tools for:

  • Metrics – Query metrics, metadata, list metrics

  • Logs – Search logs, get log details, aggregate logs

  • Events – Search events, get event details

  • Monitors – List monitors, get status, search monitors

  • APM/Traces – Query traces, service health, service dependencies

  • Services – Service dependencies (single and multi-environment)

Related MCP server: MCP Datadog Server

Quick Start

Prerequisites

  • Node.js 22+

  • npm

No clone or install needed. Add the server to your MCP client (e.g. Cursor, Claude) using stdio and run it from GitHub:

{
  "datadog": {
    "type": "stdio",
    "command": "npx",
    "args": ["-y", "github:micaelmalta/mcp-server-datadog"],
    "env": {
      "DATADOG_API_KEY": "your_api_key",
      "DATADOG_APP_KEY": "your_app_key"
    }
  }
}

Set DATADOG_API_KEY and DATADOG_APP_KEY (and optionally DATADOG_SITE, default datadoghq.com). Restart the client so the tools appear.

To try from the terminal:

DATADOG_API_KEY=your_key DATADOG_APP_KEY=your_app_key npx -y github:micaelmalta/mcp-server-datadog

Run from source

For development or a fixed install:

git clone https://github.com/micaelmalta/mcp-server-datadog.git
cd mcp-server-datadog
npm install
cp .env.example .env

Edit .env and set DATADOG_API_KEY and DATADOG_APP_KEY. Then:

npm start
# or with NODE_ENV=local: npm run dev

In your MCP config, use stdio with node and the path to the entry point:

{
  "datadog": {
    "type": "stdio",
    "command": "node",
    "args": ["/path/to/mcp-server-datadog/src/index.js"],
    "env": {
      "DATADOG_API_KEY": "your_api_key",
      "DATADOG_APP_KEY": "your_app_key"
    }
  }
}

Tools

Tool

Purpose

query_metrics

Query metrics data

get_metric_metadata

Get metric metadata

list_metrics

List metrics

search_logs

Search logs with filter

get_log_details

Get a single log by ID

aggregate_logs

Aggregate logs

search_events

Search events

get_event_details

Get event by ID

list_monitors

List monitors

get_monitor_status

Get monitor status

search_monitors

Search monitors

query_traces

Query APM traces

get_service_health

Service health metrics

get_service_dependencies

Service dependencies

get_service_dependencies_multi_env

Dependencies across environments

Example prompts: "Show error logs from service X in the last hour" → search_logs. "What's CPU usage on production?" → query_metrics. "How is the API service doing?" → get_service_health.

Time ranges: Use ISO 8601 or Unix timestamps (seconds for metrics/events, milliseconds for logs/APM). Filters: Datadog syntax, e.g. service:api, status:error, env:production.

Project structure

mcp_datadog/
├── src/
│   ├── clients/     # Datadog API clients (SDK-based)
│   ├── tools/       # MCP tool definitions and handlers
│   ├── utils/       # Environment, errors, logger, toolErrors
│   └── index.js     # Server entry point
├── test/            # Vitest tests and fixtures
│   ├── benchmark/   # Tool handler benchmarks (mocked)
│   ├── mocks/      # Datadog SDK mocks
│   └── ...
├── docs/            # Additional documentation
└── package.json

Tech stack: Node.js 22+, JavaScript (ESM), JSDoc, Vitest, ESLint, Prettier, @modelcontextprotocol/sdk, @datadog/datadog-api-client.

Development

Commands

Command

Description

npm start

Run server

npm run dev

Run with NODE_ENV=local

npm test

Run tests

npm run test:watch

Tests in watch mode

npm run test:coverage

Tests with coverage

npm run test:e2e

E2E tests (real Datadog API; see below)

npm run benchmark

Run tool-handler benchmark (mocked)

npm run lint

Lint

npm run lint:fix

Fix lint issues

npm run format

Format with Prettier

npm run format:check

Check formatting (used in CI)

npm run validate

Lint + test

API client pattern

Clients return { data, error }:

const { data, error } = await client.queryMetrics(query, from, to);
if (error) {
  console.error(error.message, error.statusCode);
} else {
  console.log(data);
}

CI

GitHub Actions (.github/workflows/ci.yml) runs on push and pull requests to main/master: format check (prettier --check), lint (ESLint), and tests. Same commands locally: npm run format:check && npm run lint && npm test.

Testing

Tests use Vitest with mocked Datadog SDK (test/mocks/datadogApi.js) and fixtures in test/fixtures/. Run npm test before committing.

E2E tests (test/e2e/) run against the real Datadog API. They are skipped unless RUN_E2E=1 and real DATADOG_API_KEY/DATADOG_APP_KEY are set in .env. Example: RUN_E2E=1 npm run test:e2e. Use this to verify that document-center production error logs are visible (e.g. logsDocumentCenter.e2e.test.js).

Operational notes

  • Logging: Tool calls are logged to stderr as JSON lines (tool, durationMs, slow). Optional: set MCP_SLOW_TOOL_MS (default 2000) to mark slow calls. Some clients also write to mcp_datadog.log (see src/utils/logger.js).

  • Rate limiting: The server does not rate limit; high tool usage can hit Datadog API limits.

  • Troubleshooting: Tools missing → check MCP config and env vars, restart client. 403/404 → permissions or plan. See Troubleshooting for "no data" cases.

Troubleshooting

Search returns 0 logs but I expect data

If search_logs (or aggregate_logs) returns no results for a service you know has traffic:

  1. Same Datadog org – The MCP server uses DATADOG_API_KEY, DATADOG_APP_KEY, and optionally DATADOG_SITE. Ensure these point to the same Datadog org and site where your app (e.g. document-center) sends logs.

  2. Compare in Datadog – In Datadog Logs Explorer, run the same filter and time range (e.g. service:document-center env:production status:error, last 7 days). If you see logs there but not via MCP, the env/site or keys are likely different.

  3. Exact filter syntax – Confirm the attribute names and values your app sends (e.g. service, env, status). Try without env:production or with env:prod, or search only service:document-center to see if any logs appear.

  4. Retention and indexes – Logs must be in an index that your API key can read; check log indexes and retention.

Documentation

  • README (this file) – Setup, usage, structure.

  • CLAUDE.md – Project conventions and patterns for contributors.

  • docs/ – Additional guides (e.g. performance, security) when present.

Contributing

  1. Follow existing style (npm run lint, npm run format).

  2. Add tests for new behavior.

  3. Run npm run validate before committing.

  4. Use conventional commits: feat, fix, docs, chore, refactor, test.

Available Tools

16 tools
aggregate_logsB

Aggregate log data for a time range using the specified aggregation type (count, avg, percentile, min, max, sum). Useful for statistical analysis of logs.

Inputs: to (required), from (required), filter (required), aggregationType (required).

get_apm_service_dependenciesA

Get the APM service dependency map for a service over a time range, showing which services it calls and which services call it based on trace data. Useful for understanding service interactions.

Inputs: to (required), from (required), serviceName (required).

get_event_detailsA

Get detailed information about a specific event. Returns full event data including timestamps, comments, and metadata.

Inputs: eventId (required).

get_log_detailsA

Get detailed information about a specific log entry. Returns full log data including all attributes and metadata.

Inputs: logId (required).

get_metric_metadataA

Retrieve metadata about a Datadog metric including units, description, tags, and integration information.

Inputs: metricName (required).

get_monitor_statusA

Get detailed status information for a specific monitor, including alert status, downtime information, and historical state changes.

Inputs: monitorId (required).

get_service_dependenciesB

Get service dependencies for a given environment. Returns all services and their relationships in the specified environment. Useful for understanding service architecture and dependencies.

Inputs: env (required), serviceName.

get_service_dependencies_multi_envA

Get service dependencies across multiple environments. Returns service relationships for each specified environment, useful for comparing architectures across prod, staging, dev, etc.

Inputs: envs (required).

get_service_healthA

Get health metrics for a service including latency, error rate, and throughput. Useful for monitoring service performance and health status.

Inputs: to (required), from (required), serviceName (required), env.

list_metricsA

List available Datadog metrics, optionally filtered by a search query. Useful for discovering what metrics are available in your environment.

Inputs: limit, query.

list_monitorsB

List all Datadog monitors with optional filtering by status and tags. Useful for getting an overview of all monitors in your account.

Inputs: tags, status.

query_metricsA

Query Datadog metrics data for a specified time range. Returns time-series data with values aggregated over the specified period.

Inputs: to (required), from (required), metricName (required), filter.

query_tracesA

Query Datadog APM traces for a service. Returns trace data with latency information and span details. Useful for performance debugging.

Inputs: to (required), from (required), serviceName (required), limit, +1 more.

search_eventsA

Search for events in Datadog. Events can include monitor alerts, deployments, integrations, and custom events. Useful for understanding system changes and incidents.

Inputs: to (required), from (required), query (required), priority.

search_logsB

Search Datadog logs with filters and a time range. Returns log entries matching the query, useful for debugging and log analysis.

Inputs: to (required), from (required), filter (required), limit.

search_monitorsA

Search for monitors by name or other criteria. Useful for finding specific monitors when you don't remember the exact ID.

Inputs: query (required), tags.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    B3.4/5.0

    Scored across 16 tools

    Disambiguation3/5

    Most tools are distinct, but the three service dependency tools (get_apm_service_dependencies, get_service_dependencies, get_service_dependencies_multi_env) have highly overlapping purposes and could be easily misselected by an agent. Other tools like list_metrics vs query_metrics are clearly separated, but the dependency trio introduces ambiguity.

    Naming Consistency4/5

    Tool names consistently use snake_case with a verb_noun pattern (get_, list_, search_, query_, aggregate_). The verbs are predictable and align with their actions. Minor deviation: get_ prefixes are used for both single items (get_metric_metadata) and collections (get_service_dependencies), but this is not overly confusing.

    Tool Count4/5

    16 tools is on the higher end of the recommended range, but it covers multiple Datadog features (metrics, logs, events, monitors, APM, dependencies) reasonably. Each tool serves a distinct function within these domains, so the count is justified, though it feels slightly heavy for a single server.

    Completeness3/5

    The set provides broad read-only coverage for Datadog's main observability areas, but it lacks any write operations (create, update, delete monitors, events, etc.). There are also gaps like dashboards and trace detail. The service dependency trio is overrepresented while monitor management is incomplete, leaving agents unable to perform lifecycle actions.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      Enables AI assistants to interact with DataDog's observability platform through a standardized interface. Supports monitoring infrastructure, managing events, analyzing logs and metrics, and automating operations like alerts and downtimes.
      1
      MIT
    • A
      license
      C
      quality
      C
      maintenance
      Enables interaction with Datadog APIs through automatically generated tools from Postman collections. Supports monitoring operations, log management, metrics submission, and other Datadog functionality through natural language.
      100
      29 npm
      Apache 2.0
    • A
      license
      Not graded
      quality
      D
      maintenance
      Enables interaction with Datadog APIs through natural language, supporting full CRUD operations on metrics, monitors, dashboards, logs, infrastructure, and more.
      4
      MIT
    • A
      license
      Not graded
      quality
      D
      maintenance
      Enables AI assistants to interact with Datadog's observability platform via natural language, covering metrics, logs, APM, monitors, dashboards, incidents, and infrastructure.
      2,048 npm
      1
      MIT