Loading ToolBench
MCP server for accessing API.AI workflows, flows, and image generation/editing capabilities
The server implements 7 tools with clear action verbs and documented schemas. Naming follows verb_noun convention (list_workflows, generate_image, edit_image, run_flow, check_balance, get_account). All tools have descriptions ranging from 73-173 characters. Input schemas are properly defined with types and descriptions for all parameters. However, several critical gaps reduce overall quality: (1) Parameter descriptions lack examples of valid enum values and format constraints, e.g., 'workflow' params state 'e.g. create-image' but lack enum declarations; (2) Output schemas are not documented, callers don't know what structure to expect from image generation or account details; (3) Error handling is minimal, no recovery guidance, no categorization of retryable vs. fatal errors; (4) No tool annotations (readOnlyHint, destructiveHint) despite clear risk distinction (3 WRITE tools, 4 READ_ONLY); (5) Parameter 'image_data' vs 'image_path' are mutually exclusive but not documented as such; (6) No documented pagination for list_workflows and list_flows despite potentially large result sets; (7) Response field naming conventions are not validated against parameter expectations. The server is functional but lacks polish expected of production-grade tools.
Check your current account balance.
Edit an existing image using a workflow. Send an image (as base64 or file path) with an optional prompt. Returns the processed image as base64.
Generate an image from a text prompt using a workflow that supports prompts. Returns the image as base64.
Get your account details including email, company, API key, and balance.
List your custom flows (multi-step pipelines). Each flow chains multiple workflows together.
List all available workflows and pipelines you have access to. Returns names, slugs, endpoints, parameters, pricing, and whether prompt is supported.
Output schemas not documented. Callers have no specification of what generate_image, edit_image, run_flow, list_workflows, list_flows, get_account, or check_balance return. LLMs cannot plan downstream calls or extract expected fields without documented return types.
Mutually exclusive parameters (image_data vs image_path in edit_image and run_flow) not documented. LLMs may pass both or neither without explicit constraint guidance. Should state: 'One of image_data or image_path must be provided; if both are given, image_data takes precedence.'
No tool annotations (destructiveHint, readOnlyHint). Tools clearly have different risk profiles: list_*, check_balance, get_account are READ_ONLY; generate_image, edit_image, run_flow are WRITE. Server must annotate these in toolDefinitions to enable agent-level permission checks.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Execute a custom flow (multi-step pipeline). Can generate from prompt or process an existing image through multiple steps.
Parameter descriptions lack format constraints and valid examples. 'workflow' param example 'create-image' is loose; should clarify if this is free-form slug or constrained enum. 'image_data' says 'Base64-encoded image data' but doesn't specify allowed MIME types, max size, or dimensions.
No pagination guidance for list_workflows and list_flows. If either returns dozens of items, response could exceed context window. Should declare: max returned count, whether more pages exist, and pagination parameters (offset/limit or cursor).
Minimal error handling in callToolResult. When API calls fail (see toolListWorkflows, toolEditImage, etc. returning errorResult), responses are bare error strings with no recovery guidance. Should return: error category (retryable? user-fixable?), suggested next action, and available alternatives.
No idempotency guarantees for write operations. generate_image, edit_image, and run_flow modify state but don't declare idempotency behavior. If an agent retries due to network failure, will duplicate images be created or will the operation be deduplicated?