How to connect a Datadog MCP to Cursor (4 steps)

You already write, edit, and reason about your code in Cursor. But the moment you start building something that integrates with Datadog, you need details that only live in your Datadog org.

What does a monitor object's JSON actually look like? Which tag keys are valid on the metric you're querying? How is an APM trace structured before you write the code that parses it?

Without the MCP connection, answering those questions means leaving the editor, authenticating against Datadog's API separately, running test calls, and pasting responses back into the session where the integration code is being written.

To help your developers inspect Datadog's data model and query real telemetry without leaving Cursor, we'll show you how to connect Datadog with Merge Agent Handler's Datadog MCP server.

How it works

Merge Agent Handler connects Cursor 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 the project's .cursorrules file, which tells Cursor's agent when to call merge search-tools and merge execute-tool to reach Datadog.

Merge handles your Datadog API and application key storage so you never commit credentials to the 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
• Cursor installed
• pipx installed (run pipx --version to confirm, or install via pip install pipx)
• A Datadog account with API and application keys for the org you want to query

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

Run the following to install the Merge CLI: pipx install merge-api

Verify your installation: merge --version

2. Log in to Merge

Authenticate the CLI with your Merge Agent Handler account: merge login

This links the CLI to your account so it can make authorized requests to Datadog on your behalf.

3. Connect the CLI to Cursor

Run the following from the root of the project where you want to use Merge tools:

merge setup cursor

This writes a ## Merge CLI section to .cursorrules so Cursor knows to use the CLI for third-party services. The command is idempotent, safe to re-run if you need to reset.

Related: Steps for connecting a Datadog MCP with Codex

4. Authenticate Datadog

Open a Cursor chat in your project and try a prompt like:

Fetch the JSON for our existing latency monitors, including the query, thresholds, and tags, so I can write correct payloads in the monitor-management integration I'm building.

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

{{this-blog-only-cta}}

Datadog MCP FAQ

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

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

With Datadog connected, Cursor can:

• Fetch a monitor's JSON structure before writing monitor-management code: retrieve the real query, threshold, and tag fields of an existing monitor so the create and update payloads you write match what Datadog's API accepts

• Inspect a metric's tag keys before writing query code: pull the actual tag keys and scopes in use for a metric so the query strings and filters you write resolve against telemetry that exists

• Check an APM trace's shape before writing a trace parser: fetch a real trace with its span and metadata structure so the parsing or forwarding code you write handles the exact format your services emit

• Look up a dashboard's widget structure before writing dashboard automation: retrieve an existing dashboard's JSON so the code you write to generate or modify dashboards produces the widget and layout shape the API expects

• Validate log event fields before writing log-query logic: pull sample log events for a service so the attribute names and formats in your search or processing code match what those logs actually contain

• Confirm the monitor and SLO ID formats before writing reference code: query the real identifiers for monitors and SLOs so the references you hard-code or look up in your integration point at the right objects

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

You can connect directly to Datadog's API using your own API and application keys. The REST API is well-documented, key generation is quick, and for a single developer building against one org the setup is fast.

The access control problem appears when you scale beyond one developer or one agent.

Datadog keys carry broad read access across metrics, logs, and traces, and sharing them across agents or teammates means every agent operates with that same reach, with no way to restrict which operations a given agent can call. Rotating a key means updating every system that holds it at once.

Merge Agent Handler handles Datadog authentication centrally.

You define exactly which Datadog operations each agent can call: an agent that inspects monitor and metric structure for code generation can read those objects without reaching write operations like creating monitors or muting alerts. Every call is logged with the timestamp, tool, and inputs, so you have a full record of what each agent read or changed.

For teams running multiple agents against a shared Datadog org, that combination of scoped access and central logging is the difference between a controlled deployment and a shared credential problem.

Why connect Datadog to Cursor?

Datadog's API data, monitor JSON, metric tag schemas, trace structures, dashboard definitions, isn't something you can accurately reconstruct from documentation alone.

These values are org-specific: monitor IDs differ across environments, tag schemas reflect what your instrumentation actually emits, and trace shapes reflect how your services are instrumented.

Connecting Datadog to Cursor puts that discovery step inside the editor. When you're writing a monitor provisioner and need the exact JSON a monitor expects, you fetch a real one. When you're building a metrics report and need to know which tag keys are valid, you query the metric. When you're writing a trace parser and need the span structure, you pull a live trace.

The data that makes the integration code correct stays in the same session where the code is being written, instead of forcing a separate API exploration phase before development can start.

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 Cursor 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 the editor session

• 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 write monitor-management code against real object structures, build metric reports grounded in actual tag schemas, and write trace parsers that match live span formats, and more, while IT keeps centralized control over which data each agent can reach.