Loading ToolBench
Zyk MCP has 13 tools with explicit schemas and descriptions visible in source. However, critical gaps limit production readiness: (1) descriptions are verbose (200-400+ chars) with embedded code examples that waste tokens and risk LLM literal reuse; (2) parameter descriptions are minimal or absent (e.g., 'input' in run_workflow has only 'Input parameters for the workflow execution', no format/structure guidance); (3) no output schemas documented, LLMs cannot predict response structure for chaining; (4) error handling is absent, no recovery guidance, retryability classification, or actionable error messages; (5) no pagination support on list_* tools despite potentially large result sets; (6) destructive operations (delete_workflow) lack confirmation/dry-run patterns. Tool naming is clear (verb_noun convention), but composition issues exist: create_workflow + review_workflow could be unified; get_tasks + respond_task form a tight pair but lack context about task structure.
Create and register a new durable workflow in Hatchet. Handles clarification of business-level details, generates TypeScript workflow code, and registers it with the Hatchet workflow engine. Supports both native dashboard interactions and Slack button interactions for human-in-the-loop workflows.
Delete a registered workflow from Hatchet. This removes the workflow definition and all associated runs.
Get the current status and details of a workflow run. Returns execution state, step progress, and any errors.
List all pending tasks waiting for user interaction in the dashboard. Returns task IDs, workflow names, and prompts.
Retrieve the full definition and code of a registered workflow.
List available example workflows that can be used as templates. Returns example names and descriptions.
Output schemas not documented. LLMs cannot predict response structure (fields, types, nested objects) for downstream tool chaining. E.g., list_workflows returns 'workflow names, descriptions, and metadata' but no schema showing exact field names or types.
Descriptions are verbose (200-400+ chars) with embedded TypeScript code examples. LLMs tend to reuse example values literally (e.g., 'my-workflow', 'question-123') in real calls, causing failures. Code examples should be in separate documentation, not tool descriptions.
Parameter descriptions are minimal or generic. 'input' in run_workflow is described as 'Input parameters for the workflow execution', no guidance on expected structure, required fields, or format. 'workflowCode' lacks validation rules (syntax, dependencies, length limits).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
List workflow runs with optional filtering by workflow name or status. Returns run IDs, statuses, and timestamps.
List all registered workflows in Hatchet. Returns workflow names, descriptions, and metadata.
Submit a response to a pending task waiting for user input. Resumes the workflow with the provided answer.
Review and validate workflow code before creation. Checks for syntax errors, missing dependencies, and best practice violations.
Trigger execution of a registered workflow with optional input parameters. Starts a new workflow run in Hatchet and returns the run ID for tracking.
Update an existing workflow definition in Hatchet. Replaces the workflow code and re-registers it.
Load and instantiate an example workflow. Creates a new workflow based on the selected example template.
No error handling or recovery guidance. Tools lack actionable error messages. E.g., if delete_workflow fails because the workflow is in use, the LLM receives no guidance on what to do next (retry? check status? ask user?). No retryability classification.
Destructive operations lack confirmation/dry-run patterns. delete_workflow and update_workflow can irreversibly modify or remove workflows with no confirmation step. Agents make mistakes, a dry-run or explicit confirmation prevents catastrophic errors.