OpenCode is the open-source, terminal-first agent that a lot of teams run when they want an MCP-capable coding assistant without a vendor lock-in on the model provider. It supports the same MCP client spec as Claude Code, so Datadog MCP works the same way underneath — but OpenCode's tool-call visibility and permission model are different enough to change how you'd actually run an investigation day to day. This topic covers setup, the core query workflow, a full worked example, and where OpenCode currently falls short of Claude Code for this specific use case.
Installing and Connecting Datadog MCP to OpenCode
OpenCode reads MCP server config from opencode.json at the project root (or ~/.config/opencode/opencode.json for global config that applies across projects). The shape mirrors the standard MCP stdio server definition:
{
"mcp": {
"datadog": {
"type": "local",
"command": ["npx", "-y", "@datadog/datadog-mcp-server"],
"environment": {
"DD_API_KEY": "{env:DD_API_KEY}",
"DD_APP_KEY": "{env:DD_APP_KEY}",
"DD_SITE": "datadoghq.com"
}
}
}
}
Note the {env:VAR_NAME} interpolation syntax — OpenCode's config format differs from Claude Code's ${VAR_NAME}, and mixing the two up is a common first-run mistake if you're copying config between agents. Export the underlying variables in your shell as usual:
export DD_API_KEY="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
export DD_APP_KEY="yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
Start OpenCode and check the MCP server status from within the TUI:
opencode
Then inside the session, the /mcp command (or equivalent status view depending on your OpenCode version — this has moved around across releases) lists connected servers and their tool counts. A datadog entry showing a nonzero tool count confirms the process started and the handshake succeeded; it does not confirm your keys are valid, since a bad app key still lets the MCP server process start — it just fails on the first actual Datadog API call.
Run the same sanity check as any other agent:
List Datadog monitors currently in an Alert state.
If OpenCode returns an authentication error at this step rather than at startup, that's expected behavior, not a bug — validate that the error message names DD_APP_KEY specifically, since an API-key-only failure and an app-key failure look similar but point at different fixes.
Tips
- Use{env:VAR_NAME}syntax inopencode.json, not the${VAR_NAME}style from Claude Code — they are not interchangeable across these two config formats.
- A nonzero tool count in/mcponly confirms the process started, not that your Datadog credentials are valid — run a real query to confirm auth.
- Putopencode.jsonin.gitignoreif it contains anything beyond env-var references, or better, keep secrets entirely in shell env and reference them by name only.
Querying Logs, Metrics, and Monitor Status from OpenCode
OpenCode's tool-call flow is more terse by default than Claude Code's — it shows the tool name and a condensed argument summary rather than a full JSON dump, unless you increase verbosity. For observability work, where the exact query string is the thing you most want to verify, it's worth turning that up.
Standard log query, phrased the same way as any other agent:
Find error-level logs for service:notification-worker in the last hour,
group by error message and show counts.
Metric aggregation:
Get avg:aws.sqs.approximate_number_of_messages_visible{queuename:notification-queue}
for the last 4 hours.
Monitor status check:
What's the current status of any monitor with "queue-depth" in the name?
One practical difference from Claude Code: OpenCode sessions are, by default, more willing to chain several tool calls in a row without narrating each intermediate step — useful for speed, less useful when you're trying to learn Datadog's query syntax by watching the agent build queries. If you want the teaching-by-example benefit described in the first topic of this module, explicitly ask for it:
Before running each query, show me the exact Datadog query string
you're about to use.
That single instruction, added once to your session (or to an AGENTS.md / project instructions file OpenCode reads at startup), changes the default behavior for the rest of the session.
Tips
- Turn up tool-call verbosity (or explicitly request the query string be shown) if you're still learning Datadog's log/metric syntax — OpenCode's default output is terser than Claude Code's.
- Put "always show the Datadog query before running it" in your project'sAGENTS.mdif you want this behavior to persist across sessions rather than repeating it every time.
- Monitor-status queries are cheap and fast — use them liberally as a first step in any investigation to confirm you're chasing a real, currently-firing condition rather than a stale alert.
Practical Example: Investigating a Latency Regression in OpenCode
Walk through a real scenario: a deploy went out two hours ago, and p95 latency on the search-api service has crept up since. No monitor has fired yet — this is proactive investigation, not incident response.
Step 1 — confirm the regression exists and scope its start:
Get avg:trace.express.request.duration{service:search-api} by {resource_name}
for the last 4 hours, using 5-minute rollups, and tell me if there's a
clear inflection point.
OpenCode returns the time series and typically identifies the inflection visually from the data pattern — e.g., "duration was stable around 120ms until 13:50 UTC, then climbed to 340ms and has stayed elevated since."
Step 2 — check for a deploy correlation:
Do we have any deploy markers for search-api around 13:50 UTC today?
If your Datadog setup posts deploy events (via dd-trace deploy tracking, a CI webhook, or the Events API), the agent pulls them; if not, it'll say so honestly rather than fabricate a marker — a good server implementation returns an empty result, and a well-behaved agent reports "no deploy markers found" rather than guessing. If you don't have deploy tracking wired up, this is worth fixing — see the tip below.
Step 3 — pull traces from the affected window:
Pull the 5 slowest traces for search-api resource "GET /search" between
13:50 and 14:00 UTC, and identify the slowest span in each.
Say the result shows a new span appearing in the waterfall that wasn't there before — elasticsearch.search taking 200ms where it used to be absent or under 20ms. That's a strong, concrete lead: something in the deploy changed how search queries hit Elasticsearch, likely a new filter clause or a missing cache.
Step 4 — hand off to code investigation:
Find recent changes to our Elasticsearch query building code — look at
the last 3 commits touching src/search/ for anything that could add
query cost.
At this point OpenCode switches from MCP tool calls to its normal git/file tools, correlating the trace-level finding with an actual commit diff — often the fix is as small as a missing .filter() becoming a .must() clause that turned a cheap filter into a scored query.
Tips
- Ask for rollup granularity explicitly (5-minute rollups) on longer time windows — the default rollup Datadog picks can smooth over exactly the inflection point you're trying to find.
- If deploy markers aren't available, wire up Datadog's deploy tracking (via CI integration or the Events API) — it turns "did a deploy cause this" from a manual git-log cross-reference into a direct, queryable correlation.
- When a new span appears in a trace waterfall that wasn't there in a known-good baseline trace, that's usually your fastest path to root cause — ask the agent to diff two trace waterfalls (before/after) explicitly if it doesn't do so on its own.
Known Limitations for Datadog MCP in OpenCode
Be direct with your team about where this setup currently falls short, so nobody's surprised mid-incident:
No persistent session memory across restarts. OpenCode (like most current agent CLIs) doesn't retain conversation context between sessions unless you explicitly save and reload a session file. An investigation that spans a shift handoff needs the outgoing engineer to paste a summary into the new session — the tool calls and their results don't carry over automatically.
Weaker code-navigation defaults than Claude Code + VS Code. OpenCode is a strong terminal agent, but the trace-to-code pivot described for Claude Code in the previous topic relies on rich file navigation and search that feels noticeably smoother in an IDE-integrated context. OpenCode's grep/search tools work fine, but you'll do more manual pointing ("look in src/search/queryBuilder.ts") than letting the agent explore freely, especially in large monorepos.
Dashboard tool coverage is thin. As of current server versions, dashboard-related MCP tools are mostly read-only listing/fetch operations regardless of client — this isn't OpenCode-specific, but it's worth repeating here since OpenCode users sometimes expect parity with the Datadog UI's dashboard-building features that simply isn't there yet in the MCP surface.
Rate-limit backoff behavior varies by OpenCode version. Some releases surface a raw 429 error to you rather than retrying with backoff automatically. If you're running a long investigation with many rapid queries, watch for this — you may need to manually pace requests ("wait a moment between each query") rather than trusting the client to do it for you.
No built-in cost/usage dashboard inside OpenCode. Unlike Claude Code, which surfaces some usage telemetry in its own UI, OpenCode gives you no visibility into how many Datadog API calls a session has made. Track your own query volume manually during heavy investigation sessions if you're on a plan sensitive to API usage.
Tips
- Save session summaries manually at the end of an investigation (a short markdown recap) so a shift handoff doesn't lose the thread — don't rely on OpenCode session persistence for this.
- Point the agent at specific files/directories rather than letting it explore a large monorepo freely when doing trace-to-code correlation — it's faster and more accurate than open-ended search in OpenCode today.
- If you hit repeated429s, explicitly instruct pacing in your prompt rather than assuming the client backs off correctly.
Tips
Tips
- Use{env:VAR_NAME}interpolation inopencode.json, and keep actual secrets in shell environment variables only.
- Explicitly request query-string visibility if you want OpenCode's default terse tool output to teach you Datadog's syntax.
- When a proactive investigation (no monitor fired yet) shows a metric inflection, always check for a deploy marker in the same window before diving into traces — it's the fastest correlation to rule in or out.
- Know the current gaps — thin session persistence, less fluid code navigation than an IDE-integrated agent, no usage dashboard — and compensate with manual habits rather than assuming parity with Claude Code.