Skip to main content
Glama
driosalido
by driosalido

get_alert_details

Retrieve comprehensive details of a specific Kubernetes alert, including its status, severity, and timeline, to support monitoring and incident analysis.

Instructions

Get detailed information about a specific alert

Args: alert_name: Name of the alert to get details for

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
alert_nameYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The main handler function for the get_alert_details MCP tool. Fetches alert data from Karma API, searches for alerts matching the given alert_name, and returns formatted details including state, severity, namespace, cluster, instance, and annotations.
    @mcp.tool()
    async def get_alert_details(alert_name: str) -> str:
        """Get detailed information about a specific alert
    
        Args:
            alert_name: Name of the alert to get details for
        """
        data, error = await fetch_karma_alerts()
        if error:
            return error
    
        # Find matching alerts
        matching_alerts = []
        grids = data.get("grids", [])
    
        for grid in grids:
            for group in grid.get("alertGroups", []):
                alertname = extract_label_value(group.get("labels", []), "alertname")
    
                if alertname.lower() == alert_name.lower():
                    for alert in group.get("alerts", []):
                        matching_alerts.append({"alert": alert, "group": group})
    
        if not matching_alerts:
            return f"No alert found with name: {alert_name}"
    
        # Format alert details
        details = f"🔍 Found {len(matching_alerts)} instance(s) of {alert_name}:\n\n"
    
        for i, item in enumerate(matching_alerts, 1):
            alert = item["alert"]
            group = item["group"]
    
            metadata = extract_alert_metadata(group, alert)
            annotations = extract_annotations(alert)
    
            details += f"📋 Instance {i}:\n"
            details += f"  State: {metadata['state']}\n"
            details += f"  Severity: {metadata['severity']}\n"
            details += f"  Namespace: {metadata['namespace']}\n"
            details += f"  Cluster: {metadata['cluster']}\n"
    
            # Add instance if available
            instance = extract_label_value(alert.get("labels", []), "instance")
            if instance != "unknown":
                details += f"  Instance: {instance}\n"
    
            # Add annotations
            if "description" in annotations:
                description = annotations["description"]
                if len(description) > 200:
                    description = description[:200] + "..."
                details += f"  Description: {description}\n"
    
            if "summary" in annotations:
                details += f"  Summary: {annotations['summary']}\n"
    
            details += "\n"
    
        return details
  • Registers get_alert_details as an MCP tool via the @mcp.tool() decorator on the FastMCP server instance in server.py
    @mcp.tool()
    async def get_alert_details(alert_name: str) -> str:
        """Get detailed information about a specific alert
    
        Args:
            alert_name: Name of the alert to get details for
        """
  • JSON-RPC schema definition for get_alert_details tool in the http_server.py tools/list endpoint. Defines input schema requiring alert_name string parameter.
        "name": "get_alert_details",
        "description": "Get specific alert details",
        "inputSchema": {
            "type": "object",
            "properties": {
                "alert_name": {
                    "type": "string",
                    "description": "Name of the alert to get details for",
                }
            },
            "required": ["alert_name"],
        },
    },
  • Imports get_alert_details from server.py into http_server.py, enabling its use across HTTP, SSE, and MCP JSON-RPC endpoints.
    from .server import (
        check_karma,
        create_silence,
        delete_silence,
        get_alert_details,
        get_alert_details_multi_cluster,
  • Helper function used by get_alert_details to fetch alert data from the Karma API. Returns a tuple of (data, error).
        return httpx.AsyncClient()
    
    
    async def fetch_karma_alerts():
Behavior2/5

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

No annotations exist. The description only states 'get detailed information', implying a read operation, but does not disclose side effects, permissions, rate limits, or failure modes. The output schema exists but behavior beyond that is opaque.

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

Conciseness3/5

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

The description is very short (two sentences) but under-specified. It is concise but lacks sufficient detail. The structure is clear but the brevity hurts completeness.

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

Completeness3/5

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

For a tool with one parameter and an output schema, the description covers the basic purpose. However, it does not explain what 'detailed information' includes or any constraints (e.g., alert must exist). Completeness is adequate but not thorough.

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

Parameters2/5

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

Schema description coverage is 0%. The description merely restates the parameter name ('alert_name: Name of the alert to get details for') without adding type, constraints, or examples. Does not compensate for the schema's lack of description.

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 uses a specific verb 'get detailed information' and a clear resource 'specific alert'. It distinguishes from siblings like 'get_alert_details_multi_cluster' and list tools. However, it doesn't explicitly differentiate itself when both single and multi-cluster versions exist.

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?

No guidance on when to use this tool versus siblings. No mention of prerequisites or context. The description is purely functional.

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/driosalido/mcp-karma'

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