Loading ToolBench
A Node-RED sidebar plugin that provides AI development copilot functionality with MCP support. Enables users to create and manage flows through MCP tools with safety protections for critical infrastructure.
The Node-RED Dev Copilot MCP server exhibits significant definition quality gaps across multiple dimensions. While it implements 18 tools with basic naming conventions (mostly verb_noun), the descriptions are minimal (often 10-30 chars), parameter documentation is sparse, output schemas are not visible in the provided source, and error handling guidance is absent. The server appears to be a custom Node-RED plugin providing MCP interface to Node-RED flows and nodes. Tool names like 'get-flows', 'create-flow', 'update-flow' follow naming conventions but descriptions lack context on WHEN to use each tool vs alternatives. Parameters are minimally described (e.g., 'id': 'Flow identifier' is too brief to guide LLM selection). Most critically, no input/output schemas are visible in the source code provided, and no error recovery guidance is documented. The implementation reads as an early-stage MCP server without production-grade polish.
Create backup
Create new flow
Remove flow
Search nodes by type
List installed nodes
Get backup content
System diagnostics
Get specific flow details
List all flows
Descriptions are uniformly too brief (10-30 chars) and lack WHEN/WHY context. Current descriptions like 'List all flows', 'Get specific flow details', 'Human-readable flow list' provide no guidance on when an LLM should choose one over another (get-flows vs get-flows-formatted vs list-tabs). An LLM cannot infer the distinction without detailed descriptions.
Input parameter descriptions are minimal or missing. E.g., 'flowJson' in create-flow and update-flow is described only as 'Flow configuration as JSON', no guidance on required fields, valid structure, or constraints. Parameter 'module' in install-node-module lacks format/version guidance. This forces LLMs to guess at structure and risks invalid API calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Human-readable flow list
Get node details
Node-RED settings
Trigger inject node for testing
Install node package
View backups
List flow tabs
Modify existing flow
Create flow visualization
No output schemas are documented. E.g., create-flow should document: 'Returns object with {id, name, status, createdAt}'. Without this, agents cannot reliably compose tool sequences (e.g., create-flow → get-flow → update-flow). None of the 18 tools show documented response schemas in the provided source.
Error handling lacks recovery guidance. Try search_users() with partial name.'). No evidence of error classification (retryable vs user-fixable vs fatal) or actionable error messages in the source. Destructive tools (delete-flow) should support dry-run or confirmation, but none is evident. Missing: HTTP status codes, error messages with recovery hints, confirmation patterns for irreversible operations.
Tool names show ambiguity and overlap. 'get-flows', 'get-flows-formatted', 'list-tabs' appear to query flows but distinction is unclear from names alone. Similarly, 'get-settings' and 'get-diagnostics' lack descriptive context. LLMs will struggle to select the right tool without reading full descriptions.
Parameter type constraints are missing. Example: 'reason' in backup-flows has no enum, valid values are not documented. 'detailed' in list-backups is marked boolean but LLMs often need guidance on when true vs false is appropriate. No minimum/maximum bounds on numeric inputs (if any). Absence of constraints invites invalid LLM inputs.
'inject' is an ambiguous tool name. 'inject' alone is vague, inject what? into where? A more specific name like 'trigger-inject-node' or 'send-test-message' would clarify intent. Current description 'Trigger inject node for testing' is only 35 chars and lacks context on when/why to use it.
Composition issues: no evidence of pagination or result limiting. Tools like 'get-flows', 'get-available-nodes', 'list-backups' don't document limit/offset/page parameters. Large result sets blow context window. No documented limits or pagination guidance.
No documented tool dependencies or chaining guidance. E.g., does create-flow return an 'id' that update-flow and delete-flow expect? Does get-available-nodes return 'module' names that install-node-module accepts? No chaining documentation visible.