Loading ToolBench
A React-based flood monitoring and emergency alert system for Malaysia that uses AI vision analysis, citizen sensor networks, and government coordination tools to assess flood severity and dispatch emergency alerts
Server has 6 tools with basic naming and descriptions, but significant gaps in schema completeness and parameter documentation. Tool names follow verb_noun convention (scan_, get_, update_, dispatch_). Descriptions exist but are generic (avg ~120 chars, below 194-char baseline). Input schemas visible in code but lack formal JSON Schema type declarations, only string keys with type hints in comments. No output schemas documented. Error handling returns structured MCPToolResult but lacks recovery guidance. Missing parameter descriptions for all inputs. No enum constraints, validation rules, or format specifications. Security concerns: Firebase credentials likely in environment but not explicitly validated. Composition is reasonable (6 focused tools), but parameter naming inconsistencies (zoneId vs zone_id) and missing chaining IDs in responses.
Dispatches emergency flood alert for a zone to Malaysian authorities. Use for severity >= 7 zones only.
Discovers all active citizen sensor nodes currently reporting flood data. Returns node list for agent to plan resource allocation
Checks BILAHUJAN system health: active nodes, last heartbeat, network status, and zone coverage
Retrieves current flood severity, water depth, hazards and metadata for a specific zone from Firebase
Analyzes flood image for a zone using Gemini AI vision, returns 16-field structured flood assessment including severity, depth, hazards, and passability
Updates severity level of a flood zone with reason and audit timestamp for government tracking
Input schemas lack formal JSON Schema type declarations. Code shows `inputSchema: { zoneId: 'string', imageBase64: 'string' }` but this is not valid JSON Schema, missing $schema, type: 'object', properties, required arrays. LLMs cannot parse this format reliably.
No parameter descriptions in tool definitions. Each parameter (zoneId, imageBase64, severity, reason, authorities) lacks a description field explaining its purpose, format, or constraints. LLMs cannot infer meaning from names alone.
No output schemas documented. Tools return MCPToolResult with 'output' field, but the structure of output (e.g., 16-field flood assessment from scan_flood_zone) is not formally specified. Agents cannot plan downstream calls without knowing response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
Error messages lack recovery guidance. Errors return raw strings like 'Failed to scan flood zone' or 'zoneId and imageBase64 are required' without suggesting next steps (e.g., 'Try get_active_nodes() to find valid zones').
Parameter naming inconsistency: tools use camelCase (zoneId, imageBase64) but MCP convention is snake_case (zone_id, image_base64). This forces LLMs to reason about naming conventions and risks parameter mapping errors.