Datadog MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DD_API_KEY | Yes | Datadog API Key used for authentication with Datadog's API | |
| DD_APP_KEY | Yes | Datadog Application Key used for authorization and is tied to a specific user account |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_ci_pipelinesC | List CI pipelines from Datadog CI Visibility with optional filtering |
| get_pipeline_fingerprintsC | Get unique pipeline fingerprints for specific repositories/services |
| get_logsB | Search and retrieve logs from Datadog with flexible filtering parameters. Similar to get_metrics but for log data. |
| get_logs_field_valuesB | Get possible values for a specific log field to understand filtering options |
| get_teamsB | Get Datadog teams and their members |
| get_metricsB | Execute metric queries on Datadog. Specify the metric name and optional filters/aggregations to build and execute the query. |
| get_metric_fieldsB | Get available fields/tags for a specific metric from Datadog to help with aggregation queries |
| get_metric_field_valuesB | Get all possible values for a specific field of a metric from Datadog to discover available dimensions |
| list_metricsA | List all available metrics from Datadog. Useful for discovering metrics before querying them with get_metrics. |
| list_service_definitionsA | List all service definitions from Datadog. Service definitions describe the structure, ownership, and metadata of services in your organization. |
| get_service_definitionB | Retrieve the definition of a specific service from Datadog. Service definitions contain metadata, ownership, and configuration details for individual services. |
| list_monitorsC | List all monitors from Datadog. Monitors are used for alerting on metrics, logs, and other data. |
| list_slosC | List Service Level Objectives (SLOs) from Datadog. SLOs define service level targets and track performance against those targets. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools have distinct purposes, but there is some potential for confusion between get_logs and get_metrics, as both involve data retrieval with filtering, though they target different data types (logs vs. metrics). The get_metric_fields and get_metric_field_values tools are also closely related, but their descriptions clarify the distinction between listing fields and their values.
Tool names follow a consistent verb_noun pattern throughout, with clear prefixes like 'get_' for retrieval actions and 'list_' for listing actions. This consistency makes it easy to predict tool functionality and navigate the set without confusion.
With 13 tools, the count is well-scoped for a Datadog integration, covering key areas like logs, metrics, services, monitors, and SLOs. Each tool appears to serve a specific purpose without unnecessary duplication, fitting the server's monitoring and observability domain appropriately.
The tool set provides good coverage for data retrieval and listing in Datadog's core areas, but there are minor gaps such as the lack of update or delete operations for resources like monitors or SLOs, which might limit full lifecycle management. However, the available tools support essential discovery and querying workflows effectively.