ilert MCP Server: All Tools and Schemas

Introduction

The ilert MCP server provides a comprehensive interface for on-call management, incident response, and alert handling. ilert is an AI-first incident management platform used by companies like Lufthansa Systems, REWE Digital, and Bertelsmann to optimize incident management, improve reliability, and minimize downtime.

This MCP server exposes tools across several key categories: alert management (listing, accepting, resolving, commenting, escalating, and rerouting alerts), incident management (creating, updating, and listing incidents), and team coordination (finding users, schedules, escalation policies, and services). It also supports invoking automated actions and workflows on alerts through webhook integrations.

Together, these tools enable a full incident response lifecycle—from detecting and triaging alerts, coordinating responders, escalating to the right teams, to tracking and communicating major service disruptions through structured incidents.

Use Cases

1. Reviewing and Managing Personal Alerts

Combine get-my-profile and list-alerts (with the assignedTo parameter) to see alerts assigned to you and take action on them.

Sample prompt: Show me all my open alerts that are currently pending or in progress

2. Accepting and Resolving an Alert

Use show-alert-details, accept-alert, comment-alert, and resolve-alert to work through an incident from start to finish.

Sample prompt: Accept alert 4521, add a comment that I'm investigating the database connection issue, then resolve it once done

3. Escalating an Alert to Another Level

Use show-alert-details to see escalation levels, then escalate-alert when you can't handle the issue yourself.

Sample prompt: Escalate alert 3390 to level 2 because I don't have access to the payment gateway systems

4. Rerouting a Misassigned Alert

Combine find-escalation-policies and reroute-alert to redirect an alert to the correct team.

Sample prompt: Alert 2201 was sent to the wrong team — reroute it to the Network Operations escalation policy

5. Adding Collaborators to an Incident

Use find-users or find-schedules with add-responder-to-alert to bring in additional expertise.

Sample prompt: Add responder Sarah Chen to alert 1180 so she can help troubleshoot the Kubernetes cluster

6. Checking Who Is On Call

Use find-schedules to see current and upcoming on-call rotations.

Sample prompt: Who is currently on call for the backend team, and who is next in the rotation?

7. Manually Creating an Alert

Combine find-alert-sources, find-escalation-policies, and create-alert to raise an alert for an issue not caught by monitoring.

Sample prompt: Create a high-priority alert titled "API latency spike in EU region" and route it through the SRE escalation policy

8. Coordinating a Major Incident

Use find-services, create-incident, and update-incident to track and communicate service disruptions.

Sample prompt: Create a high-priority incident for a major outage on the Checkout service and set its status to INVESTIGATING

9. Updating Incident Status

Use list-incidents and update-incident to keep stakeholders informed as an incident evolves.

Sample prompt: Find the open incident affecting the Payments service and update it to MONITORING with a note that a fix has been deployed

10. Running Automated Remediation Actions

Combine list-alert-action (or list-alert-actions) with invoke-alert-action to trigger automated workflows.

Sample prompt: Show me the available actions for alert 5567 and run the "restart-service" webhook

11. Finding Team Members by Role

Use find-users filtered by role to locate the right people for a task.

Sample prompt: Find all users with the RESPONDER role who have "database" in their name or email

12. Auditing Recent Alerts by Date Range

Use list-alerts with from and until parameters for reporting and review.

Sample prompt: List all resolved alerts from January 1st to January 31st, 2025 for our post-incident review

Details

MCP Server URL:

https://mcp.ilert.com/mcp

Type:

HTTP Stream

Authentication:

API Key (Bearer Token)

How to connect this MCP server

Tools

get-my-profile

Get the current authenticated user's profile information. This tool provides current user context that is useful for other tools. This tool should be called for user context before working with alerts of the current user. Returns user ID, name, email, role, timezone, language, and other profile details needed for subsequent alert operations. Use this to determine user permissions, timezone for date filtering, and to establish the user's alert ownership context. The returned user ID can be used with list-alerts (assignedTo parameter) to get 'my alerts'.

find-users

Search and retrieve users with optional filtering. This tool provides user IDs that are required by other tools. Use this to find users by name or email, check user roles and permissions, and get user IDs for adding responders or assigning alerts. The returned user IDs can be used with: add-responder-to-alert (userId parameter), create-alert (responders array), and list-alerts (assignedTo parameter).

list-alerts

Retrieve alerts with flexible filtering options. This tool provides alert IDs that are required by other alert management tools. Key usage patterns: (1) Personal alerts - include the user's ID in 'assignedTo' parameter (2) All/team alerts - leave 'assignedTo' empty or specify multiple user IDs. The 'states' parameter filters by status - only use when specifically requested, otherwise defaults to active alerts (PENDING + ACCEPTED). Supports pagination and can include escalation details. The returned alert IDs can be used with: show-alert-details, accept-alert, resolve-alert, comment-alert, escalate-alert, reroute-alert, add-responder-to-alert, list-alert-action, and invoke-alert-action tools.

show-alert-details

Retrieve comprehensive details about a specific alert including all metadata, status information, and context needed for incident response. This tool requires an alert ID from list-alerts tool. Returns: alert summary and description, current status (PENDING/ACCEPTED/RESOLVED), all current responders and their status, escalation policy and rules, alert source and integration details, priority level, creation and update timestamps, next escalation information, assigned user details, and any custom fields. Use this tool before taking any actions on an alert to understand the full context, current ownership, and available escalation paths.

accept-alert

Accept responsibility for an open alert and begin working on it. This tool requires an alert ID from list-alerts tool. This action changes the alert status from PENDING to ACCEPTED, marking you as the active responder. Prerequisites: (1) Alert must be in PENDING status, (2) Alert must be assigned to the current user through escalation policy or manual assignment. Once accepted, you can add investigation comments, escalate to higher levels if needed, add additional responders for collaboration, or resolve the alert when the incident is fixed. This creates an audit trail showing when responsibility was taken.

resolve-alert

Mark an alert as resolved. This tool requires an alert ID from list-alerts tool. This action changes the alert status to RESOLVED and closes the incident. Only works on ACCEPTED or PENDING alerts that are assigned to the current user. Use this when the incident has been fully addressed and resolved. Ask the user to add a comment before resolving to document the resolution details.

comment-alert

Add a comment to an alert. This tool requires an alert ID from list-alerts tool, and content (the comment text). Comments are visible to all users assigned to the alert and help track progress or provide updates on the incident. Use this to document investigation steps, status updates, resolution details, or any relevant information about the alert. Comments are timestamped and help maintain a complete audit trail of the incident.

escalate-alert

Escalate an alert to the next level or specified escalation policy. This tool requires an alert ID from list-alerts tool. Use this when the current responder cannot handle the alert and it needs to be escalated to another person or team.

reroute-alert

Reroute an alert to a different escalation policy or team. This tool requires an alert ID from list-alerts tool and an escalation policy ID from find-escalation-policies tool. Use this to redirect an alert to the appropriate team when it was initially assigned incorrectly or needs different expertise.

add-responder-to-alert

Add additional team members as responders to an existing alert for collaboration and expertise. This tool requires an alert ID from list-alerts tool and optionally a user ID from find-users tool or schedule ID from find-schedules tool. Use this when: (1) The current responder needs specialized knowledge from another team member, (2) The incident requires multiple people working together, (3) You want to involve subject matter experts, (4) The alert needs escalation to a specific person without changing the escalation policy. The added responder will receive notifications, can accept the alert, add comments, and help resolve the incident. Multiple responders can work on the same alert simultaneously, creating a collaborative incident response.

create-alert

Create a new alert manually. This tool can use various IDs from other tools: alert source IDs from find-alert-sources, escalation policy IDs from find-escalation-policies, and user IDs from find-users. Use this to create alerts for incidents that need immediate attention but weren't automatically detected by monitoring systems.

list-alert-action

List available actions for a specific alert. This tool requires an alert ID from list-alerts tool. Use this to see what actions can be performed on an alert before executing them. The returned webhook IDs can be used with invoke-alert-action tool.

list-alert-actions

List all available alert actions across the system. This tool provides webhook IDs that are required by other tools. Use this to discover what automated actions, integrations, and workflows are available that can be triggered on alerts. This shows global alert actions that can be invoked, along with their webhook IDs needed for the invoke-alert-action tool. Use this before invoking alert actions to find the correct webhook ID. The returned webhook IDs can be used with: invoke-alert-action (webhookId parameter).

invoke-alert-action

Invoke a specific action on an alert. This tool requires an alert ID from list-alerts tool and a webhook ID from list-alert-action or list-alert-actions tools. Use this to perform automated remediation steps, trigger integrations, or invoke custom workflows associated with an alert. Workflow: 1) Use list-alert-action to find available actions for a specific alert, 2) Use the webhookId from that response in this tool. Example: { alertId: 123, webhookId: 456 }

find-alert-sources

Search and retrieve alert sources with optional filtering. This tool provides alert source IDs that are required by other tools. Use this to find available alert sources by name, view their IDs and integration details, and understand what sources can be used when creating alerts. Alert sources represent integrations like monitoring tools, applications, or manual sources that can generate alerts. The returned data includes source IDs needed for alert creation. The returned alert source IDs can be used with: create-alert (alertSource.id field).

find-escalation-policies

Search and retrieve escalation policies with optional filtering. This tool provides escalation policy IDs that are required by other tools. Use this to find escalation policies by name, view policy details, get policy IDs for creating alerts or rerouting, and understand escalation routing rules with level information. The returned escalation policy IDs can be used with: reroute-alert (escalationPolicyId parameter) and create-alert (escalationPolicy.id field).

find-services

Search and retrieve services with optional filtering. This tool provides service IDs that are required by other tools. Use this to find services by name, check service status, view service details, and get service IDs for creating incidents or alerts. The returned data prominently shows service IDs needed for other operations. The returned service IDs can be used with: create-incident (affectedServices.service.id field) and create-alert (optional alertSource.id field).

create-incident

Create a new incident to track major service disruptions or issues. This tool requires service IDs from find-services tool. Use this for coordinating incident response, communication, and resolution tracking for significant problems affecting multiple services or users.

update-incident

Update an existing incident. This tool requires incident ID from list-incidents tool. Use this to update the incident summary, status, message, and affected services.

list-incidents

Retrieve incidents with flexible filtering options. This tool provides incident IDs that are required by other incident management tools. The 'states' parameter filters by status - only use when specifically requested, otherwise defaults to all states (INVESTIGATING, IDENTIFIED, MONITORING, RESOLVED). Supports pagination and filtering by service IDs and date ranges. The returned incident IDs can be used with: update-incident tool.

find-schedules

Find on-call schedules to see who is currently on duty. This tool provides schedule IDs that can be used by other tools. Returns schedule details including current and upcoming on-call rotations. The returned schedule IDs can be used with: add-responder-to-alert (scheduleId parameter) to add schedules as responders to alerts.

ilert MCP Server