Loading ToolBench
BMAD Framework for n8n workflow automation teams - AI-powered development methodology
The n8n-BMAD MCP server provides 14 tools for agent management, context generation, node discovery, and 'party' orchestration. However, there are significant gaps in definition quality across most dimensions. While tool names follow verb-noun convention (agent list, nodes discover, party start), descriptions are present but often too brief (10-30 chars) and lack actionable context for LLM selection. Input schemas are visible in the metadata but lack depth: most parameters omit type constraints (enums, ranges), and several tools have empty input schemas (context build-llm, party list). No output schemas are documented anywhere. Error handling is absent, no guidance on recovery, retryable vs fatal errors, or invalid input hints. The tool descriptions do not clearly state WHAT each tool returns or WHEN to use it vs similar tools. Composition is reasonable (tools are single-purpose), but tool chaining is unclear because output fields are undocumented. Security review: no credentials are exposed as parameters, but no audit logging, permission gates, or scope declarations are visible. Overall, the server reads as a CLI wrapper elevated to MCP without the careful schema and error design required for robust agent integration.
List all available agents
Load an agent persona
Display agent menu and commands
Find the best agent for a given task
Build LLM context file with all framework documentation
Generate project context from template
Initialize new n8n-BMAD project structure and configuration
Fetch installed nodes from n8n instance and cache results
Empty input schemas: 'context build-llm' and 'party list' declare empty input objects ({}), violating JSON Schema completeness and leaving LLMs unable to infer whether parameters are expected.
Descriptions too brief and lack WHEN/WHY context: 'party list' is described as 'List all available party modes' (30 chars), falling below the 50-char baseline. Similar brevity across 'party describe' (35 chars) and 'agent menu' (35 chars). These do not explain when to call these tools instead of alternatives, what data they return, or any prerequisites.
No output schemas documented: None of the 14 tools declare their return types. LLMs cannot plan downstream tool calls or extract chaining IDs (e.g., after 'agent load', what fields does the response contain? Can the result be passed to 'agent route'?). This breaks tool composition.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | <=2025-11-25 | v2 |
List cached installed nodes
Search installed nodes by keyword
Show cache status and statistics
Describe a specific party mode
List all available party modes
Start a party session
Parameters lack type validation constraints: Input schemas define string and boolean types, but no enums for closed-ended values. E.g., 'nodes list' type param accepts 'core, community, custom, all' but is not declared as an enum. 'agent list' format param accepts 'table, json, simple' but no enum constraint. LLMs will hallucinate invalid values.
No error handling or recovery guidance: Tools have no documented error responses, retryability classification, or actionable error messages. E.g., if 'agent load' receives an invalid agentId, what happens? Is it retryable? Should the LLM call 'agent list' first? No guidance.
Destructive tools lack confirmation pattern: 'context generate', 'init', and 'context build-llm' are WRITE operations that modify or generate files, yet have no dry-run mode, confirmation step, or rollback capability documented. Agents cannot safely test these operations.
Parameter descriptions are generic and lack format constraints: E.g., 'profile' in 'context generate' is described as 'Scale profile (auto or custom)' but does not declare the enum {auto, custom}. 'query' in 'agent route' is 'Task or query description' with no length or format guidance. Descriptions should state exact valid values, ranges, and formats.
Tool names lack noun specificity in agent family: 'agent list', 'agent load', 'agent menu', 'agent route' are all agent-related, but 'agent menu' and 'agent load' have subtle semantic overlap. 'agent menu' displays commands for an agent; 'agent load' loads an agent persona, these should be more distinctly named (e.g., 'agent get_menu' vs 'agent get_persona') or have clearer descriptions explaining when to use each.