Datadog Logs MCP Server
# Datadog Logs MCP Server
An MCP (Model Context Protocol) server for searching Datadog logs via HTTP.
## Features
- Search Datadog logs with customizable queries
- Specify time ranges for log searches
- Control result limits
- Runs as an HTTP server on port 5000
## Prerequisites
- Docker and Docker Compose
- Datadog API Key
- Datadog Application Key
## Setup
1. Copy the example environment file and add your Datadog credentials:
```bash
cp .env.example .env
```
2. Edit `.env` and add your actual Datadog keys:
```
DD_API_KEY=your_actual_api_key
DD_APPLICATION_KEY=your_actual_application_key
PORT=4000
```
## Running with Docker Compose
Start the server:
```bash
docker-compose up
```
The server will be available at `http://localhost:5000`
To run in detached mode:
```bash
docker-compose up -d
```
To stop the server:
```bash
docker-compose down
```
## API Endpoints
### SSE Connection
- **GET** `/sse` - Establish SSE connection for MCP communication
### Message Endpoint
- **POST** `/messages` - Send MCP protocol messages
## MCP Tool: search_logs
Search Datadog logs with the following parameters:
- `query` (required): Log search query (e.g., "env:prd AND service:pms-connectors")
- `from` (required): Start time (e.g., "now-10m", "2024-01-01T00:00:00Z")
- `to` (required): End time (e.g., "now", "2024-01-01T01:00:00Z")
- `limit` (optional): Maximum number of logs to return (default: 10)
## Example Usage
The server will search Datadog logs using the API endpoint:
```
POST https://api.datadoghq.com/api/v2/logs/events/search
```
With the query parameters provided through the MCP tool invocation.
## Development
To build locally without Docker:
```bash
npm install
npm run build
npm start
```
## Environment Variables
- `DD_API_KEY`: Your Datadog API key (required)
- `DD_APPLICATION_KEY`: Your Datadog application key (required)
- `PORT`: Server port (default: 5000)
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose targeting different data sources: Clickhouse database queries, Cloudbeds PMS API for reservations, and Datadog logs search. There is no overlap in functionality or ambiguity about which tool to use for each specific task.
All three tools follow a consistent verb_noun pattern with 'search_' prefix followed by the target resource (clickhouse, cloudbeds_pms, logs). The naming is perfectly uniform and predictable across the entire tool set.
With only 3 tools, the server feels somewhat thin for a 'Datadog Logs MCP Server' that also includes non-Datadog tools. While the tools are well-defined, the scope appears broader than just logs, and the count may be insufficient for comprehensive coverage of the implied domains.
For a server named 'Datadog Logs', having only one Datadog-specific tool (search_logs) with two unrelated tools creates significant gaps. The Clickhouse tool is unimplemented, and the Cloudbeds tool seems out of scope, leaving the core Datadog functionality incomplete and fragmented.