> ## Documentation Index
> Fetch the complete documentation index at: https://docs.incident.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Remote MCP server
> Connect AI assistants like Claude, ChatGPT, and coding agents directly to incident.io
The incident.io MCP server lets you connect any AI assistant that supports the [Model Context Protocol](https://modelcontextprotocol.io) directly to your incident data. Query incidents, analyse alerts, check who's on call, manage escalations, and run deep operational analysis — all from your existing AI tools.
The remote MCP server is currently in **Public Beta**. You can enable it from [Settings →
MCP](https://app.incident.io/~/settings/mcp).
**Already using the incident.io desktop app (Beta) for Mac OS?**
If so, you already have full access to everything on this page (and more). The desktop app ships with a local MCP server that provides all the MCP tools described here, plus rich support for investigations and interaction with the native Desktop UI. No additional setup is needed — if you've installed the desktop app, you're good to go!
The remote MCP server described here is for people who want to connect without installing the desktop app — for example, using Claude.ai in a browser, ChatGPT, or plugging incident.io into automated agent pipelines.
Interested in the macOS app? [Join the waitlist](https://app.incident.io/~/settings/desktop-app).
## What you can do
### Incident analysis and reporting
Ask questions across your entire incident history without manual data gathering:
* "How many P1 incidents did we have this quarter, and which teams were most affected?"
* "What's the trend in overnight responder workload by alert source?"
* "Show me the top 10 highest-workload incidents this month"
The `incident_stats` tool supports 10 grouping dimensions (severity, status, type, mode, alert source, custom fields, roles, time periods) with workload breakdowns showing where responder time is spent — during working hours, late evening, or overnight.
### Alert and noise analysis
Understand where alert noise is coming from and which areas generate the most on-call work:
* "Which alerts result in actual incidents vs noise?"
* "Break down alert volume and workload by team and service"
* "What proportion of our pages happen overnight, and what triggers them?"
You can analyse alerts by source, priority, time period, and whether they resulted in incidents. Combined with incident stats grouped by team, service, or any custom field, you can trace the full path from alert noise through to responder cost — and identify the highest-ROI improvements to make.
### On-call and escalation management
Check schedules, respond to pages, and analyse paging patterns:
* "Who's on call for the platform team right now?"
* "What's our ack rate by escalation path this month?"
* "Acknowledge the page for INC-456"
### Incident management
Create and update incidents, manage follow-ups, and access investigation data:
* "Create a P2 incident for the payments API degradation"
* "Update INC-123 to resolved"
* "What are the outstanding follow-ups from last week's incidents?"
### Structured operational analysis
Run guided analysis using built-in playbooks that provide step-by-step methodology, your organisation's configuration, and a branded HTML report template:
* "Prepare an operational review for the last quarter"
* "Analyse alert noise and recommend tuning improvements"
* "Assess on-call burden across our teams"
The `analysis_start` tool downloads a workspace with everything needed: playbooks (operational review, alert noise, on-call burden, team health, response effectiveness), your org config for reference, and a report template. The AI follows the playbook stages — collecting stats, drilling into specifics, identifying themes, and synthesising recommendations — producing much richer analysis than ad-hoc queries.
### Deep investigation
For any specific incident, access AI investigation findings, post-mortem documents, and full status update history:
* "Show me INC-123 with the investigation findings and post-mortem"
* "What was the root cause of our most recent major incident?"
* "Download the full investigation for INC-456 so I can analyse it"
Use `incident_show` with `include: ["investigation", "postmortem"]` for a summary of findings inline. For the complete investigation — all findings, checks, conversation history, and evidence — use `investigation_sync`, which downloads the full investigation filesystem as an archive.
**For hands-on investigation work on Mac OS, the desktop app (Beta) is the best experience.** It renders investigation
data inline, lets you pin incidents, and post findings directly to incident channels. The `investigation_sync` tool is
designed for automated agents and pipelines that need to pull down investigation data programmatically for LLM
analysis — for example, a coding agent that cross-references investigation findings with code changes, or an
automation that summarises investigations across multiple incidents.
### Team visibility
See which teams own what, and scope analysis to specific teams:
* "What escalation paths and alert sources does the platform team own?"
* "List all teams and their on-call schedules"
### Telemetry and observability
Query logs, metrics, traces, and dashboards across all the observability platforms you've connected via [AI SRE](/ai/investigations) — including Datadog, Grafana, Splunk, Honeycomb, Elasticsearch, GCP Cloud Logging, and more.
This works for any debugging scenario, not just active incidents. Use it to investigate production issues, check service health, run ad-hoc queries, or pull data for reports:
* "What are the error rates for the payments service over the last hour?"
* "Show me the logs around the time of INC-123"
* "Query the CPU and memory dashboards for the worker pods"
* "Are there any anomalies in the checkout service latency this week?"
* "Pull the Datadog traces for requests over 5 seconds"
The AI agent plans queries across your datasources, handles pagination and time ranges, and synthesises the results. It can search dashboards by name, query metrics with the right labels, and correlate signals across multiple platforms — saving you from switching between tabs and writing queries manually.
## Setup
The remote MCP server is available at `https://mcp.incident.io/mcp`. There are two ways to authenticate, depending on your use case.
### For interactive use (OAuth)
If you're a human connecting via an AI assistant like Claude, ChatGPT, or Cursor, you'll authenticate with your incident.io account via OAuth. The MCP client handles the flow — you just approve access in your browser when prompted. Actions are attributed to your user account, and you see the same data you'd see in the dashboard.
Add the remote MCP server:
```bash theme={null}
claude mcp add incident-io --transport http https://mcp.incident.io/mcp
```
Claude Code will prompt you to authorise via your browser on first use.
Add the server to your Codex MCP configuration at `~/.codex/config.toml`:
```toml theme={null}
[mcp_servers.incident_io]
type = "url"
url = "https://mcp.incident.io/mcp"
```
Codex will prompt you to authorise on first use.
Open Cursor settings and navigate to **MCP Servers**. Click **Add Server** and enter:
* **Name:** incident.io
* **Type:** HTTP
* **URL:** `https://mcp.incident.io/mcp`
Cursor will prompt you to authorise via your browser.
1. Open Claude Desktop.
2. Go to **Connectors** (or **Customize → Connectors**).
3. Click the **+** next to Connectors.
4. Choose **Add custom connector**.
5. Enter the MCP server URL: `https://mcp.incident.io/mcp`
6. Complete the authorisation flow with incident.io.
7. The connector should then appear in Claude's connected tools.
incident.io is currently available as a custom connector only. We're working on getting it listed in the Claude connector marketplace — stay tuned.
1. In ChatGPT, go to **Settings → Integrations**.
2. Search for "incident.io" or add a custom MCP server with URL `https://mcp.incident.io/mcp`.
3. Authorise access when redirected to incident.io.
### For automated systems (API keys)
If you're connecting programmatic agents, custom workflows, or automation pipelines, use an API key. API keys authenticate as a service actor rather than a specific user, and don't expire until deleted.
1. Go to **Settings → API keys** in your incident.io dashboard.
2. Create a new API key with the scopes you need.
3. Pass it as a Bearer token in the `Authorization` header when connecting your MCP client to `https://mcp.incident.io/mcp`.
For example, to test connectivity, send the MCP `initialize` request — every MCP client opens a session with this call, and a successful response confirms that the endpoint is reachable, your API key is valid, and the protocol version is compatible:
```bash theme={null}
curl -X POST https://mcp.incident.io/mcp \
-H "Authorization: Bearer your-api-key" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-11-25",
"capabilities": {},
"clientInfo": { "name": "curl", "version": "0.0.1" }
}
}'
```
To list or call tools beyond this connectivity check, use a real MCP client library — calling tools by hand requires completing the rest of the MCP handshake and parsing server-sent events.
This is ideal for integrating incident.io into your own agents, n8n workflows, Dust, or custom automation pipelines.
## Getting the most out of it
### Read the configuration first
Before filtering or grouping, ask the tools for your organisation's configuration — it lists your severity levels, custom fields, roles, and other values you'll need:
* Use the `resource_show` tool with `resource: "organisation"`, or
* Read the `config://organisation` resource directly (if your client supports MCP resources)
### Use includes for deeper analysis
When investigating an incident, always request the investigation and post-mortem data:
```
incident_show(id: "INC-123", include: ["investigation", "postmortem"])
```
Without these, you only get the basic metadata. With them, you get the AI's analysis of what happened, the team's written post-mortem, and all the evidence gathered during investigation.
### Start with stats, then drill in
For analytical questions, follow the **stats → list → show** pattern:
1. `incident_stats` to get the shape (counts, workload, trends)
2. `incident_list` to browse the interesting groups
3. `incident_show` to get full details on specific incidents
This is much more efficient than paginating through individual incidents.
### Use playbooks for structured analysis
For periodic reviews or deep analysis, use `analysis_start` rather than querying tools ad-hoc. It downloads a workspace with playbooks that guide the AI through a multi-stage process — scoping, data collection, deep dives, theme identification, and synthesis — producing structured recommendations and an HTML report. This consistently produces better results than asking open-ended analytical questions.
### Send feedback
If you hit friction or wish a tool worked differently, use the `feedback` tool to let us know. Your AI assistant will prompt you about this after completing tasks — approve the feedback to help us prioritise improvements.
## Available tools
| Tool | Description |
| ---------------------- | ---------------------------------------------------------------------------------- |
| `alert_list` | Search and browse alerts |
| `alert_show` | Full alert details with linked incidents |
| `alert_source_list` | List configured alert sources |
| `alert_stats` | Alert counts with workload from linked incidents |
| `analysis_start` | Start a structured operational analysis with playbooks and report template |
| `ask` | AI agent for on-call queries, schedule management, and general questions |
| `ask_incident` | AI agent for incident investigation and management actions |
| `ask_telemetry` | AI agent for querying logs, metrics, traces, and dashboards |
| `catalog_entry_list` | Browse entries in a catalog type |
| `catalog_entry_show` | Full catalog entry with all attributes |
| `catalog_type_list` | List catalog types (Service, Team, etc.) |
| `escalation_list` | Search escalations (pages) |
| `escalation_path_list` | List escalation paths |
| `escalation_path_show` | Who would be paged at each level |
| `escalation_respond` | Acknowledge or decline a page |
| `escalation_show` | Full escalation details with transition history |
| `escalation_stats` | Paging counts by path, priority, time of day |
| `feedback` | Submit feedback about the tools |
| `follow_up_create` | Create a follow-up on an incident |
| `follow_up_list` | List post-incident follow-ups |
| `incident_create` | Create a new incident |
| `incident_list` | Search and browse incidents with filters, sortable by workload |
| `incident_show` | Full incident details with optional investigation, post-mortem, and update history |
| `incident_stats` | Aggregate counts and workload by 10+ dimensions |
| `incident_update` | Update incident fields (status, severity, roles, custom fields) |
| `incident_update_list` | Full status update history for an incident |
| `investigation_sync` | Download a full investigation as an archive for LLM analysis |
| `resource_show` | Read organisation config, analysis playbooks, or telemetry datasources |
| `schedule_list` | List on-call schedules |
| `schedule_show` | Schedule details with current and upcoming shifts |
| `team_list` | List teams |
| `team_show` | Team details with owned escalation paths, alert sources, and schedules |