Skip to main content
Glama

create_alert

Create alert rules to monitor cost, error rate, latency, or anomaly thresholds and send notifications via email, Slack, Discord, Teams, or webhook.

Instructions

Create a new alert rule. Watches for cost / error rate / latency / anomaly threshold breaches and notifies the specified channels. Example: "notify me by email when daily cost exceeds $10". channelKinds is an array of channel kinds to enable; channelTargets is an object keyed by those kinds holding the destinations (e.g. channelKinds:["email"], channelTargets:{"email":"dev@example.com"}). Every kind listed in channelKinds must have a destination in channelTargets. anomaly_* types interpret thresholdValue as a standard-deviation multiplier (0.5-10, e.g. 3 = 3 sigma). The Free plan allows the email channel only and up to 3 alerts (the backend returns 403 beyond that).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDisplay name of the alert (1-100 chars, no line breaks)
enabledNoWhether to enable immediately after creation. Default true.
alertTypeYesMetric to watch. cost_threshold = one-shot cost threshold (USD) / monthly_budget = monthly budget (USD) / error_rate = error rate (%) / latency_degradation = latency degradation (ms) / anomaly_cost / anomaly_latency / anomaly_error_rate = anomaly detection (windowMinutes is fixed at 60) / eval_score = quality SLO (evalCriterionId required; fires when the mean score in the recent window drops below thresholdValue) / guardian_findings = external notification of findings (notifies new inbox findings; thresholdValue / windowMinutes are unused — pass 0 and 60)
conditionsNov1.5 multi-condition alert (composite conditions). When specified, single-metric evaluation via alertType + thresholdValue + windowMinutes is ignored and the conditions JSON switches to AND/OR aggregation. Example: {"operator":"AND","conditions":[{"metric":"cost_threshold","threshold":100,"windowMinutes":60,"comparator":">"},{"metric":"error_rate","threshold":0.05,"windowMinutes":60,"comparator":">"}]}. The backend validates the shape via parseConditionsJson (operator AND/OR, 1-8 conditions, each requiring metric/threshold/windowMinutes/comparator). Omit (null) to stay on the single-metric path.
filterModelNoRestrict to this model name only (substring match). Omit for all models
channelKindsYesArray of notification channel kinds to enable (each kind needs a destination under the same key in channelTargets). The Free plan can use email only.
sleepMinutesNoSuppression window for repeated notifications (minutes, 5-10080). After firing once, no re-notification during this window. Default 60.
windowMinutesNoAggregation window (minutes, 5-43200). Default 60. Ignored for anomaly types (fixed at 60).
channelTargetsYesObject keyed by channel kind with the destination as the value (must include a destination for every kind listed in channelKinds). Example: {"email": "dev@example.com"}. email takes an email address; slack/discord/teams/webhook take the service's webhook URL.
filterProviderNoRestrict to this provider only (openai / anthropic / gemini / mistral). Omit for all providers
thresholdValueYesThreshold (>= 0). USD for cost types, % for error_rate, ms for latency_degradation. For anomaly types, a standard-deviation multiplier (e.g. 3 = 3 sigma)
evalCriterionIdNoRequired when alertType=eval_score. The id of the eval criterion to watch (list_eval_criteria.criteria[].id). Fires when the mean score in the recent window drops below thresholdValue.
Behavior4/5

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

Given no annotations, the description carries the transparency burden. It discloses plan limitations, the special interpretation of thresholdValue for anomaly types as a sigma multiplier, and the required relationship between channelKinds and channelTargets. However, it does not mention authentication needs, rate limits, or any destructive behavior (though it's a creation).

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 a single paragraph that efficiently conveys the purpose, main features, and an example. It avoids redundancy and is front-loaded with the core action. However, it could be slightly more structured with bullet points for multiple behavior details.

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 complexity (12 parameters, nested objects, multiple alert types) and no output schema, the description is incomplete. It does not cover the conditions parameter for composite alerts, nor does it mention the evalCriterionId or guardian_findings use cases. Also, it does not hint at the return value (the created alert object). While the schema covers these, the description should provide a high-level summary of all major features.

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?

Schema coverage is 100%, so the schema already documents each parameter. The description adds value by explaining the relationship between channelKinds and channelTargets with an example, the sigma multiplier range for anomaly types, and an illustrative example of usage. This goes beyond the schema's individual field descriptions.

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 tool creates a new alert rule, specifying the types of breaches it watches and the notification action. It distinguishes from siblings like update_alert and delete_alert by using 'create' and describing the creation process.

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 does not explicitly compare to alternatives like propose_alert_rules or when not to use this tool. It implies usage for creating alerts but lacks usage guidance. It mentions a plan limitation (Free plan only email, up to 3 alerts) which is a constraint but not a usage alternative.

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

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