Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Review current and historical problems from Zabbix — severity, which host, when it started, how long it has been active, and whether anyone has acknowledged it. Use when someone asks what is broken right now, how long something has been broken, or what happened during a window that has already passed.
.claude/skills/automateyournetwork-zabbix-problem-review/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-14 | ✗→✓ | ▲ Improved | -42% | 0% |
| case-22 | ✗→✓ | ▲ Improved | -12% | 0% |
| case-24 | ✗→✓ | ▲ Improved | -18% | 0% |
| case-25 | ✗→✓ | ▲ Improved | -1% | 0% |
| case-01 | ✓→✗ | ▼ Worse | 32% | 0% |
zabbix-mcp — vendored third-party, read-only, three tools. See zabbix-metrics-history for the shared cautions.
| Question | Method | Note | |---|---|---| | What is wrong now? | problem.get | Reads a dedicated problem table. This is the right one | | What happened then? | event.get | Historical, heavier, needs a time window | | What rule fired it? | trigger.get | The definition behind a problem |
jsonczabbix_api("problem.get", { "output": "extend", "selectAcknowledges": "extend", "selectTags": "extend", "recent": false, "sortfield": ["eventid"], "sortorder": "DESC" })
Every problem you report carries: severity · host · when it started · how long it has been active · acknowledgement state. "How long" is the question NetClaw could not answer at all before this integration existed — do not drop it.
> ### "No active problems" and "the NMS could not be reached" are not the same answer.
An empty problem list is a legitimate, positive finding — the monitoring system looked and found nothing wrong. An unreachable NMS is a failure to look.
They are both an empty result over the wire, and reporting the second as the first is the most misleading thing this skill can do: it tells an engineer everything is fine at exactly the moment monitoring is blind.
Three outcomes, three different sentences:
| | Say | |---|---| | NMS reachable, nothing wrong | "Zabbix reports no active problems as of \<time>." | | NMS unreachable | "Zabbix could not be reached — this is not a statement about the network." | | Credentials rejected | "Zabbix rejected the credentials — the monitoring state is unknown." |
An acknowledged problem is still happening. Someone has said "I've seen this", which is a fact about the team, not about the network.
Report it as "active, acknowledged by \<who> at \<when>". Never let acknowledgement soften the description of the underlying condition, and never let a filtered-out acknowledged problem disappear from a count.
Filter before you answer — by severity, host or group — rather than returning everything and asking the reader to ignore rows. Use severities, hostids or groupids on the call.
Severities: 0 not classified · 1 information · 2 warning · 3 average · 4 high · 5 disaster.
When you filter, say what you filtered out, so "two problems" is never mistaken for "two problems exist".
event.get with value: 0 gives resolutions. Report both onset and resolution times — a problem that lasted four minutes and one that lasted four hours are different incidents, and the duration is usually the point of the question.
| Want to… | Use | |---|---| | Metric values over time | zabbix-metrics-history | | Availability and inventory | zabbix-availability | | Unsolicited traps | snmptrap-mcp — push, not poll | | Flows | ipfix-mcp | | Instrumented metrics / dashboards | prometheus, grafana | | SaaS monitoring | auvik, thousandeyes, datadog | | Current device state | pyats, multivendor-cli, fortinet — this is the poller's view over time | | Acknowledge, close or suppress anything | nothing here. This integration is strictly read-only |
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-07 | pass→pass | 16,952 | 6,123 | -64% | 1 | 1 | 0% | 1,700 | 2,020 | +19% | 0 | 0 | — |
case-01 | pass→fail | 12,052 | 19,281 | +60% | 1 | 1 | 0% | 1,228 | 1,619 | +32% | 0 | 0 | — |
case-02 | fail→fail | 16,095 | 11,146 | -31% | 1 | 1 | 0% | 2,001 | 1,421 | -29% | 0 | 0 | — |
case-03 | fail→fail | 14,221 | 18,413 | +29% | 1 | 1 | 0% | 1,773 | 1,413 | -20% | 0 | 0 | — |
case-04 | pass→pass | 17,641 | 9,095 | -48% | 1 | 1 | 0% | 1,680 | 2,180 | +30% | 0 | 0 | — |
case-05 | pass→pass | 15,236 | 11,248 | -26% | 1 | 1 | 0% | 1,691 | 1,757 | +4% | 0 | 0 | — |
case-06 | pass→pass | 14,706 | 5,045 | -66% | 1 | 1 | 0% | 1,510 | 1,780 | +18% | 0 | 0 | — |
case-08 | pass→pass | 14,748 | 3,907 | -74% | 1 | 1 | 0% | 1,749 | 1,771 | +1% | 0 | 0 | — |
case-09 | pass→pass | 12,172 | 8,598 | -29% | 1 | 1 | 0% | 1,247 | 1,407 | +13% | 0 | 0 | — |
case-10 | pass→pass | 13,343 | 2,283 | -83% | 1 | 1 | 0% | 645 | 1,302 | +102% | 0 | 0 | — |
case-11 | pass→pass | 13,168 | 5,729 | -56% | 1 | 1 | 0% | 2,225 | 1,803 | -19% | 0 | 0 | — |
case-12 | pass→pass | 11,709 | 9,681 | -17% | 1 | 1 | 0% | 1,689 | 1,750 | +4% | 0 | 0 | — |
case-13 | pass→pass | 11,802 | 5,710 | -52% | 1 | 1 | 0% | 1,915 | 1,715 | -10% | 0 | 0 | — |
case-14 | fail→pass | 16,846 | 3,158 | -81% | 1 | 1 | 0% | 2,529 | 1,467 | -42% | 0 | 0 | — |
case-15 | pass→pass | 3,969 | 3,070 | -23% | 1 | 1 | 0% | 583 | 1,408 | +142% | 0 | 0 | — |
case-16 | pass→pass | 5,956 | 2,936 | -51% | 1 | 1 | 0% | 914 | 1,369 | +50% | 0 | 0 | — |
case-17 | pass→pass | 2,544 | 1,827 | -28% | 1 | 1 | 0% | 424 | 1,282 | +202% | 0 | 0 | — |
case-18 | pass→pass | 14,756 | 2,422 | -84% | 1 | 1 | 0% | 2,221 | 1,373 | -38% | 0 | 0 | — |
case-19 | pass→pass | 8,956 | 5,758 | -36% | 1 | 1 | 0% | 1,428 | 1,814 | +27% | 0 | 0 | — |
case-20 | pass→pass | 7,145 | 3,290 | -54% | 1 | 1 | 0% | 1,212 | 1,358 | +12% | 0 | 0 | — |
case-21 | pass→pass | 7,217 | 3,991 | -45% | 1 | 1 | 0% | 1,265 | 1,446 | +14% | 0 | 0 | — |
case-22 | fail→pass | 15,644 | 8,817 | -44% | 1 | 1 | 0% | 2,609 | 2,286 | -12% | 0 | 0 | — |
case-23 | fail→fail | 23,432 | 19,338 | -17% | 1 | 1 | 0% | 3,503 | 2,776 | -21% | 0 | 0 | — |
case-24 | fail→pass | 24,886 | 13,817 | -44% | 1 | 1 | 0% | 3,389 | 2,777 | -18% | 0 | 0 | — |
case-25 | fail→pass | 12,936 | 5,057 | -61% | 1 | 1 | 0% | 1,825 | 1,810 | -1% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 25 cases were attempted, and 22 counted toward the lift figure. The other 3 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +12 percentage points is the difference between those two pass rates over the 22 comparable cases. 2 cases got worse with the skill loaded, and they are included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.