Allows interaction with Prometheus Alertmanager API, providing tools to retrieve alerts, get alert details, manage silences, and get alert groups.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@alertmanager-mcp show me current alerts"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This project implements a Model Context Protocol (MCP) server that integrates with Prometheus Alertmanager. It serves as a bridge between Claude AI and Alertmanager, allowing Claude to interact with and manage alerts through a standardized interface.
Alert Retrieval: Fetches and formats current alerts from Alertmanager with optional filtering capabilities.
Alert Details: Provides detailed information about specific alerts when referenced by their fingerprint.
Silence Management: Offers tools to create, list, and delete silences that suppress notifications for specific alerts.
Alert Grouping: Retrieves alert groups as organized by Alertmanager.
Related MCP server: Prometheus Alertmanager MCP Server
Built using TypeScript and the MCP SDK
Communicates with Alertmanager's HTTP API (v2)
Runs as a stdio-based process compatible with Claude for Desktop
Implements proper error handling and timeout management
Provides strongly-typed interfaces for alert and silence data
Access to a running Prometheus Alertmanager instance
For Claude for Desktop: Node.js (v18 or newer) installed on your system
The package is available on npm and can be used directly with npx:
npx alertmanager-mcpFor global installation:
npm install -g alertmanager-mcp
alertmanager-mcpConfigure Claude for Desktop to use the MCP server by editing the configuration file:
{
"mcpServers": {
"alertmanager": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"--network=host",
"-e", "ALERTMANAGER_URL=http://your-alertmanager-url:9093",
"ghcr.io/kaznak/alertmanager-mcp:latest"
],
"env": {}
}
}
}Restart Claude for Desktop to load the new configuration.
You can now ask Claude to interact with Alertmanager using natural language:
"Show me current alerts"
"Filter alerts related to CPU issues"
"Get details for this alert"
"Create a silence for this alert for the next 2 hours"
Retrieves a list of alerts with optional filtering.
Parameters:
filter: (optional) Filtering query (e.g., alertname=~'.*CPU.*')
silenced: (optional) Include silenced alerts
inhibited: (optional) Include inhibited alerts
active: (optional) Include active alerts (default: true)
Gets detailed information about a specific alert.
Parameters:
fingerprint: Alert fingerprint
Creates a silence for alerts matching specified criteria.
Parameters:
matchers: List of matchers for alerts
startsAt: (optional) Silence start time (ISO8601 format, default is current time)
endsAt: Silence end time (ISO8601 format)
createdBy: Username who created the silence
comment: Reason or explanation for the silence
Retrieves a list of silences with optional filtering.
Parameters:
filter: (optional) Filtering query (e.g., createdBy=~'.*admin.*')
Deletes a silence by ID.
Parameters:
silenceId: ID of the silence to delete
Gets alert groups with optional filtering.
Parameters:
active: (optional) Include active alerts (default: true)
silenced: (optional) Include silenced alerts
inhibited: (optional) Include inhibited alerts
This MCP server can be extended with additional features such as:
Alert trend analysis
Automatic response suggestions
Integration with incident management systems
Custom dashboards for specific alert types
| Name | Required | Description | Default |
|---|---|---|---|
| matchers | Yes | List of matchers for alerts | |
| startsAt | No | Silence start time (ISO8601 format, default is current time) | |
| endsAt | Yes | Silence end time (ISO8601 format) | |
| createdBy | Yes | Username who created the silence | |
| comment | Yes | Reason or explanation for the silence |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| silenceId | Yes | ID of the silence to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| fingerprint | Yes | Alert fingerprint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Include active alerts (default: true) | |
| silenced | No | Include silenced alerts | |
| inhibited | No | Include inhibited alerts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Filtering query (e.g. alertname=~'.*CPU.*') | |
| silenced | No | Include silenced alerts | |
| inhibited | No | Include inhibited alerts | |
| active | No | Include active alerts (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Filtering query (e.g. createdBy=~'.*admin.*') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.1create-silencedelete-silenceget-alert-detailsget-alert-groupsget-alertsget-silencesScored across 6 tools
Tool names are generally distinct: create/delete/get silences, get alerts, get alert details, get alert groups. However, without descriptions, 'get-alert-details' and 'get-alerts' could cause slight confusion as to whether details are a subset.
All tools follow a consistent verb_noun pattern with kebab-case: create/delete/get + resource. No mixing of styles.
6 tools is well-scoped for an Alertmanager MCP server, covering the essential operations without being excessive.
The set covers creating/deleting silences and retrieving alerts and silences. Missing update silence or alert acknowledgment, but these are not standard Alertmanager operations, so minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
Deploy, monitor, and manage your OpenClaw AI assistants via natural language.
Connects AI assistants to CloudQuell multi-cloud and AI cost, savings, anomaly, and budget data.
