Loading ToolBench
An Express-based HTTP server providing MCP (Model Context Protocol) tools for workflow orchestration and n8n integration
This HTTP-based MCP server has 2 tools with visible schemas and descriptions in Swedish. Both tools are explicitly registered in the MANIFEST object with input_schema defined. However, there are significant quality gaps: descriptions are minimal (10-20 chars), parameter descriptions are sparse or missing, no output schemas are documented, error handling is basic, and no guidance for recovery. The call_n8n tool has a critical issue: its 'flow' enum is dynamically set but often empty (FLOW_ENUM fallback prevents complete failure, but this is fragile). Tool naming lacks clarity, 'call_n8n' is implementation-specific rather than domain-focused. Both tools are directly visible in server.js, so no inference penalty applies.
Anropa ett n8n-workflow via namn. Skicka JSON-payload och få tillbaka n8n-svaret.
Returnerar en hälsning.
Tool names lack action verbs and domain clarity. 'hello_world' is a test/example tool masquerading as production. 'call_n8n' exposes implementation details (n8n) rather than describing the business action (e.g., 'trigger_workflow', 'execute_automation'). LLMs cannot infer intent from these names.
Descriptions are too short and lack context. 'Returnerar en hälsning' (Returns a greeting) is 27 chars, below the 34-char p10 baseline and fails to explain when/why to use the tool. 'Anropa ett n8n-workflow via namn...' is 90 chars but vague about what happens after invocation (side effects, state changes, return structure).
Parameter descriptions are missing or incomplete. The 'call_n8n' tool has parameters 'flow' (enum), 'data' (object), and 'headers' (object), but no guidance on what 'data' should contain, what 'headers' are valid, or format expectations. 'name' parameter in hello_world has minimal context. No examples of valid payloads or header structures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
No output/return schemas documented. Neither tool declares what fields, types, or structure the response contains. Clients and LLMs must reverse-engineer responses. For 'call_n8n', the actual response object (ok, status, n8n_url, request, response) is not declared in the manifest.
Error handling lacks recovery guidance. On invalid 'flow', the tool returns 'Unknown or unavailable workflow' with available options, this is good. But missing 'flow' parameter returns '400 Missing flow' without suggesting what to do next (e.g., 'Call /mcp/tools/full to list available workflows'). Error responses do not guide LLM recovery.
'call_n8n' flow enum is fragile. FLOW_ENUM dynamically filters N8N_MAP by whether URLs are set in env vars. If all URLs are unset, FLOW_ENUM falls back to ['create-lead'], but that workflow may not actually be callable (N8N_MAP['create-lead'] would be undefined). This breaks tool discovery and can cause runtime failures. The fallback masks the true issue.
No idempotence guarantees. The 'call_n8n' tool invokes external n8n workflows without documenting whether repeated calls with the same payload are idempotent. If a workflow creates a lead, re-invoking it will create a duplicate. Agents will retry on transient failures, without idempotence guarantees, this causes data duplication.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The manifest lists no tool annotations. 'call_n8n' is marked as WRITE risk but the tool definition has no destructiveHint: true flag. 'hello_world' is READ_ONLY but has no readOnlyHint: true. These hints guide agent planning and safety checks.