TestingOps.ai

MCP tools for agents · MCP tool for agents

Datadog and TestingOps: logs and traces for failed test runs

Connect Datadog's MCP server and TestingOps agents can check what your services logged and traced while a test was failing, before anyone files a defect.

  • MCP tool for agents
  • Available with limits
Connection
MCP tool for agents
Writes back
Only after a person approves
Last checked
7 Nov 2026

In short

Datadog and TestingOps in short

The Datadog connection is an MCP tool for TestingOps agents: with a Datadog access token that has the MCP Read scope, agents can call Datadog's MCP server for the US1 site while they analyse a run.

Agents can then look up logs, APM traces, RUM sessions, Synthetics results and CI test results around the time a case failed, to tell a product error from an environment problem.

The connection stays read-only as long as MCP Write Access is off in Datadog, and only the US1 site can be connected today.

What it does

What it does for your testing

  1. 1

    Server errors behind a failed step

    Input
    A failed step and its time
    TestingOps
    Agents can search the logs and traces of the service the step called, in that time window
    Output
    The backend error, if there is one, next to the failed step
  2. 2

    What the browser session showed

    Input
    RUM data for the page under test
    TestingOps
    Agents can look up front-end errors recorded for the same page and time
    Output
    Front-end errors that explain a step the test could not complete
  3. 3

    The test or the system?

    Input
    Synthetics and CI test results
    TestingOps
    Agents can check whether Datadog's own checks failed at the same time
    Output
    A hint that an outage, not the case, caused the failure

Step by step

How it works

  1. Turn on MCP access in DatadogAn organization admin enables MCP Access under Organization Settings → MCP. Leave MCP Write Access off for a read-only connection.
  2. Create a token with read scopesCreate a personal or service account access token with the MCP Read scope and the read permissions for the data agents need, such as logs, APM, monitors and dashboards.
  3. Connect it in TestingOpsPick Datadog under Extra tools your agents may use in Integrations → API & MCP, paste the token into Datadog access token and select Connect.
  4. Agents query Datadog during analysisWhen an agent analyses a run, it can call Datadog's tools through TestingOps. The token stays on the TestingOps server; each run gets a one-hour token for listing and calling tools.

The Datadog entry connects the US1 site (mcp.datadoghq.com). Datadog's other sites have their own MCP address, but Your own MCP server takes only an address, without a token, so they cannot authenticate there yet.

Connect

Setup

  1. In Datadog, an organization admin turns on MCP Access under Organization Settings → MCP and leaves MCP Write Access off.
  2. Open Personal Settings → Access Tokens and select New Access Token; set an expiration, select Select Scopes, tick MCP Read plus the read permissions agents need, save and copy the token (shown once).
  3. In TestingOps, as customer admin, open Integrations → API & MCP and pick Datadog under Extra tools your agents may use (outgoing, over MCP).
  4. Paste the token into Datadog access token and select Connect.

Documentation: Datadog MCP server setup

Where you connect it in TestingOps: Integrations → API & MCP → Extra tools your agents may use → Datadog

Use cases

Use cases

Check the backend before filing a defect

Trigger
A checkout case fails at the payment step
Uses
Logs and APM traces of the payment service
Agent activity
Can search for errors from that service in the minutes around the failed step
Result
Evidence for the defect, or a sign that the test environment was down
Condition
The token needs read access to logs and APM

Look behind timeouts that come and go

Trigger
A case fails every few runs with a timeout
Uses
Traces and monitors for the endpoint the step calls
Agent activity
Can compare latency around failing and passing runs
Result
A latency pattern to look at instead of retrying the case

Line up a release run with what users see

Trigger
A release goes out and the regression run shows new failures
Uses
RUM sessions and Synthetics results
Agent activity
Can check whether real sessions and Datadog's own checks show the same errors
Result
A note on which failures also appear outside the test run

Capabilities

Capabilities and limits

What is read

What the token's scopes allow on the US1 site: logs, APM traces, RUM, Synthetics, CI test results, monitors and dashboards

What is produced

Context for agents' failure analysis; the tool stores nothing in TestingOps by itself

Where it can write

Nothing while MCP Write Access is off in Datadog. If you turn it on, tools that are not marked read-only or named for reading ask first and wait for approval from someone in your organisation with Manage integrations rights (or the TestingOps team).

How it connects

Datadog's hosted MCP server for US1 (https://mcp.datadoghq.com/v1/mcp) with the access token in the Authorization header

Account and permissions

  • MCP Access enabled in Datadog's organization settings
  • A personal or service account access token with MCP Read and the read permissions agents need
  • Customer admin (or Manage integrations) rights in TestingOps; the tool is visible only to agents working on your organisation's projects

Limits

  • US1 only: EU and other Datadog sites cannot be connected with a token today
  • Datadog tokens expire after the period you set, at most one year
  • Tool results that look like prompt injection are blocked, and secrets such as keys and tokens in them are masked
  • Agents running on Grok receive no MCP tools

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A retail team's regression run fails at Place order on staging. With Datadog connected through a read-only token, the analysing agent can search the order service's logs for the minute of the failure.

The logs show a database connection error on staging, so the agent's analysis points to the environment rather than the checkout flow, and the team checks staging before anyone files a defect.

Frequently asked questions

Our Datadog organisation is on the EU site. Can we connect it?

Not yet. The Datadog entry is the US1 site. Datadog's EU address can be entered under Your own MCP server, but that field takes only an address, so the token cannot be sent.

Can agents change monitors or dashboards?

Not while MCP Write Access is off in your Datadog organization, as the setup recommends. If you turn it on, write tools ask first and someone in your organisation with Manage integrations rights (or the TestingOps team) has to approve each call.

Does TestingOps copy our logs?

No. Agents query Datadog when a task needs it; the tool imports nothing. An agent may quote what it found in its analysis.

Which token should we use?

A service account token does not depend on one person's account, which makes it a good fit. Give it MCP Read and only the read permissions agents need.

Next step

Request a demo to see how agents can use your Datadog data when they analyse a failed run.