An assistant asking "what is firing" during an incident is asking the one question most likely to return hundreds of items. The defaults here are deliberately small and the ceilings are per-endpoint — alert groups cap at 5 because each group carries its own alerts with it. The has_more flag means the model can walk the list rather than guess whether it saw everything.
A server over the Alertmanager v2 API. It reads status, alerts, silences and receivers, and it creates alerts and silences — with paging on every list call, because an alerting system is exactly the place where a full dump goes badly.
- get_status returns Alertmanager's own state
- get_alerts lists alerts filtered by silenced, inhibited and active, paginated with count and offset — 10 per page by default, 25 at most — and returns a has_more flag
- get_silences pages the same way, defaulting to 10 and capping at 50
- post_silence creates a silence and delete_silence removes one by id
- get_receivers lists configured receivers
- get_alert_groups pages with a lower ceiling — 3 per page by default, 5 at most — because each group carries all its alerts
- Basic authentication through ALERTMANAGER_USERNAME and ALERTMANAGER_PASSWORD, and multi-tenant Mimir or Cortex setups through the X-Scope-OrgId header, which overrides the static tenant setting per request
Python 3.12 or newer with uv, or the container image ghcr.io/ntk148v/alertmanager-mcp-server. ALERTMANAGER_URL is required; username, password and ALERTMANAGER_TENANT are optional. Transport defaults to stdio, with MCP_TRANSPORT switching to http or sse and MCP_HOST and MCP_PORT controlling the binding — port 8000 by default.
One command — npx -y @smithery/cli install @ntk148v/alertmanager-mcp-server --client claude