How to connect a Datadog MCP with Codex (4 steps)

When you ask Codex to write a new monitor-as-code definition or add instrumentation to a service, you usually describe the existing setup in the prompt.

That description guesses at the metric's tag keys, the monitor's threshold logic, and the trace structure the service already emits.

The real configuration lives in Datadog, not in your recollection of it. So Codex generates a monitor that queries a tag that doesn't exist, instrumentation that emits the wrong metric name, or a parser built for a trace shape your services never produce.

To give Codex direct access to Datadog as it works through your coding tasks, we'll show you how to connect Datadog with Merge Agent Handler's Datadog MCP server.

How it works

Merge Agent Handler connects Codex to the Datadog API through the Merge CLI. You install the CLI, authenticate once, and run a single setup command from your project root.

That command writes a Merge CLI section to your project's AGENTS.md file, which tells Codex when to call merge search-tools and merge execute-tool to reach Datadog.

Once connected, Merge handles API and application key storage on your behalf, so you never commit Datadog keys to your repo or rotate them by hand.

Related: How to use the Datadog MCP in Claude Code

Prerequisites

Before getting started, you'll need the following:

• A Merge Agent Handler account
• Codex access (available via the OpenAI platform)
• pipx installed (run pipx --version to confirm, or install via pip install pipx)
• A Datadog account with API and application keys for the org your tasks need

If you want to connect Merge Agent Handler's Datadog MCP with internal or customer-facing agentic products, you can follow the steps in our docs.

1. Install the Merge CLI

Install the Merge CLI with pipx: pipx install merge-api

Verify the install: merge --version

2. Log in to Merge

Run this to authenticate the CLI with your Merge Agent Handler account: merge login

This links the CLI to your Merge account and stores your session credentials locally.

3. Add Agent Handler to Codex

From the root of the project where you want Codex to reach Datadog, run:

merge setup cursor

This writes a Merge CLI section to your project's AGENTS.md file so Codex knows to use the CLI when a task needs Datadog data. The command is idempotent, safe to re-run if you need to reset the configuration.

Commit the updated AGENTS.md so the configuration travels with the repo.

4. Authenticate Datadog

Create a Codex task that needs live Datadog data. It can be something like: "Read the configuration of our existing latency monitors on the checkout service and write a Terraform monitor definition for p99 latency on the new payments service that follows the same thresholds and tags."

The first time Codex invokes a Datadog tool, a Magic Link will appear to complete connector authentication.

Once authenticated, Codex can reach your Datadog account through Merge for every later task in this project.

{{this-blog-only-cta}}

Datadog MCP FAQ

In case you have more questions on setting up and using the Datadog MCP with Codex, we've addressed several more commonly-asked questions below.

What can you do once the Datadog MCP is connected to Codex?

With Datadog connected, Codex can:

• Read an existing monitor's configuration before generating a new monitor-as-code definition: pull the real query, thresholds, and tags from a comparable monitor so the Terraform or JSON definition it writes matches your established conventions instead of generic defaults

• Pull a metric's real tag structure before generating instrumentation: fetch the actual tag keys and metric names already in use so the emitting code it writes lines up with what your dashboards and monitors expect

• Read an APM trace's shape before generating a span parser or exporter: retrieve a real trace with its span and metadata structure so the parsing or forwarding logic it writes handles the format your services actually emit

• Read a dashboard definition before generating a new dashboard-as-code: pull an existing dashboard's widget and query structure so the new definition it produces stays consistent with how your team builds them

• Pull real log event structure before generating a log pipeline or parser: fetch sample log events for a service so the parsing rules it writes match the attributes and formats those logs actually contain

Why use Merge Agent Handler vs. a self-hosted Datadog MCP server?

You can build your own MCP server against Datadog's API. For one engineer on one org, it's manageable: create API and application keys, scope them, and write tool schemas for the endpoints your tasks touch.

It gets harder once more than one person uses it or tasks run in CI.

Datadog keys carry broad read access across metrics, logs, and traces, and handing that to an agent without scoping is a real exposure, especially when logs can contain sensitive data. There's no central view of which keys are live or what they can reach.

A self-hosted server doesn't fix that.

You still own key management and scoping, and now you maintain the server too. Datadog doesn't publish an official MCP server, so community builds come with no guarantees on coverage or upkeep.

Merge Agent Handler handles key storage and lets you scope exactly which Datadog operations a Codex task can call. Every call is logged with identity, timestamp, and inputs.

For observability data that often includes sensitive request and log content, scoped access plus full audit logging is the foundation you want before an agent reads it.

Why connect Datadog to Codex?

Datadog holds the monitor definitions, metric tags, trace structures, dashboards, and log formats that monitoring and instrumentation code has to match exactly.

Codex tasks that write monitors-as-code, add instrumentation, or build log parsers need that ground truth to produce code that works against your actual setup.

The alternative is describing the configuration in the prompt, and those descriptions are always a little off. A wrong tag key, an outdated metric name, or a misremembered trace field is enough to make Codex generate code that points at telemetry that doesn't exist.

Connecting Datadog lets Codex read the real configuration when a task needs it. The monitor query before a new definition, the tag structure before instrumentation, the trace shape before a parser: Codex works from your live observability setup, not a description of it.

Can I use Merge Agent Handler's Datadog MCP with my employees?

Yes, Agent Handler for Employees is built to help engineering organizations provision, secure, and govern how employees connect AI tools like Codex to operational systems like Datadog.

Common patterns include:

• Provisioning and access control via SCIM with identity providers like Okta and Microsoft Entra ID, so IT can manage which Datadog orgs and data types an employee's agent can reach by role or team

• DLP and policy enforcement on tool calls, so admins can block queries that would return sensitive log or trace content before results reach a Codex task's context

• User-level audit logging so security and IT teams can review which monitors, metrics, traces, and logs were accessed, by which employee identity, and when

The result is that employees can use the Datadog MCP to generate monitors-as-code from real configurations, write instrumentation that matches existing tags, build log parsers grounded in actual event structure, and more, while IT keeps centralized control over which data each agent can reach.