Loading ToolBench
ESP-RainMaker-MCP has 5 tools with moderate definition quality issues. Tool names follow verb_noun convention (login_instructions, check_login_status, get_nodes, get_node_status, get_params), which is positive. However, there are significant gaps in schema documentation, parameter descriptions, and output structure documentation. The server provides markdown-formatted descriptions for most tools, but parameters lack detailed constraints (ranges, allowed values, format specifications). Input parameters are minimally documented, 'ctx' appears in 4 tools with only generic 'MCP context' description. The get_params tool lacks crucial information about which parameters it returns or their structure. Output schemas are not formally documented for any tool. Error handling provides recovery guidance (e.g., 'Try search_users()') in some cases but is inconsistent. Tool composition is sound (each tool does one thing), but the lack of structured output documentation hampers agent reasoning about downstream tool chains.
Checks if a valid login session exists based on stored credentials.
Get ONLY the online/offline status for a specific node. Use this tool only when: - User specifically asks about "status", "online", "offline" of a particular device - You already have other info and need just the status For comprehensive device information, use get_node_details instead.
Get ONLY the list of node IDs (names) without detailed information. Use this tool only when: - User specifically asks for "node IDs", "device names", or "list of devices" - You need just the names/IDs for reference For comprehensive device information, use get_node_details instead.
Get ONLY the current parameters (state) for a specific node. Use this tool only when: - User specifically asks for "parameters", "state", or "current values" of a particular device - You already have other info and need just the current state For comprehensive device information, use get_node_details instead.
Provides instructions (formatted with Markdown) on how to log in using the standard ESP RainMaker CLI. This server relies on credentials saved locally by that process. Rendering as Markdown depends on the MCP client capabilities.
No output schemas documented for any tool. Tools return strings or lists (e.g., get_nodes returns list[str] | str, get_params returns unstated structure), but callers cannot predict field names, types, or nested object structures. This forces LLMs to guess about downstream tool chain requirements.
Parameter 'ctx' (type Context) appears in 4 tools with only the description 'MCP context'. This is a required framework parameter not exposed by the MCP agent and should not be listed as a user-facing input parameter. All 4 tools incorrectly expose it in their input schemas.
Parameter 'node_id' (in get_node_status, get_params) has minimal description: only 'The node ID to get status for' / 'The node ID to get parameters for'. No guidance on format (alphanumeric? UUID? opaque string?), length limits, or how to discover valid node IDs (should reference get_nodes). LLMs cannot validate input without these constraints.
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 | 25 | - | v1 |
Tool descriptions for get_node_status and get_params contain guidance text ('Use this tool only when...') that reads as hints for the LLM rather than formal specifications. This is helpful for disambiguation but lacks complementary error handling that tells the LLM what to do if it calls the tool at the wrong time or with wrong intent.
Error responses are inconsistent. Some tools return well-formatted error strings (e.g., check_login_status returns 'Login session is active for user: {user_name}' or recovery guidance). Others (get_nodes, get_node_status, get_params) log exceptions but return truncated error messages ('Erro' visible in source snippet, suggesting incomplete error formatting).
No pagination support. get_nodes returns a raw list of node IDs with no limit, offset, or next_cursor. For users with hundreds of devices, this returns a potentially massive list that bloats context and degrades LLM reasoning. No documentation of result limits.