# Using Atlas with Datadog in 2026 > Atlas queries Datadog APM traces, logs, and monitors through Datadog's hosted MCP server, tying a p99 latency spike to the deploy that caused it. Atlas queries Datadog APM traces, logs, and monitors through Datadog's hosted MCP server at https://mcp.datadoghq.com/api/unstable/mcp-server/mcp, so it can tie a p99 latency spike to the deploy that caused it and then open the code path responsible. Authenticate with atlas mcp auth datadog, or skip OAuth by passing DD-API-KEY and DD-APPLICATION-KEY headers. ## What Atlas does with Datadog Atlas queries Datadog APM traces, logs, and monitors through Datadog's hosted MCP server, so it can tie a p99 latency spike to the deploy that caused it and then open the code path responsible. In 2026 the entire investigation happens inside one terminal session. Observability tools tell you that something regressed. They do not tell you which function to change. Atlas closes that last step. Because it can query Datadog APM traces, logs, and monitors, and because it is already sitting in your checkout, the same agent that finds the p99 latency spike can open the handler behind it. The correlation Datadog is good at, deploy markers against latency, becomes the first half of a workflow whose second half is a diff. ## Registering Datadog's hosted MCP server Add Datadog's hosted MCP server with atlas mcp add datadog --url https://mcp.datadoghq.com/api/unstable/mcp-server/mcp, then authenticate with atlas mcp auth datadog. There are 2 credential paths, and the second skips OAuth by passing --header 'DD-API-KEY=$DD_API_KEY' --header 'DD-APPLICATION-KEY=$DD_APPLICATION_KEY'. Two credential paths exist, and they suit different environments. Interactive use on a laptop wants atlas mcp auth datadog, which runs OAuth and stores nothing long lived. Automated or headless use wants the header path: --header 'DD-API-KEY=$DD_API_KEY' --header 'DD-APPLICATION-KEY=$DD_APPLICATION_KEY'. Datadog needs both keys, not just the API key, because the application key is what carries the read permissions on APM and logs. Export both before you register the server. ## Datadog regions: the host must match your site Non-US1 Datadog sites swap the host: use mcp.datadoghq.eu, us5.datadoghq.com, or ap1.datadoghq.com. Exactly 1 of those hosts, or the default US1 endpoint, must match the Datadog site your organization lives on before Atlas can read a single APM trace. Datadog data is partitioned by site, and an MCP request to the wrong host does not fall back gracefully. If your organization is on the EU site, register mcp.datadoghq.eu. If you are on US5, register us5.datadoghq.com. AP1 organizations use ap1.datadoghq.com. Check the site in your Datadog URL before you run atlas mcp add datadog, because a mismatch produces an empty or failing result that looks like a permissions problem and is not one. ## Narrowing the tool surface with toolsets Narrow the tool surface with a query string such as ?toolsets=apm,llmobs so Atlas only sees APM and LLM Observability tools. A smaller Datadog tool list means a smaller prompt and fewer wrong turns while Atlas is chasing one p99 latency regression. Datadog's hosted MCP server exposes a broad set of capabilities, and an agent given every tool at once will sometimes reach for the wrong one. Appending ?toolsets=apm,llmobs to the server URL restricts what Atlas can even see. Pick the toolsets that match the job in front of you: APM when you are chasing latency, LLM Observability when you are debugging a model call path. Registering a second, differently scoped Datadog entry for a different job is fine. ## The daily loop: from latency spike to handler Ask Atlas to correlate the p99 latency regression on a service with the release marker before it, then jump to the handler it names. That single instruction spans Datadog APM traces and your repository, which is the whole reason the Datadog MCP server belongs next to a coding agent. Phrase the prompt as a correlation, not a lookup. Atlas pulls the APM traces for the service, finds the release marker that precedes the regression, and reports which deploy the latency change lines up with. Then it does the part that a dashboard cannot: it opens the handler the trace names, in your working tree, and shows you the code. From there the fix is an ordinary Atlas diff, reviewed the same way as any other. ## The separate Code Security MCP server Datadog also ships a separate local Code Security MCP server, configured by 3 environment variables: DD_API_KEY, DD_APP_KEY, and DD_SITE. It is a second server rather than a toolset on the hosted endpoint, so register it separately in Atlas if you want its findings. Do not expect Code Security tools to appear under the hosted Datadog MCP server, because they live in a different process. The Code Security MCP server runs locally and takes its configuration from three environment variables: DD_API_KEY, DD_APP_KEY, and DD_SITE. Note that DD_APP_KEY here is spelled differently from the DD-APPLICATION-KEY header the hosted server takes. Register it as its own entry in Atlas and it sits alongside the APM connection, not inside it. ## Setup 1. Add Datadog's hosted MCP server with atlas mcp add datadog --url https://mcp.datadoghq.com/api/unstable/mcp-server/mcp 2. Authenticate with atlas mcp auth datadog, or skip OAuth entirely by passing --header 'DD-API-KEY=$DD_API_KEY' --header 'DD-APPLICATION-KEY=$DD_APPLICATION_KEY'. 3. For non-US1 sites, swap the host: use mcp.datadoghq.eu, us5.datadoghq.com, or ap1.datadoghq.com. 4. Narrow the tool surface with a query string such as ?toolsets=apm,llmobs so Atlas only sees APM and LLM Observability tools. 5. Ask Atlas to correlate the latency regression on a service with the release marker before it, then jump to the handler it names. 6. Register Datadog's separate local Code Security MCP server if you want it; it reads DD_API_KEY, DD_APP_KEY, and DD_SITE. ## FAQ ### how to connect Atlas to Datadog Run atlas mcp add datadog --url https://mcp.datadoghq.com/api/unstable/mcp-server/mcp, then atlas mcp auth datadog. For a headless setup, pass --header 'DD-API-KEY=$DD_API_KEY' --header 'DD-APPLICATION-KEY=$DD_APPLICATION_KEY' instead. ### Datadog MCP server URL for EU site Non-US1 sites swap the host. Use mcp.datadoghq.eu for EU, us5.datadoghq.com for US5, or ap1.datadoghq.com for AP1. ### how do I limit which Datadog MCP tools an agent can use Append a toolsets query string to the server URL, such as ?toolsets=apm,llmobs, so Atlas only sees APM and LLM Observability tools. ### can Atlas use Datadog without OAuth Yes. Skip OAuth by passing --header 'DD-API-KEY=$DD_API_KEY' --header 'DD-APPLICATION-KEY=$DD_APPLICATION_KEY' when you register the Datadog MCP server. ### can an AI agent find which deploy caused a latency spike Yes. Ask Atlas to correlate the latency regression on a service with the release marker before it, then jump to the handler it names. Atlas reads Datadog APM traces to do it. ### what is the Datadog Code Security MCP server A separate local MCP server that Datadog ships alongside the hosted one. It reads DD_API_KEY, DD_APP_KEY, and DD_SITE, and you register it in Atlas as its own entry. ### does the Datadog MCP server give access to logs and monitors Yes. Atlas queries Datadog APM traces, logs, and monitors through the hosted MCP server, subject to the toolsets you allow and the permissions on your keys. --- Canonical HTML: https://runatlas.sh/resources/integrations/datadog Source of truth: aeo_pages row `/resources/integrations/datadog` (segment: Integrations) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.