Loading ToolBench
A comprehensive Model Context Protocol (MCP) server for accessing Israeli emergency alerts via real-time subscription to a FastAPI middleware service. Provides real-time checking of current active emergency alerts, alert history retrieval with optional region filtering, and live subscription to emergency alert streams via Server-Sent Events (SSE).
The server defines 3 tools for Pikud Haoref alert management. Tool naming follows a clear verb-noun pattern (check_*, get_*), which is good. However, descriptions are present but minimal (15-80 chars), and input schemas are partially documented. The most critical gap is that input schemas lack proper type definitions and descriptions for parameters in critical tools. Tool `get_alert_history` has the best schema definition with typed parameters and descriptions, but `check_current_alerts` and `get_connection_status` have empty input objects with no documented response schemas. No tool documents output structure, error handling, or recovery guidance. This forces LLMs to infer result shapes and limits robust chaining. The server is HTTP-based (Streamable HTTP), which is current. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present, despite all being READ_ONLY operations.
Check for current active emergency alerts from subscribed stream
Get recent alert history by fetching directly from the Pikud Haoref API.
Check SSE subscription connection status
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract response fields without explicit schema documentation.
Input schemas for check_current_alerts and get_connection_status are empty objects with no parameters or descriptions. This is correct (no inputs needed), but response structure must be documented in tool descriptions or via separate schema definitions.
Tool descriptions are too brief (<50 chars for 2 of 3 tools). Cannot fully convey WHAT the tool does, WHEN to use it, or any prerequisites. 'Check for current active emergency alerts' (54 chars) lacks context on how results differ from get_alert_history or frequency of updates.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
No error handling or recovery guidance. If a tool call fails (API timeout, connection lost, invalid region), the response provides no actionable next steps for the LLM.
Tool annotations missing. All three tools are READ_ONLY and should declare readOnlyHint=true to signal safe retryability and safe parallel execution to LLMs.
get_alert_history parameter 'cities' expects Hebrew city names but includes no guidance on fallback behavior if a Hebrew name is misspelled or not found. The instruction '**IMPORTANT: Please provide city names in Hebrew**' is in the description but lacks validation or error context.
get_alert_history 'limit' parameter range is documented (1-50, default 10) in description, not as JSON Schema constraints (minimum, maximum). Formal constraints are machine-parseable and prevent LLMs from requesting 500 items.