Datadog MCP setup: region, OAuth and a first query
Start with your organisation’s Datadog site. Then check a known service within a fixed time window.
Investigating a deployment error requires the service, environment and time range to agree. Start with an incident that you can already see in Datadog. This guide connects the documented remote endpoint and proposes a small initial read test. Your account must already have access to the data you intend to examine.
Choose the endpoint for your Datadog site
Datadog publishes a separate MCP endpoint for each supported site. This example uses the European site at https://mcp.datadoghq.eu/v1/mcp. US1 uses https://mcp.datadoghq.com/v1/mcp; consult the vendor setup page for other sites. Choose the site of your account, rather than the location of your computer. Authentication uses OAuth.
{
"servers": {
"datadog": {
"type": "http",
"url": "https://mcp.datadoghq.eu/v1/mcp"
}
}
}Add the entry to .vscode/mcp.json. Start it in the editor and complete browser sign-in. The VS Code guide explains the file. Explicitly check which organisation is selected in the authentication window before granting access.
Set three boundaries for the first investigation
| Field | Set before querying | Check in the response |
|---|---|---|
| Service | Record the exact service name | Results belong to the same service |
| Environment | Choose staging or production | The environment filter is retained |
| Time | Start and end with a time zone | Results fall inside the window |
Find an event you already know
Open a known log sample in the Datadog interface. Record the service, environment, fixed time window and a distinguishing field from one event.
Inspect the tools available in the client and choose a suitable read operation. Availability also depends on enabled toolsets and your account permissions.
Request the same sample. Specify fixed time boundaries and a limited result set instead of asking for every log in the organisation.
Compare the timestamp and distinguishing field with the known event. Save the query, result and date in a short test note. Expand the window or change the service only after this match succeeds.
Investigate an empty result systematically
Change one setting at a time when a response is empty. Check the site and organisation first, followed by the service filter and time boundaries. Successful authentication establishes account access; it does not establish that every query must return a result. A different index or time zone can also distort the comparison. Record which checks you actually completed.
Use the monitoring and logs comparison when choosing a data source. The permissions guide helps define the access scope. The Datadog registry search separately shows which entries and sources the registry holds.
- Does the EU endpoint work for every Datadog account?
- No. Match the endpoint to the site hosting your organisation. Your own physical location does not determine the correct address.
- Do I need API keys in this JSON example?
- This example uses OAuth sign-in through the client, so it contains no API or application keys. Other documented authentication methods have their own requirements.
- Why are some tools missing after sign-in?
- Check the toolset selection and account permissions. Compare the tools actually exposed to the client with the vendor documentation.
- Does a missing event prove that an error is fixed?
- No. Repeat the original query with identical boundaries in the web interface. An invisible result can also be caused by selection or access limitations.
Documentation read on 3 October 2026. The tests described here are suggestions for your own environment.
- Datadog: MCP setup and regional endpoints
Show retrieval command
curl -s https://docs.datadoghq.com/mcp_server/setup/ - Datadog: MCP tools
Show retrieval command
curl -s https://docs.datadoghq.com/mcp_server/tools/ - VS Code: MCP configuration
Show retrieval command
curl -s https://code.visualstudio.com/docs/agent-customization/mcp-servers