Skip to main content
The Datadog MCP connector lets Rootly AI query operational data during investigations. It can inspect services, logs, metrics, monitors, application performance monitoring (APM) spans and traces, and Real User Monitoring (RUM) events through Datadog’s hosted Model Context Protocol (MCP) server. OAuth 2.0 is the recommended authentication method. Rootly also supports Datadog API and application keys for organizations that can’t use OAuth.
Rootly requests read permissions only and exposes a reviewed investigation tool set. It doesn’t request Datadog’s mcp_write permission or expose Datadog tools that create or modify resources.
This connector is independent of the Datadog Alert Source. The Alert Source sends Datadog alerts into Rootly. The Datadog MCP connector lets Rootly AI query Datadog on demand. You can configure both for the same Rootly team.

Before You Start

You need:
  • A Datadog account with access to the data Rootly AI should query.
  • Permission in Rootly to manage AI connectors.
  • A supported Datadog site: US1, US3, US5, EU1, AP1, or AP2. Datadog’s hosted MCP server isn’t available for GovCloud.
  • The Datadog role permissions listed below.

Required: Allow Rootly’s OAuth Callback

Complete this prerequisite before starting OAuth. Otherwise, Datadog rejects the authorization request or can’t return the user to Rootly.
A Datadog administrator must allowlist Rootly’s callback URL before anyone connects with OAuth. In Datadog, open Organization Settings → Organization Preferences → MCP OAuth Redirect URLs and add:
If Rootly support gave you a different Rootly environment, replace https://rootly.com with that environment’s base URL. Keep the /account/ai-sre/remote_mcp_sources/callback path unchanged.

Required Permissions

The Datadog user authorizing OAuth needs these permissions through their role. Rootly requests the matching OAuth scopes. Datadog applies the authorizing user’s role permissions in addition to the OAuth scopes. Rootly AI can’t retrieve data the user can’t access.
dbm_parameterized_queries_read is a valid Datadog role and application-key permission, but Datadog’s MCP OAuth client doesn’t authorize that scope. OAuth can investigate Database Monitoring metrics and spans with dbm_read; use API and application keys when an investigation needs parameterized query-pattern access.
Rootly doesn’t request mcp_write. A custom Datadog role only needs MCP Read and the resource-level read permissions for the data Rootly should access.

Additional Permissions for API and Application Keys

The key-based fallback validates the application key’s scopes before saving the connection. The application key and the user or service account that owns it need every permission below: This broader list intentionally preserves the existing key-based connector’s legacy read surface for backward compatibility. Use OAuth when you want the smallest permission set supported by the Datadog MCP connector.
  • user_app_keys
  • mcp_read
  • apm_read
  • apm_service_catalog_read
  • containers_read
  • logs_read_data
  • logs_read_index_data
  • monitors_read
  • apm_api_catalog_read
  • apm_pipelines_read
  • apm_remote_configuration_read
  • apm_retention_filter_read
  • apm_service_ingest_read
  • continuous_profiler_pgo_read
  • continuous_profiler_read
  • debugger_read
  • dashboards_read
  • dbm_parameterized_queries_read
  • dbm_read
  • error_tracking_read
  • events_read
  • logs_read_archives
  • logs_read_config
  • logs_read_workspaces
  • metrics_read
  • timeseries_query
  • notebooks_read
  • on_call_read
  • rum_apps_read
  • cd_visibility_read
  • ci_visibility_read
  • synthetics_default_settings_read
  • synthetics_global_variable_read
  • synthetics_private_location_read
  • synthetics_read
  • teams_read
The API key identifies the Datadog organization and doesn’t carry permissions. The user_app_keys permission lets Rootly inspect the submitted application key’s scopes during setup.

Connect Datadog With OAuth

Before continuing, confirm that a Datadog administrator completed Required: Allow Rootly’s OAuth Callback.
1

Open AI Connectors

In Rootly, go to AI & Agents → Connectors, find Datadog MCP, and click Connect.
2

Choose Your Datadog Site

Select the site that hosts your Datadog organization:Choose the site that matches your Datadog login URL. Each site has its own MCP and OAuth endpoints.
3

Start OAuth

Click Connect with OAuth. You don’t need to create or share an API key, application key, client ID, or client secret.
4

Choose the Datadog Organization

Sign in to Datadog. If your account belongs to more than one organization, select the organization Rootly AI should query.
5

Authorize Rootly

Review the requested read permissions and authorize Rootly. Datadog returns you to Rootly after approval.
6

Confirm the Connection

Return to AI & Agents → Connectors. The Datadog MCP card shows Connected after Rootly validates the OAuth grant and Datadog tool catalog.
Rootly uses OAuth 2.0 with Dynamic Client Registration and Proof Key for Code Exchange (PKCE). Access and refresh credentials are encrypted at rest. If a Datadog connection already exists, Rootly keeps it active during a new OAuth attempt. Rootly replaces the existing connection only after authorization and validation succeed.

Connect With API and Application Keys

Use this fallback when your organization can’t complete the OAuth flow.
1

Create Scoped Datadog Keys

Create a Datadog API key and a scoped application key owned by a dedicated service account. Grant the application key and its owner every permission under Additional Permissions for API and Application Keys.
2

Open the Key Form

In Rootly, open AI & Agents → Connectors, find Datadog MCP, and click Connect. Choose the correct Datadog site, then expand Use API and application keys instead.
3

Connect With Keys

Enter the API key and application key, then click Connect with keys. Rootly validates the credentials and application key permissions before saving the connection.
Rootly encrypts the API and application keys at rest.

What Rootly AI Can Read

Rootly connects to Datadog’s core MCP toolset and exposes reviewed, read-only investigation tools. Rootly filters Datadog’s upstream catalog before every call. A new tool added by Datadog doesn’t become available automatically, and tools that write Datadog data remain blocked.

Questions To Ask

Include a service, environment, and bounded time range when possible. These prompts work in Rootly AI SRE and the Slack agent:
  • “Which services emitted new error log signatures in prod during the last 30 minutes compared with the preceding 30 minutes?”
  • “Break down checkout-api p95 latency by resource for the incident window. Which endpoint regressed most against baseline?”
  • “Find error spans for payment-api between 14:00 and 14:20 UTC, then expand the slowest trace and identify the failing dependency.”
  • “Did the checkout error-rate monitor alert because of one environment, region, or host? Show the metric contributors.”
  • “Compare blocked database sessions during the incident with the same window yesterday. Which wait type or query pattern changed?”
  • “How many RUM checkout errors occurred in the incident window, grouped by browser and country?”
  • “List the exact Datadog service and environment names before querying logs for the authentication failure.”
If a broad question returns irrelevant results, add the exact service, environment, signal type, and UTC time range.

Data Handling and Permissions

  • On-demand queries. Rootly AI calls Datadog when an investigation or direct question needs current data.
  • Datadog permissions apply. Results are limited by the OAuth user’s role or the application key owner’s access.
  • Read-only boundary. Rootly requests read scopes and enforces a reviewed tool set before every call.
  • Encrypted credentials. Rootly encrypts OAuth credentials and API or application keys at rest.
  • AI traces may contain results. Datadog responses can appear in Rootly AI model and observability traces. See Data Privacy for Rootly AI for retention details.
  • Datadog rate limits apply. Investigation queries count against your Datadog organization’s API limits.

Manage the Connection

Open AI & Agents → Connectors and find the Datadog MCP card.
  • Click Configure to authorize a different Datadog organization, choose another site, or switch authentication methods. Rootly keeps the current connection active until the replacement is authorized and validated.
  • Click Disconnect to remove the connection and stop future Datadog queries.
Disconnecting doesn’t change or delete data in Datadog.

Troubleshooting

Ask a Datadog administrator to add Rootly’s exact callback URL under Organization Settings → Organization Preferences → MCP OAuth Redirect URLs. The scheme, host, path, and trailing slash must match. For Rootly’s production environment, use https://rootly.com/account/ai-sre/remote_mcp_sources/callback without a trailing slash.
Confirm the callback URL is allowlisted in that Datadog organization, then restart the connection from Rootly. If you belong to several organizations, make sure you select the organization where an administrator added the callback URL.
Rootly validates the OAuth grant and required Datadog tools before replacing the current connection. Confirm the authorizing user has mcp_read and the resource-level permissions listed on this page, then connect again. A failed replacement leaves the previous working connection unchanged.
Confirm the OAuth user or application key owner has mcp_read plus the read permission for that resource. For example, monitor queries need mcp_read and monitors_read; log queries need mcp_read, logs_read_data, and logs_read_index_data.
Grant user_app_keys to both the scoped application key and its owner, then connect again. Rootly rejects a key-based connection when it can’t verify the application key’s scopes.
Confirm you selected the Datadog site that contains the data. US1, US3, US5, EU1, AP1, and AP2 use different regional MCP endpoints. Click Configure on the connected Datadog MCP card and reconnect to change sites.
Rootly AI can only see data available to the OAuth user or application key owner. Check that identity’s Datadog role, then retry with the exact service and environment names and a bounded time range.

Frequently Asked Questions

No. The Alert Source ingests Datadog monitor alerts into Rootly. The Datadog MCP connector lets Rootly AI query Datadog during investigations. Most teams use both.
No. Rootly registers an OAuth client and stores the resulting credentials. API and application keys are an independent fallback.
No. Rootly doesn’t request mcp_write, and its reviewed Datadog tool set excludes resource creation, updates, and deletion.
A Rootly team supports one active Datadog connection. Click Configure on the connected Datadog MCP card to authorize a replacement. Rootly keeps the current connection active until the replacement succeeds.
Rootly supports US1, US3, US5, EU1, AP1, and AP2. Datadog doesn’t provide its hosted MCP server for GovCloud.
Rootly queries Datadog on demand. Short-lived references may be cached within an investigation so Rootly AI can expand a selected log or trace safely.

AI Connectors

Browse every data source Rootly AI can use during an investigation.

Datadog Alert Source

Configure Datadog monitor alerts to create Rootly alerts.

Rootly AI Data Privacy

Review encryption, retention, trace handling, and model controls.

Datadog MCP Server Setup

Review Datadog’s MCP authentication, permissions, sites, and toolsets.