Loading ToolBench
Agent automation framework with native MCP support and direct SDK integration. Open-source AI workflow automation with tool calling, 38 integrations, and local LLM support — workflows are just markdown files
marktoflow exposes 8 tools for workflow orchestration (logging, file I/O, output control, timing). While all tools have basic descriptions and input schemas, the definitions exhibit several critical gaps: (1) Parameter descriptions are minimal or absent for key inputs; (2) Schemas lack detail on constraints, formats, and enums; (3) Output schemas are not documented; (4) Error handling guidance is minimal; (5) Naming conventions are inconsistent (core.log vs workflow.log as aliases; workflow.set_outputs lacks clear input structure). The tool set is focused on utility operations rather than domain-specific actions, limiting composition patterns. Per-tool analysis shows most tools score 35-50, with no tool exceeding 55.
Log a message during workflow execution
Write content to a file
Fail the workflow with an error message
Log a message (alias for core.log)
No-op action (useful for testing or placeholders)
Set workflow output variables that can be accessed by the caller or displayed at the end of execution
Sleep for a specified duration
Create a timestamp
workflow.set_outputs has empty input schema ({}). No parameters documented, making it impossible for LLMs to infer what data structure to pass. Tool is opaque and unusable.
No output schemas documented for any tool. LLMs cannot determine what fields to expect in responses, preventing downstream tool composition and data extraction planning.
Enumerated parameters (level in core.log, format in workflow.timestamp) are documented only as text descriptions, not as formal enum constraints in JSON Schema. LLMs may pass invalid values like 'debug' or 'rfc3339'.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Tool duplication: core.log and workflow.log are aliases with identical functionality but inconsistent parameter order (core: level, message, metadata; workflow: message, level, metadata). This forces LLMs to waste reasoning cycles deciding between identical tools and risks parameter order errors.
Numeric parameter 'duration' in workflow.sleep lacks min/max bounds. LLMs may pass negative or absurdly large values (e.g., Number.MAX_SAFE_INTEGER milliseconds) causing unexpected behavior.
core.writeFile lacks guidance on path validation, disk space handling, directory creation, and error modes. No mention of permission checks or path traversal protection (critical for security).
workflow.fail lacks error classification (retryable vs fatal). LLMs cannot determine if they should retry, ask the user for intervention, or treat as unrecoverable.
workflow.noop is a testing placeholder with unclear production value. Including noop in the tool set suggests incomplete/unvetted tool definitions.