An open-source alternative to Datadog’s MCP Server.

What Datadog’s MCP Server actually is

Datadog released its MCP Server in March 2026. The product collects telemetry from MCP servers: tool call counts, per-tool latency, error rates by tool name, and token usage where the model surfaces it. The telemetry ships into Datadog’s existing analytics tier, where it sits alongside APM traces, logs, and infrastructure metrics from the rest of your Datadog stack.

Datadog handles the instrumentation side: the MCP Server component auto-discovers MCP servers running in supported environments and collects telemetry without requiring you to add OTel spans to each tool handler yourself. Pre-built dashboards surface the collected data. Alerts integrate with Datadog’s existing monitor configuration. If your team uses Datadog for APM, you get cross-signal correlation out of the box: a slow tool call sits alongside the APM trace that contained it.

The requirements are straightforward: a Datadog account, a Datadog contract, and the Datadog agent running in your environment. The pricing follows Datadog’s standard observability tier, so MCP transaction volume adds to your existing bill in the same way that spans and logs do. There is no separate MCP-specific SKU; the data flows into the platform you already pay for.

This is a closed-source product. The telemetry leaves your infrastructure and lands in Datadog’s cloud. For many teams, that is exactly what they want: managed infrastructure, polished dashboards, and one vendor for all observability signals. For other teams, it is the problem.

Who needs an alternative

Three kinds of teams read this guide with a real need.

Teams without Datadog. The majority of engineering teams that run MCP servers do not have a Datadog contract. Datadog’s pricing starts at a level that makes sense for larger organizations with substantial observability budgets. A team running one or two MCP servers on a small VPS is not going to sign a Datadog contract to get tool-call latency charts. They need an alternative from the start.

Teams with data-residency requirements. Regulated industries, government contractors, and teams operating in certain jurisdictions cannot ship application telemetry to a US-based SaaS provider without a specific compliance agreement in place. Tool-call data from an MCP server can include argument shapes, error messages, and timing information that the compliance team treats as sensitive. The requirement is on-premises telemetry storage, not managed cloud storage. The self-hosted stack satisfies this requirement; Datadog’s MCP Server does not, regardless of BAA or data-processing agreements.

Teams questioning the Datadog bill. Datadog billing based on transaction volume creates a cost that grows with usage. As MCP servers become more central to production AI agent systems, the tool-call volume and the associated observability bill grow together. A team that already runs urgentry and an OTel Collector can absorb MCP telemetry at essentially zero marginal cost. Paying Datadog’s observability tier rates on top of existing urgentry infrastructure is difficult to justify when the self-hosted path covers the same data.

What “alternative” means in this context

An alternative to Datadog’s MCP Server is not a single product. It is a stack of three components that together cover the same data pipeline Datadog handles as a managed service.

Component one: an instrumented MCP server. Your MCP server needs to emit OTel spans for each tool call. The MCP Python and TypeScript SDKs do not ship OTel instrumentation by default. You add spans by wrapping each tool handler with a tracer call. The companion guide MCP server observability covers this instrumentation in full, with Python and TypeScript examples. The span attributes you set on each call — tool name, latency, argument shape, result count, error status — become the raw data that the rest of the stack stores and queries.

Component two: an OTel Collector. The OTel Collector receives spans from your MCP server via OTLP, can enrich or filter them, and forwards them to your backend. In a simple single-backend setup the Collector is optional; your MCP server can export directly to urgentry via OTLP/HTTP. The Collector becomes valuable when you need batching, retry logic across network interruptions, or a fan-out period where spans go to both urgentry and Datadog during migration.

Component three: urgentry as the OTLP backend. urgentry accepts OTLP/HTTP at port 4318, the same port as any standard OTLP receiver. Spans from your MCP server land in urgentry’s trace storage. You query them by attribute, build dashboards from the data, and set alerts on span-derived metrics. This is where Datadog’s managed polished dashboards are replaced with panels you configure yourself.

The data pipeline the self-hosted stack implements is functionally equivalent to what Datadog’s MCP Server delivers. The difference is in setup time, dashboard quality out of the box, and who manages the infrastructure.

The self-hosted stack

Here is how the three components connect in a production deployment.

Step 1: instrument your MCP server. Add the OTel SDK to your MCP server and wrap each tool handler with a span. The minimum viable span carries three attributes: mcp.tool.name, an error status if the handler raises, and the span duration (which the SDK captures automatically). Richer attributes like argument shape, result count, and schema validation result improve your ability to build useful dashboards later.

pip install opentelemetry-api opentelemetry-sdk \
    opentelemetry-exporter-otlp-proto-http

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.resource import Resource
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from opentelemetry.trace import StatusCode
import os

resource = Resource.create({
    "service.name": "my-mcp-server",
    "mcp.server.name": "my-mcp-server",
})

exporter = OTLPSpanExporter(
    endpoint=os.environ["OTEL_EXPORTER_OTLP_ENDPOINT"] + "/v1/traces",
)
provider = TracerProvider(resource=resource)
provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(provider)
tracer = trace.get_tracer("mcp-server")

Each tool handler wraps its body in a span:

@mcp_server.tool()
async def fetch_document(doc_id: str) -> dict:
    with tracer.start_as_current_span("mcp.tool.fetch_document") as span:
        span.set_attribute("mcp.tool.name", "fetch_document")
        try:
            result = await _fetch(doc_id)
            span.set_attribute("mcp.tool.result.size_bytes", len(str(result)))
            return result
        except Exception as exc:
            span.record_exception(exc)
            span.set_status(StatusCode.ERROR, str(exc))
            raise

Step 2: deploy the OTel Collector (optional but recommended). A minimal Collector config receives spans from your MCP server and forwards them to urgentry:

receivers:
  otlp:
    protocols:
      http:
        endpoint: "0.0.0.0:4318"

exporters:
  otlphttp:
    endpoint: "https://your-urgentry-host"

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp]

During a migration period where you want spans flowing to both urgentry and Datadog, add a second exporter to the Collector and fan out from the pipeline. When you are satisfied with urgentry coverage, remove the Datadog exporter entry.

Step 3: run urgentry. urgentry runs as a single Go binary. The install is one command:

curl -fsSL https://urgentry.com/install.sh | sh
./urgentry serve --role=all

On a $5 1 vCPU / 1 GB VPS, urgentry sits at roughly 52 MB resident memory at 400 events per second. For an MCP server handling a few hundred tool calls per day, this is well within headroom. OTLP/HTTP lands on port 4318. The Sentry envelope endpoint lands on port 9000 alongside it, in the same binary, if you also use urgentry for error tracking.

Point your MCP server’s OTel exporter at the Collector (or directly at urgentry if you skip the Collector):

export OTEL_EXPORTER_OTLP_ENDPOINT=http://your-collector-host:4318
export OTEL_SERVICE_NAME=my-mcp-server
export OTEL_RESOURCE_ATTRIBUTES=mcp.server.name=my-mcp-server

Feature comparison

Eight rows covering the relevant surfaces.

Honest gaps

urgentry does not have pre-built MCP dashboards today. That sentence deserves full weight.

When you connect your MCP server to Datadog’s MCP Server product, you get working dashboard panels immediately: tool call rate by tool name, latency distribution, error rate over time, token usage trends. The data is collected automatically and the visualizations are configured for you. No span attributes to define, no dashboard panels to build, no alert thresholds to decide.

With urgentry, the span data arrives and you build the dashboards yourself. You decide which attributes to query, which aggregation to use, which thresholds to set. That is real work. A team that instructs one engineer to spend an afternoon on it gets working dashboards by end of day. A team that has no one to spend that afternoon ends up with data in urgentry and no way to see it quickly. This is the concrete cost of the self-hosted path, and it should factor into your decision.

The roadmap for urgentry includes MCP-specific dashboard templates, but “it’s on the roadmap” does not help your on-call rotation today. If pre-built dashboards are the requirement, Datadog is currently ahead on this specific point.

Worked migration shape

If your team currently uses Datadog’s MCP Server and wants to evaluate moving off it, the migration has a safe, reversible shape. The goal is to get to a state where urgentry covers your actual alert requirements before removing Datadog from the signal path.

1. Instrument with OTel first. If your MCP server currently relies on Datadog’s auto-discovery to collect telemetry, add explicit OTel spans to each tool handler now. See the instrumentation section above or the companion guide for full examples. This step is independent of which backend you use; OTel spans can go to Datadog and urgentry in parallel.

2. Deploy the OTel Collector with fan-out. Configure the Collector to forward spans to both urgentry and Datadog simultaneously. Your existing Datadog dashboards and alerts continue working. urgentry starts receiving the same data in parallel. Run both for a week. Verify that span data appears in urgentry and matches what Datadog shows.

exporters:
  otlphttp/urgentry:
    endpoint: "https://your-urgentry-host"
  datadog:
    api:
      key: ${env:DD_API_KEY}

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp/urgentry, datadog]

3. Build your urgentry dashboard panels. While the fan-out runs, build the MCP-specific dashboard in urgentry. At minimum: tool call rate by mcp.tool.name, p95 latency by tool name, error rate by tool name. These three panels cover the most common on-call scenarios for MCP server incidents.

4. Move alerts one by one. Once your urgentry panels show the same data as Datadog, re-create your alert conditions in urgentry. Test each alert by triggering the condition deliberately on a staging MCP server. When an alert fires in urgentry, mark the equivalent Datadog monitor as muted.

5. Remove the Datadog exporter. When all MCP-related alerts are at parity in urgentry and have been muted in Datadog for at least one full on-call rotation, remove the Datadog exporter from the Collector config. Cancel the Datadog MCP add-on billing component.

The fan-out period is the safety net. You do not move to urgentry until urgentry is actually covering the alerts you care about. The migration fails safely if you find urgentry does not cover a scenario: Datadog is still running the whole time.

When Datadog wins anyway

Three situations where staying with Datadog’s MCP Server is the right call.

You already pay for Datadog and use it for APM. If your team has Datadog APM running across your services, adding MCP Server telemetry to the same platform costs you configuration time, not additional money in many contract structures. The cross-signal correlation between an APM trace and the MCP tool call that happened inside it is genuinely valuable for debugging agent failures. Moving that one signal to urgentry breaks the correlation and creates a two-tab investigation workflow. The marginal cost of keeping MCP telemetry in Datadog is low when the contract already covers it.

You need the cross-signal correlation with logs and infrastructure metrics. Datadog’s MCP Server product sits inside an ecosystem where logs, metrics, traces, and now MCP tool calls are correlated by default. If you run an AI agent system where understanding an MCP tool failure requires looking at the database slow-query log that happened at the same moment, and that log is already in Datadog, urgentry adds an investigation hop instead of removing one.

Your team has no capacity to build dashboards. The gap described in the honest gaps section is a blocker if nobody on your team can spend the time to configure urgentry dashboards. Pre-built dashboards from Datadog are working dashboards today. A self-hosted stack with no dashboards is a data warehouse with no query interface from an operational standpoint.

When self-host wins

Three situations where the self-hosted stack is clearly the better fit.

Data residency requirements. If your compliance posture requires that application telemetry stays in your own infrastructure, urgentry satisfies that requirement and Datadog’s MCP Server does not. This is a binary constraint, not a cost-benefit calculation. The comparison ends here for regulated teams.

Cost at scale. A team running ten MCP servers with high tool-call volume accumulates observability charges under Datadog’s volume-based billing. urgentry at 52 MB on a $5 VPS handles 400 events per second without additional billing. At the point where Datadog MCP observability costs more per month than the VPS urgentry runs on, the self-hosted math is decisive.

You already run OTel and urgentry. Teams that run urgentry for error tracking and OTLP trace storage already have the backend. Adding MCP server telemetry means instrumenting the MCP server handlers with OTel spans, which takes a few hours, not days. The marginal cost of MCP observability on an existing urgentry deployment is close to zero. This is the situation where the self-hosted path has the lowest friction of any option.

Frequently asked questions