Loading ToolBench
Simple MCP Server to use Electrolux appliances from AI. Uses Model Context Protocol and Electrolux Group API.
Server has 2 tools with basic descriptions but critical gaps in schema documentation, parameter descriptions, and error handling. Tool definitions are inferred from test code (McpClient.kt) rather than explicitly registered in the main codebase, which is a significant red flag. Descriptions are present but minimal (50-60 chars). Input schemas show parameter names but lack explicit type declarations and parameter-level descriptions in the visible code. No output schemas documented. No error handling guidance. Server does not meet baseline for production use.
Get info of my Electrolux appliance with applianceId using jwtToken and apiKey.
Get list of my Electrolux appliances using jwtToken and apiKey.
Tool definitions not found in main source code, only visible in test file (McpClient.kt). Cannot verify actual tool registration, method signatures, or how Spring AI framework exposes these tools to MCP clients. This suggests tools may be inferred by the framework rather than explicitly defined.
Parameter descriptions missing or not visible. Input schema shows parameter names (apiKey, jwtToken, applianceId) with brief type hints, but no inline descriptions explaining what each parameter controls, expected format, or constraints. Rubric requires every parameter to have a description explaining meaning and constraints.
API credentials (apiKey, jwtToken) exposed as tool parameters. Rubric explicitly forbids credentials as parameters, they must be server-side injected via environment variables or vault. Agent traces log all parameters, risking credential leaks into logs and prompt history.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No output schemas documented. Tool descriptions state what the tools do but do not specify the structure of the response, field names, types, or what the agent should expect. LLMs cannot plan downstream calls without knowing response structure.
No error handling guidance. Tools have no documented error cases, recovery steps, or what an LLM should do if the Electrolux API returns 401 (auth failed), 404 (appliance not found), or network timeout. Rubric requires error responses to guide the LLM on next steps.
Tool descriptions are too brief (50-60 chars). Rubric baseline: average tool description is 194 chars (p10=34, p90=392). These descriptions lack context on when to call each tool vs the other, what the appliance data looks like, or whether pagination is supported.
No pagination or result limits documented. If getElectroluxAppliances returns many devices, no indication of max results, pagination parameters, or offset/limit support. Rubric requires tools returning lists to document pagination.