Incident Triage with MCP: A Step-by-Step Playbook (Sentry and Datadog)

Incident triage is the first hour of a production problem: someone on call works out what broke, how many users it hits and where to look first. That person usually jumps between an error tracker, a log search and a tracing view. With MCP (Model Context Protocol), a coding agent can pull the same Sentry errors and Datadog logs, metrics and traces into one conversation, so the engineer spends less time copying stack traces and more time deciding.

This playbook uses only tools that Sentry and Datadog document as of October 2026. It keeps the AI in a read-and-summarize role. A person still decides on rollbacks, fixes and customer messages.

What you need

• Sentry MCP server. See our Sentry MCP server profile. Sentry's hosted MCP page says every connection uses OAuth, and you can scope the URL to /mcp/{organizationSlug}/{projectSlug}. Scoped connections default tools to that project and hide some discovery tools.
• Datadog MCP Server. See our Datadog MCP server profile. Datadog's overview describes it as a bridge "between your observability data in Datadog and any AI agents" and notes it is "under significant development."
• A coding agent that speaks MCP. Claude Code, Cursor and VS Code all work with remote servers. Our guides cover connecting Claude Code to Sentry and connecting Claude Code to Datadog.
• Accounts with the right read permissions. Datadog says the server "cannot grant a user access beyond what that user already has," so the on-call engineer's own role sets the limit.

The workflow

1. Confirm the incident in Datadog. Ask the agent to list open incidents with search_datadog_incidents, then pull the one you care about with get_datadog_incident. Both are read tools in the core toolset, per Datadog's tools reference, and need the Incidents Read permission.
2. Check which monitors fired. Use search_datadog_monitors to see alerting monitors around the incident start time. If you enable the alerting toolset, search_datadog_monitor_groups breaks results down by group.
3. Find the matching errors in Sentry. Ask the agent to search issues and errors for the affected service and time window. Sentry's README names search_issues and search_errors among its AI-powered search tools, which turn plain-English questions into Sentry's query syntax.
4. Read the logs. Use search_datadog_logs for raw lines, and analyze_datadog_logs to group and count them. Both need Logs Read Data and Logs Read Index Data.
5. Follow a slow or failing request. Use search_datadog_spans or aggregate_spans to find bad spans, then get_datadog_trace for one full trace. In Sentry, search_traces covers the same ground for Sentry-instrumented services.
6. Check the blast radius. search_datadog_hosts shows affected hosts, and search_datadog_entities searches the service catalog for dependencies. get_datadog_metric pulls the error-rate or latency series.
7. Write the triage note. Ask the agent for a short summary: symptom, start time, affected services, top error, suspected cause and open questions. If your team keeps notes in Datadog, create_datadog_notebook is a write tool that needs Notebooks Write; keep it off until you trust step 1 to 6.
8. Hand off. The on-call engineer reviews the note, decides on rollback or fix, and owns the incident update.

Example prompts

• "List active Datadog incidents with severity SEV-1 or SEV-2 and show the details of the newest one."
• "In Sentry, search issues in the checkout project that first appeared in the last two hours. Rank them by event count."
• "Analyze Datadog logs for service:payments with status:error since 14:00 UTC and group them by error message."
• "Find the slowest spans for the checkout service in the last 30 minutes and open the full trace for the worst one."
• "Write a triage note: what broke, when it started, which monitors fired, top Sentry issue, and what we still don't know."

Guardrails

• Scope Sentry to one project. Sentry says "Scoping to a project is recommended when possible." You can also limit skills with ?skills=inspect,triage or drop one with ?disable-skills=seer, per the README.
• Keep Datadog to core at first. Only core is on by default. Datadog lets you add toolsets with the toolsets query parameter, so leave write-heavy and Preview toolsets off until you need them.
• Use a read-only role. Datadog checks the matching permission on each tool call, so a role without write permissions blocks write tools.
• Watch the token scopes for self-hosted Sentry. The stdio mode's token list includes project:write, team:write and event:write, per the README. Treat that token as a secret.
• Expect sensitive data. Logs and error events can hold customer details and secrets, and whatever the agent reads lands in its context. Read data exfiltration through MCP before you connect production data.
• Mind rate limits. Datadog lists fair-use limits of 50 requests per 10 seconds and 100,000 tool calls a month, "subject to change." Sentry advises running calls one at a time if you hit a Rate Limited message.
• Keep decisions human. Rollbacks, feature-flag changes and customer messages stay with the on-call engineer. The MCP project's security best practices also warn against broad, omnibus scopes.

What to measure

• Time to first triage note from page to written summary, compared with incidents handled without the agent.
• Accuracy of the suspected cause, judged by the engineer after the postmortem.
• Tool calls per incident, from Datadog Audit Trail (filter on "MCP Server"), to spot loops and wasted calls.
• Rate-limit hits in both services.
• Data exposure events, such as a summary that quoted a token or customer email, logged and reviewed.

Don't compare against made-up baselines. Record your own numbers for a few weeks before and after.

Next step

More playbooks live in the MCP playbooks hub. If you want help wiring Sentry, Datadog and your coding agent together with sensible scopes, see our Claude Code development service.

Frequently asked questions