Integrates with Prometheus Alertmanager to retrieve and filter alerts, manage silences (create, list, delete), get alert details by fingerprint, and retrieve alert groups as organized by Alertmanager.
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., "@Prometheus Alertmanager MCP Server show me current alerts that are active but not silenced"
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: Opsgenie 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
To install Prometheus Alertmanager Integration Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @comqx/alertmanager-mcp --client claudeAccess 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. Dates show when Glama detected each change.
v1.0.0create-silence2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsedelete-silence2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseget-alert-details2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseget-alert-groups2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseget-alerts2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseget-silences2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsecreate-silencedelete-silenceget-alert-detailsget-alert-groupsget-alertsget-silencesEach tool has a clearly distinct purpose targeting specific resources: create/delete silences, get alerts with varying granularity (details, groups, list), and get silences. There is no overlap in functionality, making tool selection straightforward for an agent.
All tools follow a consistent verb-noun pattern with hyphens (e.g., create-silence, get-alerts). The naming is uniform across all six tools, using clear verbs like 'create', 'delete', and 'get' paired with specific nouns.
Six tools are well-scoped for managing Prometheus Alertmanager alerts and silences, covering core operations. It is slightly lean but reasonable, as it includes essential CRUD-like actions for silences and multiple alert retrieval methods.
The toolset covers key areas: silences (create, delete, list) and alerts (list, groups, details). However, there are notable gaps such as no tools for creating, updating, or deleting alerts, which limits full lifecycle management in the alert domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Monitor websites, APIs, and servers: create monitors, triage incidents, and query uptime stats.
Manage incidents and on-call: list/create/update incidents, who is on call, on-call overrides.
Read Spike.sh incidents, on-call, escalations and services; acknowledge, resolve, set priority.
Read incidents, services, teams, on-call schedules; acknowledge, resolve and note incidents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/comqx/alertmanager-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
