Loading ToolBench
强大易用的开源企业级智能体平台 (Powerful and easy-to-use open-source enterprise-level agent platform)
MaxKB exposes 4 tools for workflow execution, but definition quality is severely compromised. Tool names lack clear action verbs (tool-lib-node, tool-node, tool-start-node, tool-workflow-lib-node are all noun-based or hyphenated, violating naming conventions). Descriptions are present but generic and lack context about when/why to use each tool or what side effects occur. Input schemas are partially visible but incomplete: parameter types are declared (uuid, string, boolean, object, array) but lack validation constraints, ranges, format specifications, and many parameters lack descriptions entirely. The input_field_list parameter across multiple tools accepts arbitrary objects with minimal guidance. No output schemas are documented. Error handling is absent from visible definitions. The code sample provided is truncated and does not show complete tool implementations or error paths. Most critically, tools appear to execute arbitrary Python code (tool-node) and external tool libraries (tool-lib-node) without documented sandboxing, validation, or permission gates, a critical security gap.
Tool library node for workflow execution - executes external tools/functions from a tool library within a workflow
Direct tool/function node - executes Python code directly within a workflow with input parameters
Tool workflow start node - initializes workflow execution with user input fields and default values
Tool workflow library node - executes another published tool workflow as a node within a parent workflow
Tool names violate verb-noun convention. All four tools use noun-based or hyphenated names (tool-lib-node, tool-node, tool-start-node, tool-workflow-lib-node) instead of action verbs (execute_tool_from_library, execute_python_code, initialize_workflow, execute_workflow). LLMs rely on verb prefixes to parse intent.
No input validation constraints documented. Parameters like 'code' (tool-node), 'type' (tool-workflow-lib-node), and 'source' accept free-form strings. No enums, regex patterns, length limits, or ranges specified. LLMs will hallucinate invalid values.
No output schemas documented for any tool. LLMs cannot predict what fields to expect after execution, blocking downstream tool chaining and forcing re-discovery calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 22 | 2025-06-18+ | v1 |
CRITICAL SECURITY: tool-node accepts arbitrary Python code execution with no visible sandboxing, permission model, or input validation. No mention of what libraries are available, timeout limits, resource caps, or how exceptions are handled. This is a severe attack surface.
Many parameters lack descriptions. For example, input_field_list items (name, type, source, value) in tool-node have minimal guidance. LLMs cannot infer what 'source: custom' vs 'source: reference' means or what format 'value' should take.
No error handling guidance. Descriptions do not indicate what happens when tool execution fails, how to retry, or what the LLM should do next. No error classification (retryable, user-fixable, fatal).
tool-start-node has no visible input/output schema in the provided source code. Input structure and expected defaults are unknown.