Skip to main content
Glama
TANTIOPE

Datadog MCP Server

events

Retrieve, create, and analyze Datadog events with actions for listing, searching, aggregating, and timeseries. Filter monitor alerts by transition type to count real state changes.

Instructions

Track Datadog events. Actions: list, get, create, search, aggregate, top, timeseries, incidents, discover, histogram. For monitor alerts, use tags: ["source:alert"].

IMPORTANT — re-evaluation vs transition:

  • source:alert events INCLUDE renotifies and re-evaluations (every Datadog re-evaluation of an alerting monitor emits an event). A "how many times did monitor X fire" question answered with source:alert alone over-counts.

  • To restrict to real state transitions, pass transitionType (e.g. ["alert","alert recovery"]). This appends @monitor.transition.transition_type:(...) to the query and matches the design's live investigation.

  • For a fires-only numeric count rooted in a single monitor ID, prefer the higher-level primitive monitors action=history — it returns {transitions, count, meta} with the same filter applied for you.

transitionType: Optional array of monitor transition types (alert, alert recovery, warning, warning recovery, no data, no data recovery, renotify). Empty array is treated as undefined. top: Generic event grouping by any fields (groupBy parameter). Returns groups ranked by count with optional context breakdown.

  • Example: {groupBy: ["service"], message: "...", service: "api", total_count: 50, by_context: [{context: "queue:X", count: 30}]}

  • Use for deployments, configs, custom events, or monitor alerts

  • Returns "message" field (event title), NOT monitor name (use monitors tool for real names)

  • total_count includes renotifies when source:alert is used without transitionType — see monitors action=history for fires-only counts discover: Returns available tag prefixes from events. aggregate: Custom groupBy, returns pipe-delimited keys. search: Full event details. timeseries: Time-bucketed trends with interval. incidents: Deduplicate alerts with dedupeWindow. histogram: Bucket events by local hour_of_day / day_of_week / day_of_month in the requested IANA timezone (DST-safe). Pass bucket_by (required) and optional timezone (default UTC) and cursor (for continuation). Caps at limits.maxEventsForHistogram (default 5000); when reached returns bucketCountIncomplete:true + nextCursor.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform
idNoEvent ID (for get action)
queryNoSearch query
fromNoStart time (ISO 8601, relative like "1h", or Unix timestamp)
toNoEnd time (ISO 8601, relative like "1h", or Unix timestamp)
priorityNoEvent priority
sourcesNoFilter by sources
tagsNoFilter by tags
limitNoMaximum number of events to return (default: 50)
titleNoEvent title (for create)
textNoEvent text (for create)
alertTypeNoAlert type (for create)
groupByNoFields to group by (for aggregate and top actions). Top: custom fields like ["service"], ["user"]. Aggregate: monitor_name, priority, alert_type, source. Default for top: ["monitor_id"]
cursorNoPagination cursor from previous response
intervalNoTime bucket interval for timeseries: 1h, 4h, 1d (default: 1h)
dedupeWindowNoDeduplication window for incidents: 5m, 15m, 1h (default: 5m)
enrichNoEnrich events with monitor metadata (slower, adds monitor details)
contextTagsNoTag prefixes for context breakdown in top action (default: queue, service, ingress, pod_name, kube_namespace, kube_container_name)
maxEventsNoMaximum events to fetch for grouping in top action (default: 5000, max: 5000). Higher = more accurate but slower
transitionTypeNoFilter events by monitor state transition type. When set, restricts results to events with @monitor.transition.transition_type matching any value. Use ["alert","alert recovery"] to count real fires/recoveries and skip renotifies. Empty array is treated as undefined (no filter). For a fires-only count by monitor ID, prefer monitors action=history.
bucket_byNoBucket dimension for histogram action: hour_of_day (0-23), day_of_week (0=Sun..6=Sat), day_of_month (1-31).
timezoneNoOptional IANA timezone (e.g. "UTC", "Europe/Paris"). DST-safe. For histogram: controls hour/day bucketing (default: UTC). For search/aggregate/top/incidents read actions: adds sibling *Local ISO 8601 strings (e.g. timestampLocal) next to existing timestamps. Omit for byte-identical legacy shape.
fieldsNoSearch action only: return only these event fields. Allowed values: id, title, message, timestamp, priority, source, tags, alertType, host, monitorId, monitorInfo, monitorMetadata (only populated when enrich=true). Default: full event.
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full behavioral disclosure weight. It explains that source:alert includes renotifies, transitionType filters transitions, top returns message field not monitor name, histogram has limits and incomplete markers, and enrich is slower. Lacks details on create action behavior but overall strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-structured with sections for actions, important notes, and action-specific details. It is front-loaded with the core purpose and overall usage guidelines. Every sentence adds value, though some redundancy exists (e.g., transitionType explanation repeated).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 23 parameters, no output schema, and complex semantics (e.g., transition filtering, histogram limits), the description is remarkably complete. It covers action purposes, parameter interactions, default values, edge cases (empty array), and behavior nuances (total_count includes renotifies, bucketCountIncomplete).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. The description adds significant value beyond schema: it explains transitionType filter behavior, default contextTags, bucket_by options, timezone DST-safety, and differences between top and aggregate. Elevates understanding beyond parameter descriptions alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Track Datadog events' and lists all 10 supported actions. It provides specific details on how to handle monitor-related events, such as using tags ["source:alert"] and transitionType. It distinguishes the tool from siblings like monitors by directing users to monitors action=history for fires-only counts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells users when to use this tool vs alternatives: 'For a fires-only numeric count... prefer the higher-level primitive monitors action=history'. It also explains the meaning of source:alert and transitionType, and provides guidance on when to use top vs aggregate vs histogram actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TANTIOPE/datadog-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server