Skip to main content
Glama
ntk148v

alertmanager-mcp-server

get_alerts

Retrieve a list of alerts with optional filters for active, silenced, or inhibited status, paginated by count and offset.

Instructions

Get a list of alerts

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filterNo
silencedNo
inhibitedNo
activeNo
countNo
offsetNo

Implementation Reference

  • The get_alerts tool handler function. Decorated with @mcp.tool, it accepts filter, silenced, inhibited, active, count, and offset parameters. Validates pagination, builds query params, calls make_request to GET /api/v2/alerts, then paginates results via paginate_results.
    async def get_alerts(filter: Optional[str] = None,
                         silenced: Optional[bool] = None,
                         inhibited: Optional[bool] = None,
                         active: Optional[bool] = None,
                         count: int = DEFAULT_ALERT_PAGE,
                         offset: int = 0):
        """Get a list of alerts currently in Alertmanager.
    
        Params
        ------
        filter
            Filtering query (e.g. alertname=~'.*CPU.*')"),
        silenced
            If true, include silenced alerts.
        inhibited
            If true, include inhibited alerts.
        active
            If true, include active alerts.
        count
            Number of alerts to return per page (default: 10, max: 25).
        offset
            Number of alerts to skip before returning results (default: 0).
            To paginate through all results, make multiple calls with increasing
            offset values (e.g., offset=0, offset=10, offset=20, etc.).
    
        Returns
        -------
        dict
            A dictionary containing:
            - data: List of Alert objects for the current page
            - pagination: Metadata about pagination (total, offset, count, has_more)
              Use the 'has_more' flag to determine if additional pages are available.
        """
        # Validate pagination parameters
        count, offset, error = validate_pagination_params(
            count, offset, MAX_ALERT_PAGE)
        if error:
            return {"error": error}
    
        params = {"active": True}
        if filter:
            params = {"filter": filter}
        if silenced is not None:
            params["silenced"] = silenced
        if inhibited is not None:
            params["inhibited"] = inhibited
        if active is not None:
            params["active"] = active
    
        # Get all alerts from the API
        all_alerts = make_request(
            method="GET", route="/api/v2/alerts", params=params)
    
        # Apply pagination and return results
        return paginate_results(all_alerts, count, offset)
  • Pagination defaults: DEFAULT_ALERT_PAGE (10) and MAX_ALERT_PAGE (25) used as default and cap for count parameter in get_alerts.
    # Pagination defaults and limits (configurable via environment variables)
    DEFAULT_SILENCE_PAGE = int(os.environ.get(
        "ALERTMANAGER_DEFAULT_SILENCE_PAGE", "10"))
    MAX_SILENCE_PAGE = int(os.environ.get("ALERTMANAGER_MAX_SILENCE_PAGE", "50"))
    DEFAULT_ALERT_PAGE = int(os.environ.get(
        "ALERTMANAGER_DEFAULT_ALERT_PAGE", "10"))
    MAX_ALERT_PAGE = int(os.environ.get("ALERTMANAGER_MAX_ALERT_PAGE", "25"))
    DEFAULT_ALERT_GROUP_PAGE = int(os.environ.get(
        "ALERTMANAGER_DEFAULT_ALERT_GROUP_PAGE", "3"))
    MAX_ALERT_GROUP_PAGE = int(os.environ.get(
        "ALERTMANAGER_MAX_ALERT_GROUP_PAGE", "5"))
  • Registration decorator: @mcp.tool(description="Get a list of alerts") on the get_alerts function registers it as an MCP tool via the FastMCP instance.
    @mcp.tool(description="Get a list of alerts")
  • make_request helper – makes the actual HTTP GET request to /api/v2/alerts with auth, tenant headers, and returns parsed JSON.
        )
        response.raise_for_status()
        result = response.json()
    
        # Ensure we always return something (empty list is valid but might cause issues)
        if result is None:
            return {"message": "No data returned"}
        return result
    except requests.exceptions.RequestException as e:
        return {"error": str(e)}
  • paginate_results helper – slices the full alert list by offset/count and returns paginated data with metadata (total, offset, count, has_more).
    def paginate_results(items: List[Any], count: int, offset: int) -> Dict[str, Any]:
        """Apply pagination to a list of items and generate pagination metadata.
    
        Parameters
        ----------
        items : List[Any]
            The full list of items to paginate
        count : int
            Number of items to return per page (must be >= 1)
        offset : int
            Number of items to skip (must be >= 0)
    
        Returns
        -------
        Dict[str, Any]
            A dictionary containing:
            - data: List of items for the current page
            - pagination: Metadata including total, offset, count, requested_count, and has_more
        """
        total = len(items)
        end_index = offset + count
        paginated_items = items[offset:end_index]
        has_more = end_index < total
    
        return {
            "data": paginated_items,
            "pagination": {
                "total": total,
                "offset": offset,
                "count": len(paginated_items),
                "requested_count": count,
                "has_more": has_more
            }
        }
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavior beyond fetching a list. Crucial details like side effects, required permissions, or return format are omitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is concise but under-specified. It fails to convey important details; conciseness here sacrifices usefulness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 parameters, no output schema, no annotations, and no sibling differentiation, the description is severely incomplete. It should explain filtering, pagination, and result structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 6 parameters with 0% description coverage. The description adds no meaning to any parameter, leaving filter, silenced, inhibited, active, count, and offset completely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get a list of alerts' clearly states the verb and resource, matching the tool name. However, it does not differentiate from sibling tools like get_alert_groups or get_silences, missing a chance to specify scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives such as get_alert_groups (for grouped alerts) or get_silences (for silenced alerts). The description lacks prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ntk148v/alertmanager-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server