Hey, I’m trying to setup a new automation which can use the DataDOG MCP tool. But, I am struggling to understand what needs to be placed into the “Server URL” field - the placeholder is “DD_MCP_DOMAIN”, but I am assuming this URL needs to contain some for of auth?
https://cursor.com/automations/new
I have tried using a variety of values in this field and all result in either “fetch failed” or “insert URL”.
Can someone point me in the right direction for this, please?
Hey, this is a known issue. The Datadog MCP dialog in Automations fails with “fetch failed” no matter what URL you enter. The team knows about it, and your report helps us prioritize.
For now, there isn’t a workaround in the Automations UI. I’ll update this thread if there’s any news.
Thanks Dean and Greg. I’ve been working with Datadog to try and pinpoint this. Here is my context:
Bug: Datadog MCP Streamable HTTP auth headers not forwarded on CallTool POST requests
Cursor Version:
Version: 2.6.19
VSCode Version: 1.105.1
Commit: 224838f96445be37e3db643a163a817c15b36060
Date: 2026-03-12T04:07:27.435Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 23.6.0
Request ID: 20825dfa-856e-469e-8de7-56ee95795eec
Transport Type: Streamable HTTP
The Datadog MCP server returns “Forbidden / Failed permission authorization checks” on every CallTool POST from both local and cloud agents, while the same hardcoded API credentials work perfectly in the MCP Inspector. Listing operations (listOfferings, listPrompts) succeed – only tool execution fails.
I’ve been troubleshooting this with both Datadog Premier Support and Cursor Support. Here’s what we’ve established:
| Client | listOfferings | CallTool (search_datadog_rum_events) |
|---|---|---|
| MCP Inspector (Streamable HTTP) | Works | Works (10,277 RUM events returned) |
| Cursor local agent | Works | Forbidden |
| Cursor cloud agent | Works | Forbidden |
Same literal API key and application key used across all three clients – hardcoded in mcp.json, not using ${env:...} interpolation
Datadog confirmed their MCP server is working correctly (Premier Support ticket open)
Key permissions confirmed – the MCP Inspector proves the keys have the required rum_read scope
API key permissions – Inspector returns data with the same keys
Environment variable resolution – keys are hardcoded, not interpolated
MCP server issues – Datadog confirms their side is healthy
Connection/transport issues – MCP logs show the connection is healthy; listOfferings succeeds and status recovers to connected after each failed tool call
14:21:47.871 [info] Handling CallTool action for tool ‘search_datadog_rum_events’
14:21:47.874 [info] Calling tool ‘search_datadog_rum_events’
14:21:48.058 [error] Client error for command Streamable HTTP error: Error POSTing to endpoint: {“errors”:[“Forbidden”,“Failed permission authorization checks”]}
14:21:48.059 [warning] [V1] connected → error
14:21:48.059 [error] Error calling tool ‘search_datadog_rum_events’: Streamable HTTP error: Error POSTing to endpoint: {“errors”:[“Forbidden”,“Failed permission authorization checks”]}
14:21:48.059 [warning] callTool result contains auth error
14:21:48.660 [info] listPrompts: Found 0 prompts
14:21:48.817 [info] Recovering status from ‘error’ to ‘connected’ after successful listOfferings
The pattern strongly suggests auth headers (DD_API_KEY / DD_APPLICATION_KEY) are present for connection and listing operations but are not being forwarded on CallTool POST requests. This is reproducible across both local and cloud agents with hardcoded credentials, and is isolated to Cursor’s MCP client – the MCP Inspector sends the same request successfully.
Configure Datadog MCP server in mcp.json with Streamable HTTP transport and hardcoded DD_API_KEY / DD_APPLICATION_KEY headers
Confirm the server connects successfully (tools list in Settings > Tools & MCP)
Call any Datadog tool (e.g. search_datadog_rum_events) from either a local or cloud agent
Observe Forbidden error in MCP logs
Run the same query in MCP Inspector (npx @modelcontextprotocol/inspector) with identical endpoint and headers – observe it succeeds
I tried this again today and it worked. The only part you need to enter in the URL field is the domain and subdomain, e.g. “mcp.datadog.com”. Authentication is then triggered.
@Greg_Farrow thanks for the reply. Confirmed and the MCP is now working. Thanks!
