search_logsLABSCO SUMMARY
Ask the incident question, not the query builder.
Logs and spans come back in the same conversation, and the span aggregation answers "which service is slow" without anything being exported to a notebook first.
What it is
A read layer over the Datadog API for three questions: what the logs say, what the trace spans say, and what the spans look like once grouped. Each search takes a query string and a time range given as UNIX timestamps, and pages through results with a cursor.
What you get
- Logs searched by query over a time range, returned with service, host, status, tags and the message, trimmed to a readable length
- The HTTP attributes pulled out beside each log line - method, URL, status code and error
- Trace spans searched the same way, with service, resource name, duration, host, environment and type
- Spans aggregated by a dimension you choose, so the answer comes back as a shape rather than a list
- Cursor paging, 25 results by default and up to 1,000 per page
- A default window of the last 15 minutes when you do not give one
Requirements
A Datadog account with API access, and its credentials supplied to the server through your client config. Searches run against Datadog's logs and spans APIs, so your own retention settings decide how far back a query can reach.
Setup effort
Build from source
USE CASES
Working out what broke in the last quarter hour
Search the logs without a time range and take the default fifteen-minute window, then read the status codes and errors that came back with each line.
Following an error from the log line into the trace
Search the spans for the same service and window, so resource name and duration sit next to the log message.
Finding which service the latency is in
Aggregate the spans by service instead of paging through them, so the answer is a distribution rather than 25 rows.
Pulling a full result set out of a busy window
Raise the page limit and follow the cursor, so a thousand-line window comes back in order rather than cut off at the default 25.
3 tools
Listed in project docs. Your client may show a different list.
search_spansaggregate_spansBEFORE YOU INSTALL
What to know first
Tools you get
3 tools named in the project's documentation.
Requires
- Node.js with npm or pnpm, to build it from the clone — or Docker, for the Docker route
- DD_API_KEY in your environment
- DD_APP_KEY in your environment
INSTALLATION
Connect your client
Server setup
git clone https://github.com/tuno-dev/datadog-mcp
cd datadog-mcp
npm install
npm run buildMCP Clients
Claude Desktop — local build
{
"mcpServers": {
"datadog": {
"command": "node",
"args": [
"<YOUR_PATH_TO_DATADOG_MCP>/build/index.js"
],
"env": {
"DD_API_KEY": "<YOUR_DATADOG_API_KEY>",
"DD_APP_KEY": "<YOUR_DATADOG_APP_KEY>"
}
}
}
}Claude Desktop — Docker
Build the image from a clone of the repository first:
git clone https://github.com/tuno-dev/datadog-mcp
cd datadog-mcp
docker build -t datadog-mcp .Then add this to claude_desktop_config.json:
{
"mcpServers": {
"datadog": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"DD_API_KEY",
"-e",
"DD_APP_KEY",
"datadog-mcp"
],
"env": {
"DD_API_KEY": "<YOUR_DATADOG_API_KEY>",
"DD_APP_KEY": "<YOUR_DATADOG_APP_KEY>"
}
}
}
}VS Code
{
"servers": {
"datadog": {
"command": "node",
"args": [
"<YOUR_PATH_TO_DATADOG_MCP>/build/index.js"
],
"env": {
"DD_API_KEY": "<YOUR_DATADOG_API_KEY>",
"DD_APP_KEY": "<YOUR_DATADOG_APP_KEY>"
}
}
}
}