Loading ToolBench
Model Context Protocol (MCP) server for Alteryx Server providing tools for CRUD operations on workflows, collections, users, jobs, connections and credentials
The server provides 22 well-structured tools with consistent naming conventions starting with action verbs (get_, create_, delete_, update_, add_, remove_). All tools have basic descriptions and input schemas are present and mostly complete. However, descriptions are often too brief (10-30 chars), parameter descriptions lack detail about constraints and formats, and output schemas are not documented. Error handling returns basic error strings without recovery guidance. The tool set covers collections, workflows, users, and jobs in a coherent Alteryx domain model, but lacks intermediate-level quality markers like pagination hints, output field documentation, or idempotency guidance.
Add a schedule to a collection by its ID
Add a workflow to a collection by its ID
Create a new collection
Delete a collection by its ID
Download a workflow package file by its ID and save it to the local directory
Execute a workflow by its ID and monitor its execution status. This call will return a jobID, he Job status and the job details once the execution is completed or failed. The input data parameter is a list of name-value pairs, each containing a name and value.
Tool descriptions are universally too brief (10-45 chars). The rubric baseline for A+ tools is 50-200 chars with context about WHEN to use the tool, WHAT it returns, and prerequisites. Current descriptions like 'Get a collection by its ID' lack this guidance and force LLMs to infer behavior. This violates pattern:tool-description.
Parameter descriptions are missing or generic. The 'collection_id' parameter appears in 9+ tools with identical minimal description 'The ID of the collection...'. Per the rubric, descriptions should explain format/constraints: e.g. 'The UUID of the collection (required, alphanumeric)'. No mention of whether IDs must be uppercase, what happens if invalid, or how to discover valid IDs. This violates pattern:tool-description and pattern:constrained-input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 72 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Get the list of all collections of the Alteryx server
Get the list of all users of the Alteryx server
Get the list of all workflows of the Alteryx server
Get a collection by its ID
Get a user by their email
Get a user by their ID
Get a workflow by its ID
Get all jobs associated with a workflow
Get the list of tools in a workflow by the workflow ID
Get the XML representation of a workflow file by its ID
Remove a schedule from a collection by its ID
Remove a workflow from a collection by its ID
Start a workflow execution by its ID and return the job ID. This will create a new job and add it to the execution queue. This call will return a job ID that can be used to get the job details later. The input data is a list of name-value pairs, each containing a name and value.
Transfer workflow ownership to a new user
Update a collection name or owner by its ID
Update a workflow name or comment by its ID
No output schemas documented. The rubric (pattern:tool and baselines) requires every tool to document return types so LLMs can plan downstream tool calls and extract the right data. Source code shows tools return pprint.pformat(api_response), a string representation of an object. LLMs cannot parse this reliably. Expected: structured JSON with typed fields documenting what fields are present (e.g. { id: string, name: string, owner_id: string }).
Error handling returns raw error strings ('Error: {e}') without recovery guidance. Per pattern:recovery-guide, errors should tell the LLM what to do next: 'User not found. Try search_users() with a partial name.' Current implementation provides no actionable next steps, forcing the agent to guess or retry blindly.
No pagination support on list tools (get_all_collections, get_all_workflows, get_all_users). Per pattern:paginated-result, tools returning lists MUST support limit/offset or cursor parameters and return total counts. Without pagination, large result sets blow context windows. Baseline from 549 production tools: list tools that lack pagination score <50.
Compound tool names ('update_collection_name_or_owner', 'update_workflow_name_or_comment') violate the single-responsibility principle. Per pattern:tool, a tool name containing 'and' or 'or' signals multiple responsibilities. These should be split: update_collection_name + update_collection_owner, and update_workflow_name + update_workflow_comment. This enables the agent to compose smaller, focused operations and provides clearer idempotency semantics.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared. Per the MCP spec and pattern guidelines, tools that delete or modify state should declare destructiveHint=true; read-only tools should declare readOnlyHint=true. This metadata helps agents reason about side effects and retry behavior. The source declares Risk levels but these are not exposed to the MCP client.
Missing input validation and constraint documentation. Parameters like 'output_directory' (download_workflow_package_file) and 'name' (create_collection) have no documented constraints. Rubric requires: min/max for numeric params, length limits, character restrictions, format requirements. Example: name could be enforced as 1-256 chars, no leading/trailing whitespace.
Execution tools (start_workflow_execution, execute_workflow_with_monitoring) lack confirmation/dry-run capability. Per pattern:confirmation-request, irreversible operations should support a confirmation step or dry-run mode. Agents make mistakes, no safeguard exists before executing a potentially long-running, resource-intensive workflow.
No idempotency guidance for create/update operations. Per pattern:idempotent-operation, repeated calls with identical inputs should produce the same result. create_collection and update_collection operations provide no idempotency key or conflict-handling strategy. If an agent retries a failed create_collection call, will it create a duplicate? Documentation is silent.