Skip to main content
Glama

get_alarm

Retrieve detailed alarm information including query, thresholds, and notification settings from Oracle Cloud Infrastructure using the alarm's OCID.

Instructions

Get detailed information about a specific alarm.

Args:
    alarm_id: OCID of the alarm to retrieve

Returns:
    Detailed alarm information including query, thresholds, and notification settings

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
alarm_idYes

Implementation Reference

  • Registration of the 'get_alarm' tool using @mcp.tool decorator with wrapper for error handling.
    @mcp.tool(name="get_alarm")
    @mcp_tool_wrapper(
        start_msg="Getting alarm details for {alarm_id}...",
        success_msg="Retrieved alarm details successfully",
        error_prefix="Error getting alarm details"
    )
  • The main handler function for the 'get_alarm' tool, which receives the alarm_id parameter and delegates to the helper function with the OCI monitoring client.
    async def mcp_get_alarm(ctx: Context, alarm_id: str) -> Dict[str, Any]:
        """
        Get detailed information about a specific alarm.
    
        Args:
            alarm_id: OCID of the alarm to retrieve
    
        Returns:
            Detailed alarm information including query, thresholds, and notification settings
        """
        return get_alarm(oci_clients["monitoring"], alarm_id)
  • Core helper function that performs the actual OCI API call to retrieve alarm details and formats the response dictionary.
    def get_alarm(monitoring_client: oci.monitoring.MonitoringClient, alarm_id: str) -> Dict[str, Any]:
        """
        Get details of a specific alarm.
    
        Args:
            monitoring_client: OCI Monitoring client
            alarm_id: OCID of the alarm
    
        Returns:
            Details of the alarm
        """
        try:
            alarm = monitoring_client.get_alarm(alarm_id).data
    
            alarm_details = {
                "id": alarm.id,
                "display_name": alarm.display_name,
                "compartment_id": alarm.compartment_id,
                "metric_compartment_id": alarm.metric_compartment_id,
                "metric_compartment_id_in_subtree": alarm.metric_compartment_id_in_subtree,
                "namespace": alarm.namespace,
                "resource_group": alarm.resource_group,
                "query": alarm.query,
                "resolution": alarm.resolution,
                "pending_duration": alarm.pending_duration,
                "severity": alarm.severity,
                "body": alarm.body,
                "is_enabled": alarm.is_enabled,
                "lifecycle_state": alarm.lifecycle_state,
                "suppress": {
                    "time_suppress_from": str(alarm.suppression.time_suppress_from) if alarm.suppression else None,
                    "time_suppress_until": str(alarm.suppression.time_suppress_until) if alarm.suppression else None,
                    "description": alarm.suppression.description if alarm.suppression else None,
                } if alarm.suppression else None,
                "destinations": alarm.destinations,
                "repeat_notification_duration": alarm.repeat_notification_duration,
                "time_created": str(alarm.time_created),
                "time_updated": str(alarm.time_updated),
            }
    
            logger.info(f"Retrieved details for alarm {alarm_id}")
            return alarm_details
    
        except Exception as e:
            logger.exception(f"Error getting alarm details: {e}")
            raise
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation ('get'), implying it's likely read-only, but doesn't confirm this or mention any side effects, authentication requirements, rate limits, or error handling. The description is minimal and lacks behavioral context beyond the basic operation.

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 well-structured and extremely concise: a clear purpose statement followed by dedicated 'Args' and 'Returns' sections. Every sentence earns its place with no wasted words. The information is front-loaded and efficiently organized.

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?

Given the tool's simplicity (single parameter, no output schema, no annotations), the description covers the basics: purpose, parameter meaning, and return content overview. However, for a retrieval tool without annotations, it should ideally mention that this is a read-only operation and possibly clarify the relationship with 'list_alarms'. The description is minimally adequate but could be more complete.

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

Parameters4/5

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

The description explicitly documents the single parameter 'alarm_id' with its semantic meaning ('OCID of the alarm to retrieve'), which is valuable since schema description coverage is 0%. This adds essential context beyond the bare schema, though it doesn't elaborate on OCID format or validation rules. For a single parameter tool, this provides adequate semantic clarification.

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 clearly states the tool's purpose: 'Get detailed information about a specific alarm.' It specifies the verb ('get') and resource ('alarm'), but doesn't explicitly differentiate from its sibling 'list_alarms' beyond the singular vs. plural naming. The description is accurate but lacks explicit sibling distinction.

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?

The description provides no guidance on when to use this tool versus alternatives like 'list_alarms' or other retrieval tools. It mentions retrieving 'a specific alarm' but doesn't clarify prerequisites, error conditions, or when to choose this over other methods. No explicit usage context is provided.

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/jopsis/mcp-server-oci'

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