Loading ToolBench
Workday Studio MCP server for local file operations, assembly editing, integration planning, and diagnostics
26 tools with mostly complete schemas and descriptions, but significant gaps in error handling, output documentation, and parameter validation. Tool names follow verb_noun convention well (list_, read_, write_, create_, delete_, search_, validate_, parse_, get_, update_). Descriptions average ~120 chars, meeting baseline minimums but lacking LLM-optimized guidance on WHEN to use each tool vs. alternatives. Most parameters have type and description, but many lack constraints (enums, ranges, format specs). Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal; most tools lack recovery guidance. Security concern: parse_server_log accepts arbitrary filesystem paths without validation, risking directory traversal.
Insert a new step into assembly.xml. Optionally wire it after an existing step (updates the predecessor's routes-to automatically). The new step inherits the predecessor's original routes-to as its own routes-to.
Copy a file from one project to another
Create a new Studio project
Create a new XSL transform file in a project
Delete a step from assembly.xml and rewire its predecessor to its successor
Delete a file from a project
Get reference patterns and best practices for integration development
Get detailed reference documentation for a step type
Output schemas not documented. LLMs cannot predict response structure for any of the 26 tools. This forces agents to reason about unknown fields and risks context loss when chaining tools.
parse_server_log accepts arbitrary filesystem paths without validation. Agents could pass '../../../etc/passwd' or similar, risking directory traversal attacks. Input must be validated and restricted to expected log directories.
add_assembly_step 'options' parameter is an untyped object with no schema. Agents cannot know which keys are valid for which step_type. Document as discriminated union: {transform: {xsl_file: string}, http_out: {url: string, method: enum}, ...}.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | <=2025-11-25 | v2 |
Get the current lifecycle state and recommended next steps for an integration
List all steps in an assembly.xml file
List files in a project directory
List all integration parameters defined in assembly.xml
List all Studio projects in the workspace
Record a discovery or decision made during integration development
Look up available SOAP operations for a Workday application
Parses a Workday server log (server-{eventId}.log) and returns a focused summary: integration status, duration, deduplicated errors/warnings, execution timeline, and any XSLT cc:log messages. The raw log is 10-15k lines of framework boilerplate and XML config dumps (which contain plaintext credentials and are never surfaced). This tool extracts the signal and suppresses the noise.
Generate a comprehensive integration plan with design brief, execution chain, sub-flow contracts, and build order
Read a file from a project
Rename a file in a project
Rename one or more steps in assembly.xml and update all references
Search for files matching a pattern in a project
Update a sub-flow (async-mediation + local-out pair) in assembly.xml
Validate assembly.xml against Workday Studio rules and constraints
Validate XML file syntax and structure
Display the workspace directory tree structure
Write or update a file in a project
Destructive tools (delete_file, delete_assembly_step) lack confirmation or dry-run support. Agents can permanently delete without safeguards. Implement confirmation_request pattern or add a 'dry_run' parameter.
Error handling is minimal across all tools. No recovery guidance, no categorization of retryable vs. fatal errors, no actionable error messages. E.g., 'File not found' should suggest 'Try list_files() to see available files.'