Skip to main content
Glama
honeycombio
by honeycombio

get_trigger

Retrieve detailed information about a specific Honeycomb alert by ID, including threshold settings, alert type, status, and configuration details.

Instructions

Retrieves a specific trigger (alert) by ID with detailed information. This tool returns a detailed object containing the trigger's ID, name, description, threshold, frequency, alert type, triggered status, disabled status, recipients, evaluation schedule type, and timestamps.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
environmentYesThe Honeycomb environment
datasetYesThe dataset containing the trigger
triggerIdYesThe ID of the trigger to retrieve

Implementation Reference

  • Handler function for the get_trigger tool. Validates required parameters (environment, dataset, triggerId), fetches the trigger data via api.getTrigger, simplifies the response structure (including recipients), formats it as JSON text content with metadata (status), and handles errors.
    handler: async ({ environment, dataset, triggerId }: { environment: string; dataset: string; triggerId: string }) => {
      // Validate input parameters
      if (!environment) {
        return handleToolError(new Error("environment parameter is required"), "get_trigger");
      }
      if (!dataset) {
        return handleToolError(new Error("dataset parameter is required"), "get_trigger");
      }
      if (!triggerId) {
        return handleToolError(new Error("triggerId parameter is required"), "get_trigger");
      }
    
      try {
        // Fetch trigger details from the API
        const trigger = await api.getTrigger(environment, dataset, triggerId);
        
        // Simplify the response to reduce context window usage
        const simplifiedTrigger: SimplifiedTriggerDetails = {
          id: trigger.id,
          name: trigger.name,
          description: trigger.description || '',
          threshold: {
            op: trigger.threshold.op,
            value: trigger.threshold.value,
          },
          frequency: trigger.frequency,
          alert_type: trigger.alert_type,
          triggered: trigger.triggered,
          disabled: trigger.disabled,
          recipients: trigger.recipients.map(r => ({
            type: r.type,
            target: r.target,
          })),
          evaluation_schedule_type: trigger.evaluation_schedule_type,
          created_at: trigger.created_at,
          updated_at: trigger.updated_at,
        };
        
        return {
          content: [
            {
              type: "text",
              text: JSON.stringify(simplifiedTrigger, null, 2),
            },
          ],
          metadata: {
            triggerId,
            dataset,
            environment,
            status: trigger.triggered ? "TRIGGERED" : trigger.disabled ? "DISABLED" : "ACTIVE"
          }
        };
      } catch (error) {
        return handleToolError(error, "get_trigger");
      }
    }
  • Zod schema defining the input parameters for the get_trigger tool: environment (string), dataset (string), triggerId (string).
    schema: {
      environment: z.string().describe("The Honeycomb environment"),
      dataset: z.string().describe("The dataset containing the trigger"),
      triggerId: z.string().describe("The ID of the trigger to retrieve"),
    },
  • Registration of the get_trigger tool: imports createGetTriggerTool and adds the tool instance to the array of tools registered with the MCP server.
    // Trigger tools
    createListTriggersTool(api),
    createGetTriggerTool(api),
  • Helper interface defining the simplified trigger data structure used in the tool's response to reduce context window usage.
    interface SimplifiedTriggerDetails {
      id: string;
      name: string;
      description: string;
      threshold: {
        op: string;
        value: number;
      };
      frequency: number;
      alert_type?: string;
      triggered: boolean;
      disabled: boolean;
      recipients: SimplifiedRecipient[];
      evaluation_schedule_type?: string;
      created_at: string;
      updated_at: string;
    }
  • Helper interface for simplified recipient objects in triggers.
    interface SimplifiedRecipient {
      type: string;
      target?: string;
    }
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves detailed information and lists the fields returned, but does not mention behavioral aspects like error handling, authentication needs, rate limits, or whether it's a read-only operation. The description adds some context but lacks comprehensive behavioral traits.

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

Conciseness4/5

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

The description is appropriately sized with two sentences: the first states the purpose, and the second details the returned information. It is front-loaded with the core function, but the second sentence could be more concise by summarizing rather than listing all fields.

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 no annotations and no output schema, the description partially compensates by listing return fields, but it does not fully address complexity like error cases or operational constraints. It is adequate for a read operation but lacks depth for complete agent understanding.

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

Parameters3/5

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

The schema description coverage is 100%, so the schema already documents all three parameters. The description does not add any meaning beyond what the schema provides, such as explaining parameter relationships or usage nuances. Baseline 3 is appropriate as the schema handles parameter documentation.

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

Purpose5/5

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

The description clearly states the verb ('Retrieves') and resource ('a specific trigger (alert) by ID'), specifying it returns detailed information. It distinguishes from sibling tools like 'list_triggers' by focusing on a single trigger retrieval rather than listing multiple.

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

Usage Guidelines3/5

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

The description implies usage when detailed information for a specific trigger is needed, but does not explicitly state when to use this tool versus alternatives like 'list_triggers' or other sibling tools. No exclusions or prerequisites are mentioned.

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/honeycombio/honeycomb-mcp'

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