Loading ToolBench
A universal multi-bridge MCP hub — connect any LLM to n8n, Blender, Notion and more through a single pedagogical gateway.
polybridge-mcp defines 17 tools across 4 bridges (Blender, filesystem, n8n, Notion). Tool names follow verb_noun convention (create, apply, render, list, read, write, delete, execute, activate, append). Descriptions are present and moderately detailed (avg ~120 chars). Input schemas are visible and properly typed with enums where appropriate. However, several critical gaps reduce quality: (1) output schemas are NOT documented, LLMs cannot predict response structure for chaining; (2) parameter descriptions lack actionable constraints (ranges, formats, dependencies); (3) error handling is minimal, no recovery guidance or categorization; (4) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels; (5) some descriptions are generic ('Use for advanced operations') rather than LLM-optimized. Filesystem and n8n tools are well-named but lack depth. Blender tools are domain-specific but descriptions omit prerequisites (e.g., 'Blender must be running with polybridge addon enabled').
Apply a material (color and basic surface properties) to an existing object.
Create a new 3D object in the current Blender scene.
Execute an arbitrary Blender Python script. Use for advanced operations not covered by other tools.
Return a list of all objects currently in the Blender scene.
Render the current Blender scene and return the result as a base64 PNG image.
Delete a file. This action is irreversible.
Output schemas not documented. LLMs cannot predict response structure (fields, types, nested objects) for downstream tool chaining. E.g., blender_list_objects returns a list but structure is unknown; n8n_get_execution returns execution data but fields are undocumented.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. fs_delete_file is marked DESTRUCTIVE but lacks annotation; blender_execute_script is IRREVERSIBLE but unmarked. Agents cannot distinguish safe retries from dangerous operations.
Parameter descriptions lack actionable constraints. E.g., blender_create_object location/scale are arrays but no min/max bounds stated; n8n_execute_workflow inputData is 'optional JSON' but no schema or example provided; fs_read_file filePath has no length limit or character restrictions documented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
List all files and subdirectories inside a directory.
Read the contents of a file. Only files inside the configured allowed directories can be read.
Write content to a file. Creates the file if it does not exist, overwrites if it does.
Enable or disable an n8n workflow.
Execute a specific n8n workflow by its ID. Optionally pass input data to the workflow.
Get the result and status of a workflow execution by its execution ID.
List all workflows in the n8n instance with their names, IDs, and active status.
Append a text paragraph to an existing Notion page.
Create a new Notion page inside a parent page or database.
Read the title and text content of a Notion page.
List all available bridges and their connection status.
Error handling is minimal. No recovery guidance or error categorization. E.g., blender_execute_script description says 'Use for advanced operations' but does not explain what happens on syntax error, timeout, or permission denial. Agents have no guidance on retry vs. user-fixable vs. fatal.
Descriptions lack LLM-optimized context. blender_execute_script ('Execute an arbitrary Blender Python script') does not state prerequisites (Blender running, addon enabled) or when to use it vs. other Blender tools. Descriptions should answer WHAT, WHEN, and WHY.