Loading ToolBench
Air-raid alert history for Kyiv City, recorded locally from raid.fly.dev and alerts.in.ua. Read-only MCP query surface over collected data with coverage verdicts.
Three well-named, read-only tools with clear domain purpose (Kyiv air-raid alerts). Tool names follow verb_noun pattern (alerts_window, alerts_for_sleep, ingest_status). Descriptions are detailed (150 - 250 chars) and explain WHAT, WHEN, and output structure. Input schemas present with ISO-8601 format guidance. Critical strength: every tool documents a 'coverage' verdict (full/partial/none) in the description, addressing the core ambiguity the service solves. Weakness: output schemas are not explicitly documented in the visible code, only inferred from descriptions. No error handling guidance visible (e.g., what happens on invalid ISO-8601 input, malformed timestamps, or DB unavailability). No parameter constraints (enums, min/max) for numeric or categorical inputs. Tool composition is clean (three separate concerns), but ingest_status takes no parameters, unclear how to filter by source or time range.
Given a sleep window in Europe/Kyiv local time, returns alerts that ended in the 6 hours before onset (bedtime delay), alerts overlapping the sleep itself with per-alert overlap minutes (sleep fragmentation), total overlap minutes, whether explosions were reported, and the coverage verdict. All overlap arithmetic is done server-side.
Air-raid alert intervals overlapping a Europe/Kyiv local time window, with a coverage verdict for that window.
Last successful ingest per source, current connection state, total disconnect minutes over the last 7 days, and coverage gaps over the last 30 days. Use this to judge how much any absence of alerts can be trusted.
Output schemas not documented. Descriptions mention 'coverage verdict' and 'overlap minutes' but no formal schema (field names, types, structure) is visible in code. LLMs cannot plan downstream operations without knowing response structure.
No error handling guidance. Tool descriptions do not explain what happens on invalid ISO-8601 input, timezone mismatches, or database unavailability. LLMs have no recovery path.
ingest_status takes no parameters but description mentions 'per source' and '7 days' / '30 days'. No way to filter by source, time range, or region. Tool is inflexible.
ISO-8601 timestamp parameters lack formal constraints. Description says 'e.g. "2026-08-08T22:30"' but no regex pattern, minLength, or format declaration in schema. LLMs may pass invalid formats.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
No pagination or result limits documented. If alerts_window spans a long period or returns many alerts, response could be unbounded. No mention of max results or cursor-based pagination.