Loading ToolBench
MCP server for Argo Workflows providing AI tool access to workflow operations
The server provides 2 tools with basic schemas and descriptions, but falls significantly short of production quality standards. Tool descriptions are present but lack depth and actionable context. Parameter descriptions are minimal (1-3 words). No output schema documentation is visible. Error handling guidance is absent. The schemas are present but sparse, parameter types are defined, but descriptions lack the detail needed for LLM reasoning. No tool annotations (readOnlyHint, idempotentHint) are used despite both tools being read-only. The tools follow basic verb_noun naming (get_, list_) but lack the rich context production tools require for reliable agent invocation.
Get a specific workflow by name and namespace
List workflows in a namespace with optional filtering by status and labels
Output schemas completely undocumented. Neither tool describes what fields are returned, their types, or how downstream tools can use the results. LLMs cannot plan multi-step workflows without knowing what data they receive.
Parameter descriptions are minimal (1-3 words). 'Kubernetes namespace to list workflows from (empty string lists all namespaces)' for list_workflows.namespace is the longest; most are bare noun phrases. LLMs need actionable descriptions explaining what happens with different values and when to use them.
No error handling guidance. Tools do not document what errors can occur (workflow not found, namespace not found, permission denied), what fields are returned in errors, or how the LLM should recover (retry, ask user, etc.).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
No tool annotations present. Both tools are marked read-only, but readOnlyHint is not used in the schema. This forces LLMs to infer safety from the tool name alone, increasing hallucination risk when similar tool names exist.
get_workflow accepts 'name' as a string but does not document whether it expects a workflow name, UID, or other identifier. Users may pass 'my-workflow-123' or 'workflow-id-abc'; without clarification, the LLM guesses.
list_workflows.status is an array but lacks enum values. The description says 'e.g. Running, Succeeded, Failed, Pending' but does not formalize these as enums. LLMs will hallucinate statuses like 'pending-approval' or 'in_progress' that may not exist.
list_workflows.limit is unbounded. No minimum/maximum documented. An LLM could pass limit=999999, causing resource exhaustion or API errors. Baselines show numeric parameters should have explicit min/max (e.g. 1 - 100).
No tool composition guidance. The server offers only read tools (get, list), no create, update, delete, or submit operations. For an Argo Workflows server, this is severely limiting. Agents cannot trigger workflows, resubmit failures, or manage pipeline state.