Gemini CLI is Google's open-source terminal agent, and it speaks standard MCP, so Datadog integration is largely a config-format exercise rather than a capability gap. What's genuinely worth covering here is how Gemini's large context window changes the economics of a wide, exploratory telemetry query — and where its tool-calling behavior diverges from Claude Code enough to matter for an observability workflow specifically.
Installing and Connecting Datadog MCP to Gemini CLI
Gemini CLI reads MCP server definitions from ~/.gemini/settings.json (user-level) or .gemini/settings.json at the project root (project-level, takes precedence when present). The config block:
{
"mcpServers": {
"datadog": {
"command": "npx",
"args": ["-y", "@datadog/datadog-mcp-server"],
"env": {
"DD_API_KEY": "$DD_API_KEY",
"DD_APP_KEY": "$DD_APP_KEY",
"DD_SITE": "datadoghq.com"
}
}
}
}
Gemini CLI supports $VAR_NAME substitution from the calling shell's environment — export the values beforehand:
export DD_API_KEY="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
export DD_APP_KEY="yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
Launch and check the MCP connection with the built-in command:
gemini
/mcp
This lists configured servers and their connection state, plus the tools each one exposes — /mcp in Gemini CLI is more verbose by default than the equivalent in some other clients, printing full tool descriptions and parameter schemas, which is genuinely useful the first time you're figuring out exactly what the Datadog server can do without reading npm package source.
Confirm actual auth works, not just process startup:
List Datadog monitors currently in an Alert state.
If you're behind a corporate proxy or a locked-down network, note that npx needs to fetch the package on first run unless it's already cached locally — pre-install it if your environment restricts outbound npm registry access:
npm install -g @datadog/datadog-mcp-server
and point command at the installed binary instead of npx if that's the case.
Tips
- Run/mcpright after connecting — Gemini CLI's verbose tool listing is a fast way to see the server's exact tool names and parameters without digging through documentation.
- Pre-install the MCP server package withnpm install -gif your network blocks on-demandnpxfetches, and reference the global binary directly in config.
- Project-level.gemini/settings.jsonoverrides user-level~/.gemini/settings.json— check which one actually has your Datadog block if the server isn't showing up as expected.
Running Log Searches and Metric Aggregations from Gemini CLI
The query patterns are identical to any other MCP client — Gemini CLI is just the interface translating your prompt into the same Datadog Logs Search API and Metrics Query API calls. What differs in practice is how Gemini handles a large returned payload: its context window (1M tokens on Gemini 2.5 Pro and larger context configurations, depending on model and tier) tolerates pulling back a much larger raw result set than most other agents before you need to worry about truncation or summarization loss.
Practical implication: you can be a bit more generous with time windows on exploratory (non-urgent) queries without the agent silently dropping data to fit context:
Pull all error-level logs for service:billing-service over the last
24 hours, and summarize the top 5 distinct error patterns with counts
and example log lines for each.
For a service with moderate log volume, this kind of 24-hour sweep is exactly the sort of query that would risk truncation or a lossy summary in a smaller-context agent, but Gemini CLI's window gives it more room to actually read through the full result set before summarizing. That said, "more context room" doesn't mean "ignore Datadog's own rate limits and cost implications" — see the cost topic earlier in this module; the API-side constraints don't change just because your client can hold more tokens.
Metric aggregation, same syntax as always:
avg:trace.express.request.duration{service:billing-service} by {resource_name}
Get p95 latency for billing-service by resource, last 6 hours, and
flag any resource where p95 exceeds 500ms.
Gemini CLI handles this kind of "fetch then apply a threshold filter" prompt well — it pulls the full series, then reasons over it in the response rather than needing a separate filtering tool call, since the filtering logic isn't something Datadog's query API does inline for percentile-per-resource-with-threshold in one call.
Tips
- Take advantage of Gemini's larger context window for wide exploratory summarization queries (e.g., "summarize error patterns over 24 hours") — but keep production-incident queries tightly time-scoped regardless, since Datadog's own API costs and rate limits don't scale with your client's context size.
- When asking for a threshold-based flag ("p95 exceeds 500ms"), let Gemini fetch the raw series and apply the filter in its reasoning rather than expecting a single Datadog query to do combined aggregation-plus-threshold — that filtering step happens client-side, not in Datadog's query language.
- Ask for example log lines alongside error-pattern counts — a count without a sample line is much harder to verify against the actual Datadog UI later.
Practical Example: Finding the Service Responsible for an Error Rate Spike
Scenario: a shared "error budget" dashboard shows overall error rate across the platform spiking at roughly 09:15 UTC, but the spike isn't attributed to a single service in the top-line view — you need to find which service actually drove it.
Step 1 — get an error count breakdown by service across the whole platform for the spike window:
Search logs for status:error across all services between 09:00 and
09:30 UTC today, and give me a count grouped by service.
This should surface a clear outlier — say inventory-sync jumps from a baseline of ~5 errors/hour to 400+ in that 30-minute window, while every other service stays flat.
Step 2 — narrow into that service's error content:
Search logs for service:inventory-sync status:error between 09:00 and
09:30 UTC, group by @error.message, and show the top 3 messages with
counts.
Suppose the dominant message is a connection timeout to a downstream dependency — Timeout connecting to warehouse-api after 5000ms.
Step 3 — check whether the downstream dependency itself shows the actual problem:
Check the status of any monitors related to warehouse-api, and get
avg:trace.express.request.duration{service:warehouse-api} for the
same 09:00-09:30 window.
If warehouse-api shows a latency or availability degradation in the same window, you've found the causal chain: warehouse-api degraded → inventory-sync timed out calling it → error rate spike on the shared dashboard attributed broadly to "the platform" until scoped.
Step 4 — check for a common trigger:
Were there any deploys or infrastructure changes to warehouse-api or
its underlying hosts around 09:00 UTC?
This closes the loop — either a deploy caused it (rollback is your immediate action) or it's an infrastructure issue (host resource exhaustion, network partition, a dependency of the dependency) that needs a different remediation path entirely.
Tips
- When a shared or platform-wide dashboard shows a spike without service attribution, your very first query should always be a group-by-service breakdown — don't guess which service is responsible.
- A timeout error message pointing at a downstream service name is your strongest signal to pivot the investigation to that downstream service's own metrics and monitors next.
- Always check for a deploy or infra change correlated with the timestamp before writing up root cause — "it broke because of X" without a corroborating change event is speculation, not a finding.
Comparing Datadog MCP Output Between Gemini CLI and Claude Code
Both agents call the identical Datadog MCP server and get identical raw tool results back — the divergence is entirely in how each client processes and presents that data, and it's worth knowing the shape of the difference before you pick one for a given task.
Raw data fidelity on large results. Gemini CLI's larger context window means it's less likely to need to truncate or pre-summarize a large log/metric payload before reasoning over it, which matters for wide exploratory queries (see above). Claude Code's context window is smaller by comparison (though still large in absolute terms across current model versions), so on a very large payload it's more likely to summarize as it goes rather than holding the entire raw result — usually fine, occasionally means a subtler outlier buried in the middle of a large result set gets less attention.
Tool-call transparency. Claude Code, especially inside the VS Code extension, tends to show a cleaner structured view of each tool call and its arguments inline, which is genuinely nicer for the "verify the query before trusting the answer" habit this whole module keeps recommending. Gemini CLI's /mcp and tool-output display is more raw/verbose — everything is there, but you're reading closer to unformatted JSON rather than a rendered summary.
Code correlation depth. The trace-to-code pivot (finding the exact function behind a slow span) is noticeably smoother in Claude Code + VS Code specifically because of how tightly that combination integrates file search and navigation into the same UI surface as the chat. Gemini CLI can do the same correlation — its file tools are perfectly capable — but it's a more manual, more prompt-driven process; you'll type more explicit file/directory hints rather than letting the agent roam.
Cost model differences are separate from Datadog's own costs. Model API costs (Gemini vs Claude) are an entirely separate line item from Datadog API usage costs discussed earlier in this module — don't conflate the two when budgeting. A long, exploratory Gemini CLI session over a 24-hour log sweep costs more in model tokens precisely because it's ingesting more raw data, even though the Datadog-side query itself is a single API call either way.
For day-to-day incident response where speed of trace-to-code correlation matters most, Claude Code (particularly in VS Code) is the stronger default. For wide exploratory analysis over large log/metric datasets — postmortem research, trend analysis across weeks of data — Gemini CLI's context headroom is a genuine practical advantage.
Tips
- Reach for Gemini CLI specifically when a query needs to reason over a large raw payload without losing detail to context-driven summarization — long log sweeps, multi-week trend analysis.
- Reach for Claude Code (ideally in VS Code) when the task is fast incident response requiring tight trace-to-code correlation — its tool-call transparency and code navigation are smoother for that specific loop.
- Keep model-token cost and Datadog API cost as separate budget lines; a client choice that increases one doesn't necessarily affect the other.
Tips
Tips
- Use$VAR_NAMEsubstitution in.gemini/settings.jsonand keep secrets in shell environment only; check project-level config isn't silently overriding user-level config.
- Lean on Gemini's larger context window for wide exploratory sweeps, but keep incident-response queries tightly time-scoped regardless — Datadog's own rate limits and costs are unaffected by client context size.
- When an error spike shows on a shared or platform-wide view, always start with a group-by-service breakdown before drilling into any single service's logs.
- Pick the agent by task shape: Claude Code (VS Code) for fast trace-to-code incident response, Gemini CLI for large-payload exploratory analysis.