Loading ToolBench
Model Context Protocol (MCP) server that exposes the Workato Platform API to Claude Desktop and other MCP clients.
Strong foundation with 14 well-named tools following verb_noun convention (list_, get_, search_, start_, stop_, delete_, force_run_, reset_). All tools have descriptions (avg ~180 chars, within 10-1024 baseline). Input schemas are comprehensive with zod validation and type coercion. However, several parameter descriptions are missing or minimal, and output schemas are not documented. Error handling is basic (no recovery guidance, no error categorization). No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Composition is sound, tools chain well (e.g., search_recipes → get_recipe → start_recipe).
Delete a recipe permanently (DELETE /api/recipes/:id).
Force-run a recipe on demand (POST /api/recipes/:recipe_id/force_run). Rate limit: 1 request per second.
Get details of a single connection by id.
Get details of a single job by id, including its input/output and error trace.
Get full details of a single recipe by id (GET /api/recipes/:id). Returns name, description, code (recipe DSL), config (connections), trigger, running status, job counts, tags, version info, etc. Pass includes=['tags'] to also retrieve the recipe's tag handles.
List connections configured in the account.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., recipe_id from list_recipes for chaining to get_recipe). Every tool should document its response structure.
Destructive tools (delete_recipe) lack confirmation/dry-run pattern and minimal descriptions. delete_recipe description is only 'Delete a recipe permanently (DELETE /api/recipes/:id).', no guidance on consequences or recovery.
Tool annotations missing. No readOnlyHint, destructiveHint, or idempotentHint despite clear risk levels (READ_ONLY, WRITE, DESTRUCTIVE). Agents cannot distinguish safe from dangerous tools without explicit annotations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
List project folders in the account. Folders group recipes and other assets.
List jobs, optionally filtered by recipe_id, status, or date range. Useful for monitoring recipe execution history.
List recipes belonging to the authenticated user (GET /api/recipes). Supports filtering by folder, adapters (connectors), running status, and date range. Results are paginated (default: per_page=100, max 100). Set exclude_code=true to speed up listing for large accounts. Note: The Workato API does NOT support server-side name search. To find recipes by name, use the `search_recipes` tool instead.
Validate Workato credentials and return the current user. Use this first to confirm the connection works.
Reset a recipe trigger cursor (POST /api/recipes/:recipe_id/reset_trigger). Use to re-sync data from the source. Only works with polling and scheduled triggers. The recipe must handle duplicate records.
Search recipes by name (case-insensitive). Since the Workato API has no server-side text search, this tool auto-paginates through all recipes and filters client-side by name. Example: search_recipes({ name: 'PRDI Recipe 04 - PRDI AR DOKU Transactions' })
Start (enable) a recipe (PUT /api/recipes/:id/start).
Stop (disable) a recipe (PUT /api/recipes/:id/stop).
Minimal descriptions on read-only discovery tools (list_jobs, list_connections, list_folders). Descriptions are 30-40 chars, below the 50-200 char LLM-optimized baseline. No guidance on when to call them or what they reveal.
Error handling is generic. No recovery guidance, error categorization, or actionable messages. If a recipe is not found or API rate limit is hit, the LLM receives no guidance on what to do next.