Loading ToolBench
MCP server for GitHub Actions workflow inspection, analysis, and management
This is a mature GitHub Actions MCP server with 12 well-defined tools covering workflow management, artifact handling, and CI analysis. Most tools have clear names starting with action verbs (list_, get_, manage_, wait_, analyze_, diagnose_) and comprehensive parameter schemas with type constraints. However, there are gaps: (1) several parameter descriptions are generic or lack concrete guidance, (2) output schemas are not explicitly documented in the tool definitions, (3) some tools lack clear error recovery hints, and (4) parameter interdependencies (e.g., which 'element' values require which other parameters in get_run) are underspecified. The code reveals strong engineering discipline, JSON schema generation is tested and tool registration is rigorous, but descriptions prioritize technical API contracts over LLM-friendly guidance.
Analyze workflow, job, or step durations across recent runs to compare a specific CI run against recent history and surface slow spots.
One-shot diagnosis of a failed workflow run: identifies failed jobs/steps, extracts error lines from logs, and optionally checks for flakiness. Returns a structured diagnosis with actionable error context.
Download a workflow run artifact to disk
Get the contents of a workflow run artifact (stream without downloading to disk)
Get workflow status summary for a commit/branch/tag (derived from workflow runs; no Checks API permission required).
Get workflow run details. Start with element=info, then use jobs/logs/log_sections/artifacts as needed.
get_run tool has complex conditional parameter logic (element enum dispatches to different subsets of parameters: artifact_id for artifact_content, job_id for logs, etc.) but interdependencies are not clearly documented in parameter descriptions. LLMs may pass invalid parameter combinations.
Output schemas are not documented in tool definitions. While parameter input schemas are rigorous (types, descriptions, constraints), the expected output structure for each tool is not specified. LLMs cannot plan downstream tool calls or extract the right fields without knowing return types.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
List workflow runs with comprehensive filtering options
List all workflows available in the repository
Manage a workflow run (cancel, rerun, or rerun failed jobs)
Wait silently for every job in a workflow run to complete, regardless of job status
Wait for all CI check runs for a commit ref (SHA, branch, or tag) to complete.
Wait silently for a workflow run to complete (no output during polling)
Several parameter descriptions are generic or lack actionable guidance. Examples: 'repository owner override' and 'repository name override' do not explain when to use these or what format is expected. 'Maximum time to wait in minutes' does not explain behavior on timeout (does it error? return partial results?). LLMs benefit from concrete format hints and failure mode guidance.
Error handling and recovery guidance is absent from tool descriptions. 'download_artifact' with overwrite=false does not specify what error is returned if the destination exists. 'manage_run' does not document what happens if the run is already completed or if the action is invalid. LLMs need explicit 'what to do if this fails' guidance.
List-returning tools (list_runs, list_workflows) have cursor-based pagination but no 'total_count' or explicit guidance on when to stop paginating. The 'per_page' default is 5; no clear guidance on why small defaults or when to increase them.
get_run 'element' parameter accepts enum values but does not explain the purpose or when to use each one. An LLM must infer that 'info' is the entry point, then 'jobs', 'logs', 'artifacts', etc. are nested fetches. Sequence guidance would improve usability.