Skip to main content
Glama

Ankra

by ai.ankra
OverviewDiscussionsAdmin

create_alert

Create an alert definition: a named alert with one or more rules the platform evaluates every minute. Use this when asked to create, add or set up an alert on Ankra (an Alertmanager silence is create_alertmanager_silence instead). Before calling: list_alerts to avoid a duplicate name (names are unique per organisation), list_clusters for cluster ids, and list_alert_destinations if integration_names will be set. Each rule targets resource_type 'cluster' (cluster health) or 'cluster_resource' (the stacks, addons, manifests and GitOps repositories on a cluster; cluster_resource_types is then required), is scoped by cluster_ids, environments or all_clusters=true (a rule naming none targets the chat's bound cluster), and carries a severity (critical/warning/info, default warning) and cooldown_minutes between re-fires (default 15). Condition vocabulary, by resource_type. cluster: cluster_state (condition_value offline|online, operator eq|neq); gitops_sync (failing|degraded|healthy, eq|neq); metric_threshold (condition_value is the metric key: cpu_utilisation_pct, memory_utilisation_pct, disk_utilisation_pct (cluster-wide average), node_disk_utilisation_max_pct (fullest node), pod_restarts_15m, oom_kills_15m, nodes_not_ready, nodes_disk_pressure (nodes with the kubelet DiskPressure condition), pods_pending, pods_failed (pods in phase Failed, which is where kubelet evictions land); operator gt|gte|lt|lte|eq|neq against threshold_value); metric_absence (condition_value may be omitted - it is fixed to platform_metrics; fires when the cluster has shipped no platform metrics for more than threshold_value minutes); security_findings (condition_value is the posture metric: critical, high, severe, fixable_critical, fixable_high, new_severe_cves, new_kev_cves, kev, risk_score; compared against threshold_value). cluster_resource: resource_state (all_up|up|creating|updating|stopping|down) and job_status (failed|timeout|running|success|pending|blocked|cancelled|cancelling), both eq|neq. Conditions within one rule combine with logical_operator AND (default) or OR. Any other condition type, value or operator is refused rather than stored, because the evaluator would never fire it and the alert would sit dead while reading as configured. Firings notify through the organisation's notification routes (list_notification_routes); integration_names additionally wires the alert directly to named destinations from list_alert_destinations, and an unknown name is refused. The alert is created enabled unless enabled=false. Reversible with delete_alert; to quieten it later prefer set_alert_enabled.

Input Schema

NameRequiredDescriptionDefault
nameYesAlert name, unique within the organisation (at most 100 characters).
rulesYesThe rules evaluated for this alert; the alert fires when any rule's conditions are met.
enabledNofalse creates the alert muted. Default true.
descriptionNoWhat the alert watches and why (at most 500 characters).
integration_namesNoNames of existing alert destinations (list_alert_destinations) to notify directly, in addition to the organisation's notification routes. An unknown name is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / rules / items / properties / min_failure_duration_minutes / description
      Previous value: -"Minutes the rule must keep reading triggered before it fires; a healthy evaluation in between resets it. Omit for the default: 5 for a pods_pending condition (a starting pod is Pending for seconds), otherwise 0, which fires on the first evaluation."New value: +"Minutes the rule must keep reading triggered before it fires; a healthy evaluation in between resets it. Omit for the default: 5 for a pods_pending or pods_failed condition (a starting pod is Pending for seconds, and a pod a rolling update deletes can be Failed for seconds), otherwise 0, which fires on the first evaluation."
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only establish that this is a non-read-only, non-destructive, non-idempotent write. The description adds substantial behavioral context beyond that: minute-level evaluation, unique names per organisation, refusal of invalid condition types/values/operators and unknown integration names, default enabled state, notification routing, and reversibility.

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?

It is front-loaded with purpose, usage guidance and prerequisites before the detailed condition catalog, and most sentences carry useful operational detail. However, it is a single very dense paragraph with an unusually long condition vocabulary, which makes it less scannable than ideal.

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

Completeness5/5

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

For a complex nested create tool with no output schema, the description supplies prerequisites, validation behavior, defaults, scoping rules, lifecycle alternatives and notification semantics. It is complete enough for an agent to construct a correct call without additional discovery.

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

Parameters5/5

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

Schema description coverage is already 100%, but the description adds cross-parameter semantics that the schema does not fully capture: condition vocabulary by resource_type, metric keys and their meanings, allowed operators, logical combination, scoping interactions between cluster_ids/environments/all_clusters, and special defaults such as min_failure_duration_minutes.

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?

States a specific verb and resource: 'Create an alert definition', then defines it as a named alert with rules the platform evaluates every minute. It explicitly distinguishes this from create_alertmanager_silence, so an agent can route between the two without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use guidance, prerequisite calls, and alternatives: use when asked to create/add/set up an alert, use create_alertmanager_silence instead for a silence, and call list_alerts, list_clusters and list_alert_destinations beforehand where relevant. It also names delete_alert and set_alert_enabled for follow-up management.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Ankra toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources