Loading ToolBench
MCP server for exposing conductor endpoints. Provides tools and resources for managing Conductor workflows, tasks, and events.
Conductor MCP presents a moderate-quality tool definition set. All 8 tools have basic descriptions (10-200 chars range) and explicit input schemas with typed parameters. However, output schemas are undocumented, error handling guidance is absent, and parameter descriptions lack depth. Tool naming follows verb_noun conventions well (get_, update_, create_). The main gaps are: (1) no documented output schema for any tool, (2) minimal parameter context (e.g., task_id/workflow_instance_id lack format guidance), (3) no error recovery guidance, (4) missing chaining IDs in responses, and (5) no idempotency hints for write operations. This server lands in the 'Fair' (60-69) tier, definitions are present but lack the LLM-optimization depth needed for 70+.
Creates or updates a task definition. The task definition should include at minimum: name, description, retryCount, timeoutSeconds, responseTimeoutSeconds.
Gets all task definitions
Gets all event handlers or filters by event name and active status. Event handlers define how Conductor responds to external events. They can trigger workflow executions or perform other actions when specific events occur.
Gets the metadata for a conductor workflow task in json format based on that task's id
Gets the task definition for the given taskType. "taskType" is synonymous with "task name". This API refers to only user-defined tasks.
Gets execution logs for a specific task. Returns log entries generated during task execution.
No documented output schemas for any tool. LLMs cannot plan downstream calls or extract fields without knowing what each tool returns. Pattern baseline 100% of A+ tools document return types.
Parameter descriptions lack actionable detail. 'The uuid representing the task id' does not explain format, range, or what happens if invalid. Baselines show effective param descriptions average 72 chars with constraint details.
No error handling guidance. Tools that call external HTTP services (http_get, http_post) can fail with network errors, auth failures, or malformed responses. No recovery hints for agents.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Gets the current status details for all conductor workflow task queues
Updates the status of a task execution. This is typically used by workers to update task status.
List/pagination tools (get_all_task_definitions, get_task_queue_details, get_event_handlers) lack limit/offset parameters and return count documentation. Pattern requires pagination support for large result sets.
Write operations (update_task_status, create_task_definition) lack idempotency hints or dry-run confirmation steps. Agents retry failed calls, non-idempotent tools risk duplicate side effects.
create_task_definition accepts an opaque 'task_definition' object with no schema validation or structure hints. Guideline states 'Describe the expected format, range, and allowed values directly in the parameter description.'
HTTP proxy functions (http_get, http_post in conductor_mcp/network/http_proxy.py) expose raw HTTP response text without structure. No response shaping, no field extraction, no error parsing.