🔍 Scout Research Report

Triggered by @pelikhan

Executive Summary

The Datadog MCP server provides AI agents with comprehensive access to Datadog's observability platform through the Model Context Protocol. Creating a shared agentic workflow involves wrapping this server with proper configuration, authentication, and tool permissions similar to existing MCP integrations in gh-aw (like Tavily, Context7, etc.).

Click to expand detailed findings

Research Findings

What is the Datadog MCP Server?

The Datadog MCP server is a Model Context Protocol implementation that bridges AI agents with Datadog's monitoring and observability platform. It provides natural language access to:

Log queries and analysis - Query and filter application logs
Metrics retrieval - Access performance metrics and time-series data
Monitor management - Check monitor status and alert configurations
Incident tracking - Query and manage incidents
Dashboard access - Retrieve dashboard data and visualizations

Available implementations:

@ndevvy/mcp-server-datadog - Community implementation
@winor30/mcp-server-datadog - Alternative community version

Integration Pattern for gh-aw

Based on existing MCP integrations in .github/workflows/shared/mcp/, the Datadog wrapper should follow this structure:

File: .github/workflows/shared/mcp/datadog.md

---
mcp-servers:
  datadog:
    command: "npx"
    args: ["`@ndevvy/mcp-server-datadog`"]
    env:
      DD_API_KEY: "${{ secrets.DD_API_KEY }}"
      DD_APP_KEY: "${{ secrets.DD_APP_KEY }}"
      DD_SITE: "datadoghq.com"  # or datadoghq.eu, us3.datadoghq.com, etc.
    allowed:
      - query_logs
      - get_metrics
      - list_monitors
      - get_incidents
      - query_dashboards
---

Authentication Requirements

The Datadog MCP server requires two authentication tokens from Datadog:

API Key (DD_API_KEY) - Primary authentication credential
Application Key (DD_APP_KEY) - Application-specific access key
Site Parameter (DD_SITE) - Datadog region (e.g., datadoghq.com, datadoghq.eu)

These should be stored as GitHub repository secrets and passed via environment variables.

Tool Permissions Strategy

Following the pattern from other MCP servers in gh-aw, the allowed array should specify permitted tools:

Recommended tool subset (start conservative, expand as needed):

query_logs - Essential for log analysis
get_metrics - Core metric retrieval
list_monitors - Monitor status checks
get_incidents - Incident investigation

Additional tools (add based on use case):

query_dashboards - Dashboard data access
create_incident - Incident management (write operation)
update_monitor - Monitor configuration (write operation)

Network Configuration

If using the Claude engine with network restrictions (similar to Playwright integration), add Datadog domains to the allowed list:

network:
  allowed:
    - defaults
    - "*.datadoghq.com"
    - "api.datadoghq.com"

Example Workflow Usage

---
on:
  schedule:
    - cron: "0 * * * *"  # Hourly monitoring check
permissions:
  contents: read
  issues: write
engine: claude
imports:
  - shared/mcp/datadog.md
safe-outputs:
  create-issue:
    title-prefix: "[monitoring] "
    labels: [observability, automated]
---

# Monitoring Health Check

Check Datadog for any critical alerts or incidents in the last hour.

Query recent logs for ERROR level messages, review active monitors, 
and summarize any ongoing incidents. Create an issue if critical 
issues are detected.

Recommendations

Start with read-only operations - Initially limit tools to query/read operations (query_logs, get_metrics, list_monitors)
Use environment-based configuration - Store API keys as GitHub secrets, configure site parameter based on Datadog region
Follow existing MCP patterns - Model the implementation after Context7, Tavily, or other existing MCP integrations in .github/workflows/shared/mcp/
Add network permissions if using Claude - Include Datadog API domains in network allowlist
Document tool capabilities - Provide clear inline documentation about available tools and their purposes
Consider rate limiting - Datadog API has rate limits; workflows should be designed accordingly
Implement error handling - Add guidance for handling API errors, missing credentials, or rate limit scenarios

Key Sources

Suggested Next Steps

Create .github/workflows/shared/mcp/datadog.md following the pattern above
Add repository secrets for DD_API_KEY and DD_APP_KEY
Create a test workflow to validate the integration
Document available tools and their parameters
Add example workflows demonstrating monitoring use cases
Consider adding to the documentation in docs/ directory

AI generated by Scout

Datadog mcp #1648

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions