Datadog MCP for Claude Code: Monitoring Integration

EngineeringAugust 24, 20268 min readBy PinVari
Datadog MCP for Claude Code: Monitoring Integration

Datadog MCP for Claude Code is a Model Context Protocol server that exposes Datadog tools to the Claude Code CLI so the agent can query logs, metrics, traces, or monitors without you pasting a dashboard screenshot. You connect the server, scope the tools, and keep credentials out of the prompt.

Most integration posts stop at "add the server." The useful version is a checklist: what the agent is allowed to read, what it must never write, and how a local UI capture still sits beside production telemetry.

What does Datadog MCP for Claude Code actually add?

It adds tools. It does not add judgment.

Claude Code already edits files and runs shell commands. Claude Code MCP is how extra tools appear. Datadog's server is one of those extras, in the same family as the MCP server examples you may already run.

The agent can then ask for a log query or a monitor state the way it asks for a file. You still decide whether a 5xx spike is the bug you are fixing this hour.

Tools are queries, not a pager replacement.

If you need the protocol basics first, what is an MCP server is the shorter explainer.

Key

Connect Datadog so the agent can fetch a signal. Do not connect it so the agent can "own production." Read-only is the default you want on a laptop.

How do I connect the server without leaking a key?

Install the Datadog MCP connector the way Datadog documents this week. I will not invent a price, a site region, or a flag that may have changed.

Put the API key and application key in the connector's local config or in your secret store. Do not put them in CLAUDE.md. Do not put them in a Slack snippet you later paste into chat.

Add the server to Claude Code with a scoped user or project entry. Restart the CLI so the tool list refreshes.

Then ask: "List the MCP tools you can see that mention logs or monitors." If the agent cannot name them, the server is not connected. Fix that before you debug a query language.

Keys stay in the connector. The prompt only names the service.

Tip

Run a harmless read first: last 15 minutes of errors for one service you own. If that fails, it is auth or site URL, not the model.

What is the copyable integration checklist?

Copy this. Check a box only after you have seen the result.

  1. Confirm you already have a Datadog account and a service you are allowed to query.
  2. Create an application key with the smallest read scopes you can live with.
  3. Install the Datadog MCP server from current Datadog docs, not from a random gist.
  4. Point it at the correct site. US and EU are not interchangeable.
  5. Add the server to Claude Code. Restart. Ask the agent to list tools.
  6. Run one log query for a service name you recognize. Confirm the timestamps look like your timezone.
  7. Run one monitor status read. Confirm the agent does not try to mute it.
  8. Write a CLAUDE.md line: production reads go through Datadog tools; do not curl the HTTP API with a key from chat.
  9. Add a PreToolUse note or hook if you want to block write-like tool names.
  10. Keep PinVari on 127.0.0.1:3402 for the UI on your Mac, so a red button on localhost is not a Datadog search.

That last line is the one most monitoring guides skip.

Checklist before a second query: auth works, one read succeeded, writes are blocked.

When should the agent use Datadog versus a local capture?

Use Datadog when the truth is in production. Use a local capture when the truth is on your screen.

Datadog MCP

Type: remote observability tools.

Capture: logs, metrics, traces, monitor state.

Resolution: a query result.

Claude Code shell

Type: local commands.

Capture: process output on your machine.

Resolution: a stdout blob.

PinVari MCP

Type: local screen context.

Capture: a circled or dwelled control plus speech.

Resolution: AX role, label, frame, confidence, provenance.

A 500 from checkout is a Datadog search. A disabled Save button on the staging site in your browser is a point-and-speak capture.

Hold ⌥⌘A, circle the control, speak the expected state. PinVari transcribes on-device and binds "this" to the pointer trail. The agent calls pinvari_next_instruction and gets a named element, not a PNG to decode.

Jam.dev is still excellent if the only surface is Chromium and you want console logs. It will not see a native Datadog desktop window or your IDE. CleanShot X will screenshot the monitor graph and still not name the series.

Signal versus pixel is the whole split.

What queries should I let the agent run first?

Start with the boring ones.

Ask for error logs for one service, one environment, a short window. Ask for the monitor that already pages that service. Ask whether a deploy marker sits near the spike.

Do not start with "find why the app is slow" across every index you pay for. You will wait, and you will get a story.

I will not invent Datadog query syntax that may have changed. Use the query the agent returns only after you would run it yourself in the UI.

If the agent wants to change a monitor, say no unless that is the ticket. Read-only is a product decision, not a vibe.

Short window, one service. Widen after you trust the tool.

Heads up

A laptop agent with a write-capable Datadog key is a pager incident waiting for a confident model. Scope the key. Say so in the prompt. Confirm in the tool list.

How do I close the loop after a monitor and a UI fix?

The monitor tells you users saw 500s. The fix is often a control or a copy change you can see.

After the agent patches the code, run tests. Then open the UI. If the empty state is still wrong, capture it. Do not paste another dashboard PNG.

PinVari can hold full focused-window text up to 40,000 characters, including text scrolled out of view, plus an interactive-element map. Optional whole-screen on-device OCR covers AX-blind canvas. Multi-display marks remember the monitor they were drawn on.

When the agent finishes, pinvari_mark_done clears the notch island. A Stop hook can do that for you.

PinVari is a one-time $39 launch license for the first 500, then $59. No subscription for the core app. The pricing page is the number. The app is a notarized Developer-ID DMG for macOS 14+, Apple Silicon and Intel.

Nothing in that flow uploads by default. Datadog traffic is your existing observability path. PinVari stays on localhost.

Two servers, two jobs. Do not make Datadog explain a CSS gap.

What usually breaks in this integration?

Wrong site URL. Expired application key. A tool list that still shows yesterday's server name after you renamed it.

The next break is context. The agent dumps three hundred log lines into the session and then cannot see your test file. Ask for a summary of ten lines, not the raw index.

The third break is mixing environments. Staging logs plus a production monitor story will waste an hour.

Restart Claude Code after any MCP change. Hooks and servers both load at session start.

Restart, then re-list tools. That sentence fixes more "Datadog MCP is broken" threads than a new prompt.

FAQ

Does Datadog MCP for Claude Code replace the Datadog UI?

No. It lets the agent fetch a slice of what you already store. You still use the Datadog UI for dashboards you stare at, and for permissions you should not hand to a coding agent.

Is there an official Datadog MCP server?

Datadog has been shipping MCP support. Install from their current documentation. I will not pin a GitHub URL or a price that may have moved.

Can the agent mute monitors through MCP?

Only if the tool and the key allow writes. Prefer a read-only key on a development machine. If a write tool appears, treat it like production access.

How is this different from pasting a dashboard screenshot?

A screenshot is pixels and tokens. A tool result is structured. The agent can re-query. A PNG cannot.

Should I put Datadog and PinVari on the same MCP host?

No. Datadog talks to Datadog. PinVari talks to 127.0.0.1:3402 on your Mac. Claude Code can load both servers. They answer different questions.

What if I do not use Datadog?

Use whatever observability MCP or API you already pay for. The checklist is the same: read-only key, one proof query, local capture for the UI the metrics cannot name.

How do I write a CLAUDE.md note that keeps Datadog in its lane?

Two sentences are enough.

"Production symptoms come from Datadog tools. Localhost UI comes from PinVari."

Add the service name you own and the environment tag you actually query. Do not list every dashboard.

If the agent starts guessing a query language, ask it to show the query before it runs. You still have to recognize your own service.

A third sentence can name the forbidden action: do not mute, do not delete, do not create a new monitor unless the ticket says so.

Two sentences, one service. That is the Datadog chapter of CLAUDE.md.

When a teammate joins, they should be able to run the proof query on day one. If they cannot, the integration is still a personal setup, not a team one.

Keep the application key rotation on the same calendar as the rest of your secrets. MCP does not make a key safer. It only makes it closer to the model.

Hand your agent the exact element

PinVari resolves what you point at into a named, executable instruction — on-device, no keys, your own agent. One click inside PinVari connects Claude Code, Cursor, VS Code or Codex — or paste one CLI line from pinvari.com/connect.

PinVari → Connect → your agent (one click)
Get PinVari — $39 →