Model Context Protocol (MCP) is quickly becoming the standard way to connect AI assistants to other tools. To help ops teams take advantage of that shift, ilert has built an open MCP server that lets assistants like Claude and Cursor securely interact with ilert, from checking who’s on call to creating and managing incidents.
This post explains MCP in simple terms, why ilert invested in it, how the server is designed, and how you can connect your favorite MCP client today.
This is a shorter version of the article first published by ilert engineer Tim Gühnemann.
MCP Basics
The Model Context Protocol is an open standard that gives AI assistants a consistent way to access external tools and data. Instead of building one-off plugins for every assistant, MCP defines common interfaces for:
- Tools (actions an assistant can take)
- Resources (data it can read)
- Transports (how communication happens)
In other words, MCP is like a “USB-C for AI apps”: one interface that works across many clients. With MCP, assistants can read data, run operations, and stream results in a way that supports permissions and audit trails — much more reliable than UI automation or brittle scripts.
Many clients already support MCP. Claude Desktop can connect to MCP servers through extensions and connectors, while Cursor lets you add them in Tools & MCP and use them directly in the IDE chat.
For ops teams, this means assistants can read incidents, alerts, and schedules and then act on them (acknowledge, escalate, resolve, create incidents) through permissioned API calls rather than screen scraping.
Reasons we introduced an open MCP server for ilert
AI agents are increasingly used where teams already collaborate: chats, terminals, and IDEs. ilert’s focus is to bring incident response into those environments while keeping access safe, scoped, and fully auditable.
Problem: AI assistants need a secure, consistent way to work with alerts and incidents across different clients — without custom integrations for each one.
Outcome: MCP lets ilert expose capabilities once and make them instantly usable in any MCP-compatible assistant. Less context switching, fewer handoffs.
Architecture of the ilert MCP server
Tech stack
- Runtime: Deno + TypeScript
- SDK: Official MCP TypeScript SDK
- Transport: Streamable HTTP (recommended in the MCP spec)
- Hosting: Remote MCP server at https://mcp.ilert.com/mcp
The server uses the official SDK to provide MCP-compliant tools, resources, and prompts. We expose it remotely over Streamable HTTP, which supports streaming responses, resumable sessions, and simple authentication headers — a good fit for enterprise environments. (stdio is supported too, but Streamable HTTP is the default recommendation.)
How we map ilert to MCP
ilert’s MCP server exposes tool actions that map directly to the ilert API and common DevOps/SRE workflows. Assistants can safely read context and take action on Alerts and Incidents without relying on UI scripting.
What you can do
- Manage alerts: list, inspect, comment, acknowledge, resolve, escalate, reroute, add responders, and run predefined actions.
- Open incidents: create incidents with severity, service, and responders right from your assistant.
- Look up context: find users, services, alert sources, escalation policies, schedules, and your own profile.
Typical flow
- Use read tools to gather context (e.g., services → alerts → alert details).
- Suggest and confirm a write action (e.g., acknowledge or resolve an alert, create an incident, run an alert action).
- Execute through scoped ilert API keys so everything stays permissioned and auditable.
Real-world scenarios
Scenario 1: Create an alert in ilert
Use your assistant to locate the right service, confirm severity, and create an alert through MCP tools — all without leaving your chat or IDE.
Scenario 2: Comment on an incident and resolve it
Ask the assistant to fetch the incident context, add an update, and resolve or escalate once confirmed — with every step logged via API scopes.
Learn more about ilert AI capabilities here.
Top comments (0)