"Show me all critical incidents from the last week."
"Create an incident for the payment API being down."
"What was the root cause of that database incident last Tuesday?"
If you've ever wished you could just ask Claude (or any MCP client) to handle incident management tasks instead of context-switching between chat and your incident management dashboard, you're going to like what we built.
The Model Context Protocol (MCP) is Anthropic's new standard for connecting AI assistants to external data sources and tools. Think of it as a way to give Claude access to your systems through a structured, secure interface.
Instead of Claude living in isolation, MCP servers act as bridges to your actual tools and data. Claude can read from them, write to them, and help you get work done without leaving the conversation.
So we built one. The incident.io MCP server is a Golang bridge that connects Claude (or any MCP-compatible AI assistant) directly to your incident.io account.
Here's what you can do once it's set up:
Get incident information:
Create and manage incidents:
Search and analyze:
Maybe you just want to load up your incident.io environment with fun incidents? As an example, this Claude prompt:
Create 4 sample incidents based on funny moments from the TV show 'The Office'
Generated these incidents via the MCP server
Fair warning: this is largely vibe-coded and unsupported. Chris Evans and I built this because we wanted it to exist, not because we had a roadmap requirement or huge customer demand.
The architecture is straightforward:
// Core structure - it's an MCP server that translates natural language
// requests into [incident.io](<http://incident.io>) API calls
server := mcp.NewServer()
server.AddTool("list_incidents", listIncidents)
server.AddTool("create_incident", createIncident)
server.AddTool("update_incident", updateIncident)
// ... and so on
Each tool maps to one or more incident.io API endpoints. When Claude wants to "show me critical incidents," the MCP server translates that into the correct API call, fetches the data, and formats it for Claude to understand and present back to you.
The magic is in the tool descriptions, we spent time making sure Claude understands what each function does and when to use it:
{
Name: "list_incidents",
Description: "List incidents with optional filtering by status, severity, date range, etc.",
InputSchema: map[string]interface{}{
"type": "object",
"properties": map[string]interface{}{
"status": {
"type": "string",
"description": "Filter by incident status (open, closed, etc.)",
},
// ...
},
},
}
This gives Claude enough context to know when and how to call our functions, while keeping the interface natural and conversational.
The server is open source (MIT licensed) and available on GitHub: https://github.com/incident-io/incidentio-mcp-golang
To set it up:
go install [github.com/incident-io/incidentio-mcp-golang@latest]
{
"mcpServers": {
"incidentio": {
"command": "incidentio-mcp-golang",
"env": {
"INCIDENT_IO_API_KEY": "your-api-key-here"
}
}
}
}
Restart Claude Desktop and you're ready to go.
Now you can ask Claude things like "What incidents do we have open?" and it'll know the answer.
Again, this is largely vibe-coded. We built it because we wanted it, and we're sharing it because maybe you want it too?
If you run into issues, the GitHub repo is the best place to file them. We can't promise rapid fixes, but we're interested in making it better if there's interest.
And if you're not using incident.io yet but this sounds useful, you can start a free trial at incident.io. The MCP server works with any paid incident.io account, and we let trial users access an API key for a couple of weeks.
One more thing: if you build something cool with this, or extend it in interesting ways, let us know. We love seeing what people build with our tools.
This post explores how a basic idea turned into a working Apple TV dashboard powered by the incident.io API. Using Claude Code and a “vibe coding” approach, the app was built in a few hours, complete with real-time incident data, dual themes (including a Wargames-inspired view), and no Swift experience :)
Although we have flexible working, we love being in-person. This covers some of the reasons that we're office first - including building connections, working at pace, and having a lovely time doing it.
We launched our list of Top engineering voices to follow in 2025 to spotlight those engineers who aren’t just building behind the scenes, but also writing, posting, and contributing in ways that make the whole community smarter.
Ready for modern incident management? Book a call with one of our experts today.