AlertINT HTTP MCP server for alert correlation, incident management, and operator feedback. Provides read-only access to alerts, incidents, and audit logs, plus write-back tools for incident annotations and verdict capture. Integrates with Prometheus, logs, Sentry, Zabbix, and change event sources.
AlertINT MCP server demonstrates solid definition quality with 16 well-named tools covering incident management, observability queries, and feedback capture. All tools have descriptions (avg 180 chars, within 10-1024 baseline). Input schemas are present and typed for all tools. However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Error handling descriptions are minimal; tools lack recovery guidance. Two write tools (alertint_incident_annotate, alertint_incident_capture_verdict) have good descriptions but lack explicit confirmation/dry-run patterns. Parameter descriptions are generally adequate but some lack format/constraint details (e.g., RFC3339 time format stated but not in all time params). Tool composition is strong, each tool has single responsibility and names follow verb_noun convention.
Return the compact evidence pack for an incident — the same structured context that the acute-triage skill passed to the LLM: shared labels, alert timeline, severity distribution, and top annotations.
Get full details for one incident: member alerts with their roles, AI finding (analysis name, overall issue, correlation findings, severity, confidence), and raw LLM output JSON. drill=true marks a synthetic drill fired by `alertint drill`, not a real incident.
Attach an operator note to an incident — human context for the next investigator, shown in the incident's history (Slack card and MCP reads), permanent and age-stamped. Notes never influence triage or memory recall; to correct or confirm a finding with machine effect, use alertint_incident_capture_verdict. Writes land only in AlertINT's own incident state, audit-chained — never in your systems.
Capture an operator-confirmed verdict for an incident — a correction or a confirmation — as a replayable, graded record. NEVER call this without an explicit human confirmation of the verdict. Persists the verdict + annotation first (a grading failure cannot lose the capture), runs the widen_queries live once to freeze discriminating evidence, then grades current triage against the expectation: red/green with a layer (evidence_selection = fix a rule/check; synthesis = fix a hint/prompt). The grade is advisory — one sample, not a certification. A repeat call re-grades without re-persisting; a changed expectation or new widen_queries creates a new version.
Output schemas not documented. LLMs cannot predict response structure for incident details, evidence packs, or query results. This breaks tool chaining, agents cannot know which fields to extract for downstream calls.
Write tools lack explicit confirmation/dry-run pattern. alertint_incident_capture_verdict performs grading and persistence without a preview step. Agents cannot validate verdicts before committing irreversible feedback.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
List recent AlertINT incidents, newest first. Each incident groups one or more related alerts with an AI finding. Rows with drill=true are synthetic drills fired by `alertint drill`, not real incidents.
Query recent change events (deployments, config changes, etc.) matching optional label selectors. Returns changes ordered by recency within the configured window.
Search stored alerts. All parameters are optional. Returns alerts ordered by received_at descending.
Operational usage summary over a time window: alert deliveries and alerts received, LLM call/token volume (with a per-model breakdown).
Walk the hash-chained audit log and verify tamper-evidence. Returns the number of rows checked and whether the chain is intact.
Query logs from the configured log source (Loki or compatible backend) over a time range. Returns log streams matching the query.
Query Prometheus for instant vector data. Returns metric values at a single point in time.
Query Prometheus for range vector data over a time interval. Returns metric values across a time range.
List recent Sentry error issues matching optional filters. Returns issues ordered by recency within the configured live window.
Get detailed trace and event information for a specific Sentry issue.
Query current problems (active alerts) for a Zabbix host.
Query Zabbix metric history for a specific item over a time range. Returns historical metric values.
Time parameter descriptions inconsistent. alertint_search_alerts documents RFC3339 format in 'since'/'until' descriptions, but prometheus_query_range and loki_query_range state 'RFC3339 or Unix timestamp' without clarifying which is preferred or how to distinguish them.
alertint_incident_capture_verdict expectation parameter is complex object with optional fields (cause_alert, cause_series, severity_rank, must_mention, must_not_conclude). Description states 'At least one of must_mention/must_not_conclude is required' but does not clarify which combinations are valid or what happens if both are omitted.
No error handling guidance in tool descriptions. Tools do not document what errors are retryable, what user-fixable errors look like, or how to recover from failures (e.g., if Prometheus is unreachable, should agent retry or fall back to Loki?).