Loading ToolBench
Open source AI workflow orchestration platform with MCP server support for tool execution, workflow management, adapter integration, and intelligent assistant capabilities
AICtrlNet provides 14 tools with structured schemas and descriptions. Strengths: all tools have descriptions (avg ~120 chars), input schemas are present with type definitions, tool names follow verb_noun conventions, and there is thoughtful inclusion of safety features like dry_run and idempotency_key. Weaknesses: descriptions are generic and lack LLM-optimized guidance on WHEN to use tools vs alternatives; many parameter descriptions are minimal (e.g., 'Optional input data' in execute_workflow lacks format hints); no documented output schemas; error handling is mentioned as a feature but not evident in tool definitions; parameter constraints are underspecified (e.g., 'limit' has defaults but no min/max bounds stated in descriptions); no tool annotations (readOnlyHint, destructiveHint, idempotentHint); composition reveals overlapping tools (create_workflow and nl_to_workflow both generate workflows, differing only in explicit NL->plan output shape) without clear guidance on which to prefer.
Analyze the intent of a piece of text without creating a workflow.
Assess the quality of content (text, JSON, or code) across dimensions: accuracy, completeness, relevance, clarity, consistency.
Create a new workflow from a natural language description. Supports AI processing nodes, human approval steps, data sources, notifications, and conditional branching.
Execute an existing workflow with optional input data. Returns the execution ID for status tracking. Set dry_run=true to simulate execution without side effects — nodes that would touch external systems (adapters, notifications, browser, approvals) return simulated results, and the response includes dry_run_source.
Get details of a single adapter definition by id.
Missing output/return schemas for all tools. Descriptions mention what tools return (e.g., 'execution ID', 'assistant's reply', 'workflow definitions') but formal JSON Schema for response objects is not documented. This forces LLMs to infer return structure and plan downstream tool calls blindly.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The protocol supports these but they are absent. execute_workflow and create_workflow are destructive/write operations; test_adapter_config and all list_* tools are read-only. Adding annotations would help LLMs reason about safety and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 76 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
Check the status of a running or completed workflow execution.
Get details of a specific workflow including its definition, nodes, and status.
List platform-adapter definitions available for this edition. Adapters unlock entire ecosystems (n8n, Zapier, Make, IFTTT, Power Automate, SaaS APIs) through pre-built, governed integrations.
List the caller's saved adapter configurations.
Browse available workflow templates. AICtrlNet provides templates for common patterns like data pipelines, approval flows, and AI processing chains.
List existing workflows (newest first) with their status and name. Use 'q' to find a workflow by name.
Convert a natural-language description into an AICtrlNet workflow (returns the created workflow's id + node plan). Same service that powers create_workflow but with the explicit NL->plan shape.
Send a message to the AICtrlNet intelligent assistant. Automatically manages conversation sessions. Returns the assistant's reply with suggested actions.
Dry-run an adapter configuration (no side effects). Verifies credentials + reachability + quota. Safe to run anytime.
Overlapping tool responsibilities without clear differentiation. create_workflow and nl_to_workflow both generate workflows from NL descriptions. The only stated difference is that nl_to_workflow 'returns the created workflow's id + node plan' with 'explicit NL->plan shape', but this is vague. analyze_intent and nl_to_workflow both accept 'text' with similar intent analysis. Descriptions lack guidance on which tool to call in each scenario.
Parameter descriptions lack actionable constraint details. Many parameters have minimal descriptions that do not specify format, range, or allowed values in prose. E.g., 'limit' defaults to 20 but no min/max is stated in descriptions; 'input_data' is 'Optional input data' with no format hint; 'category' and 'search' in list_adapters are undescribed or under-described. LLMs cannot infer valid inputs from these alone.
Tool descriptions are too generic and do not guide LLM selection. Many descriptions are terse and do not answer: WHEN to use this tool instead of a similar one? E.g., get_adapter vs get_workflow both retrieve details; get_execution_status description does not hint at polling strategy or expected status values; assess_quality description does not explain what use case it serves in the workflow design/execution context.
No error handling guidance in tool definitions. Tool descriptions do not hint at recovery paths. E.g., get_workflow does not say what happens if workflow_id is invalid; list_templates does not explain behavior if category filter matches nothing; execute_workflow does not document possible failure modes (e.g., insufficient permissions, invalid input_data schema). Without this, LLMs cannot self-correct on failures.
Inconsistent idempotency semantics. execute_workflow mentions '24h' idempotency window with idempotency_key, but create_workflow and nl_to_workflow do not document idempotency guarantees despite both accepting idempotency_key (nl_to_workflow shows it in schema). This inconsistency may lead agents to assume all three are idempotent when they are not.
Parameter 'context' in nl_to_workflow is marked optional with no schema or description. It is unclear what structure this object should have, what keys are expected, or what data it should contain. This invites invalid calls.