Skip to main content
Glama
ntk148v

alertmanager-mcp-server

post_alerts

Create new alerts in Alertmanager to notify teams about system issues or events requiring attention.

Instructions

Create new alerts

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
alertsYes

Implementation Reference

  • The async handler function for the 'post_alerts' tool. It is registered via the @mcp.tool decorator and forwards the alerts list as JSON to the Alertmanager /api/v2/alerts POST endpoint using the make_request helper. Input schema is defined by the List[Dict] type hint and docstring.
    @mcp.tool(description="Create new alerts")
    async def post_alerts(alerts: List[Dict]):
        """Create new alerts
    
        Parameters
        ----------
        alerts
            A list of Alert object.
            [
                {
                    "startsAt": datetime,
                    "endsAt": datetime,
                    "annotations": labelSet
                }
            ]
    
        Returns
        -------
        dict:
            Create alert response from Alertmanager API.
        """
        return make_request(method="POST", route="/api/v2/alerts", json=alerts)
  • Core helper function that performs HTTP requests to the Alertmanager API. Handles authentication, tenant headers, URL joining, error handling, and JSON parsing. Directly called by post_alerts to POST the alerts.
    def make_request(method="GET", route="/", **kwargs):
        """Make HTTP request and return a requests.Response object.
    
        Parameters
        ----------
        method : str
            HTTP method to use for the request.
        route : str
            (Default value = "/")
            This is the url we are making our request to.
        **kwargs : dict
            Arbitrary keyword arguments.
    
    
        Returns
        -------
        dict:
            The response from the Alertmanager API. This is a dictionary
            containing the response data.
        """
        try:
            route = url_join(config.url, route)
            auth = (
                requests.auth.HTTPBasicAuth(config.username, config.password)
                if config.username and config.password
                else None
            )
    
            # Add X-Scope-OrgId header for multi-tenant setups
            # Priority: 1) Request header from caller (via ContextVar), 2) Static config tenant
            headers = kwargs.get("headers", {})
    
            tenant_id = _current_scope_org_id.get() or config.tenant_id
    
            if tenant_id:
                headers["X-Scope-OrgId"] = tenant_id
            if headers:
                kwargs["headers"] = headers
    
            response = requests.request(
                method=method.upper(), url=route, auth=auth, timeout=60, **kwargs
            )
            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)}
  • The @mcp.tool decorator registers the post_alerts function as an MCP tool with the name 'post_alerts' (inferred from function name) on the FastMCP instance.
    @mcp.tool(description="Create new alerts")
Behavior1/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. 'Create new alerts' implies a write/mutation operation but doesn't specify permissions needed, side effects, rate limits, or response format. It lacks critical details like whether this is idempotent, what happens on failure, or how alerts are delivered/processed.

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

Conciseness5/5

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

The description is extremely concise at just two words, with no wasted language. It's front-loaded with the core action. While this conciseness comes at the expense of completeness, the description itself is structurally efficient with every word serving its purpose.

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?

Given a mutation tool with 1 parameter, 0% schema coverage, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what alerts are, their purpose, required fields, expected response, or error conditions. For a tool that presumably creates important notifications, this leaves critical gaps for an agent to use it correctly.

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?

Schema description coverage is 0%, with 1 parameter ('alerts') that has no documentation in the schema. The description doesn't mention parameters at all, failing to compensate for the complete lack of schema documentation. It provides no information about what the 'alerts' array should contain, its structure, or example values.

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

Purpose2/5

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

The description 'Create new alerts' states the basic action but is tautological with the tool name 'post_alerts' (which implies creation). It doesn't specify what kind of alerts, for what system, or what resources are involved. While it uses a verb+resource structure, it lacks specificity and doesn't distinguish from siblings like 'post_silence' which also creates something.

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

Usage Guidelines1/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions. With siblings like 'get_alerts' for reading alerts and 'post_silence' for creating silences, there's no indication of when to choose creation over retrieval or how this relates to other alert management tools.

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