Loading ToolBench
MCP server for power outage analysis providing weather data, work order information, device analysis, and environmental data processing
This server exhibits significant gaps in definition quality across most tools. While tool names start with action verbs (get_, process_), descriptions lack the depth and context needed for LLM selection. Most critically, parameter descriptions are sparse or missing entirely, and output schemas are completely undocumented. The server operates 12 tools that fetch and process power outage event data, but the presentation quality is far below production standards. Average tool description length is ~45 characters (baseline 194), well below acceptable range. Parameter descriptions are minimal or absent for critical inputs. No output schemas are documented anywhere in the codebase.
处理总结环境信息
获取设备信息数据，封装对设备数据服务的调用。
获取无人机图片分析结果
获取原始环境数据
获取停电事件基本信息。
获取保护报文数据，封装对保护报文数据服务的调用
获取录波数据，封装对录播数据服务的调用
Output schemas completely undocumented. No tool in the codebase documents what fields are returned, their types, or structure. LLMs cannot plan downstream tool calls or extract required data without schema documentation.
Parameter descriptions are minimal or absent. Critical parameters like 'outage_number', 'analysis_type', 'tower_ids' lack context about expected format, valid ranges, or dependencies. 'analysis_type' integer parameter only states in code validation '1 or 2' but description does not explain what these values mean (during vs. post-outage analysis).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
获取停电时间沿线天气分析数据，封装对天气数据服务的调用。
处理并总结报文、录波数据，生成报文智能体的输入数据
处理设备信息数据，生成大模型输入参数。
处理并总结天气数据，获取天气数据后调用此工具处理天气数据并生成汇总天气信息
沿线诉求工单查询工具，获取沿线历史及当前客户工单信息。
Tool descriptions lack actionable context for LLM selection. Descriptions are under 50 characters on average (baseline 194). For example, 'get_environment_raw_data' description is only '获取原始环境数据' (20 chars), does not explain what 'raw' means, when to call it vs. other environment tools, or what processing occurs downstream. LLMs cannot distinguish similar tools.
No error handling guidance. Code includes validation (e.g., 'if analysis_type not in (1, 2): raise ValueError()') but error responses do not guide LLM recovery. When validation fails, the LLM receives a ValueError with no suggestion for what to try next or which tool might provide valid analysis_type values.
Tool composition unclear. Tools like 'weather_data_processing' and 'get_weather_data' have implicit dependencies, LLM must infer that output from get_weather_data feeds into weather_data_processing. Tool descriptions do not state prerequisites or dependencies explicitly.
Raw API responses returned without filtering. Tools like 'get_environment_raw_data' explicitly call post_to_data_service() and return nested JSON with 'code', 'success', 'data', 'msg' metadata. These fields waste tokens and obscure the actual payload the LLM needs. Baseline pattern recommends stripping API metadata and returning only relevant fields.
No pagination support documented. Tools returning lists (e.g., work_order_query_tool, get_environment_raw_data with infos array) do not expose limit, offset, or pagination parameters. Large result sets will blow context window without pagination.
Processing tools operate on untyped Dict[str, Any] objects. 'weather_data_processing' accepts 'weather_data: Dict[str, Any]' with no schema constraint, enum, or format validation. LLMs cannot infer valid structure.