Loading ToolBench
Turn natural-language ideas into validated, imported, and tested Dify workflows through MCP.
16 tools with consistent verb-noun naming (dify_*) and complete Zod schemas. All tools have descriptions (avg 95 chars, within 10-1024 range). Parameters are well-typed with enums where appropriate (e.g., indexing_technique, doc_form, model_type). However, descriptions are terse and lack WHEN/WHY context. Parameter descriptions are minimal (avg 40 chars vs 72 baseline). No output schema documentation. Error handling is absent, no recovery guidance, no actionable error messages. Missing idempotency hints for destructive ops (delete_app). No permission gates documented. Composition is sound (single responsibility per tool), but chaining IDs are not always returned (e.g., dify_create_dataset returns only dataset_id, not workspace context needed for follow-up calls).
Create an empty Dify knowledge base and return its dataset id.
Upload a local document and index it in an existing Dify knowledge base.
Create and index a Dify knowledge-base document directly from UTF-8 text.
Delete a Dify app by id or exact name.
Read the draft workflow graph for an app.
Import a Dify DSL YAML file, optionally overwriting an existing app by app id.
No output schema documentation. Tools return JSON via asText() wrapper, but LLMs cannot see what fields to expect. Breaks downstream tool chaining and forces agents to guess response structure.
Descriptions lack WHEN/WHY context. 'List Dify apps' does not explain when to call this vs dify_get_draft or dify_open_app. Avg description 95 chars vs 194 baseline. LLMs cannot disambiguate similar tools.
No error handling or recovery guidance. Tools return raw JSON errors with no actionable next steps. E.g., dify_delete_app has no confirmation step or dry-run mode for an irreversible operation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
List Dify apps visible in the current workspace.
List Dify knowledge bases/datasets visible in the current workspace.
List model providers and available models in the current Dify workspace.
Open a persistent browser profile for signing in to Dify. Use this once per machine or when the session expires.
Open or refresh a Dify app page in the shared browser so the user can inspect/use it.
Render a strict Workflow IR JSON object into a Dify DSL YAML file and run local static validation.
Run a draft workflow with input variables and return parsed workflow events and outputs.
Check whether Dify is reachable and the persistent browser session is authenticated.
Run multiple draft workflow test cases and evaluate expected status/outputs.
Validate a local Dify DSL YAML file before importing it.
Parameter descriptions are minimal (avg 40 chars). E.g., 'Optional fuzzy name filter' lacks format/length constraints. 'Workflow IR object' does not explain structure. LLMs cannot validate inputs before calling.
dify_delete_app lacks permission gates and confirmation. No audit trail or dry-run. Destructive operations should require explicit user confirmation or permission checks.