Loading ToolBench
Diagnose your GitHub Actions: flaky jobs and tests, wasted billable minutes, slow steps, cache misses, and workflow anti-patterns — in one command.
gha-doctor presents well-structured tool definitions with comprehensive descriptions (avg 180+ chars) and detailed parameter schemas. All 7 tools have clear verb-noun naming (analyze_repo, lint_repo, etc.) and explicit input schemas with type constraints. However, output schemas are not visible in the provided source code, and error handling guidance is absent. Tool descriptions are domain-specific and actionable but lack explicit recovery hints for failure cases. Parameter descriptions are thorough (e.g., 'Repository as owner/name, e.g. cli/cli'), meeting the 10-1024 char baseline. No security issues detected (no secrets in params). Composition is sound, each tool has a single responsibility and tools chain naturally (e.g., analyze_repo → run_deep_dive). The main gap is missing documented output schemas and error recovery patterns.
Full CI health report for a GitHub repository: static workflow lint, run-history analysis (success/failure rates, flaky jobs, retry waste, superseded PR runs, queue times, duration trends, zombie crons, PR feedback time), cache and artifact checkups, a 0-100 health score, and a ranked, dollar-quantified top-wins list. Makes ~100+ GitHub API calls and typically takes 10-30 seconds. Optionally set flaky_logs to also read N flaky-failure job logs and name the flaky tests (needs a token), or cache_logs to measure the real cache hit rate from N job logs.
Print the documentation for a lint rule: what it checks, why it matters, and how to fix it. Pass the rule ID (e.g. D004).
Static lint of GitHub Actions workflows and action manifests only (no run history, fast): 21 rules covering missing timeouts, no concurrency cancellation, dead action versions, retired runner labels, deprecated workflow commands, unguarded crons, and more. Pass repo to lint any GitHub repository via the API (no clone needed), or dir for a local checkout (offline). Defaults to the current directory.
Fleet triage across an organization's (or user's) most recently pushed repositories: per-repo run counts, failure rates, median duration, compute minutes, last-run age, and fleet-wide zombie crons (scheduled workflows failing on repeat), one API call per repo. Useful for finding which repository's CI to look at first.
Output schemas not documented in source. LLMs cannot plan downstream tool calls or extract structured data without knowing what fields to expect from each tool.
Error handling lacks recovery guidance. Tool descriptions do not specify what errors are retryable, user-fixable, or fatal, or what the LLM should do next on failure.
Parameter 'runs' in analyze_repo lacks guidance on when to use non-default values. Description should explain trade-offs: larger samples = more accurate but slower (10-30s baseline).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Diagnose a pull request's CI: every workflow run on the PR's head commit, how long the PR waited for a verdict, re-run smells, and a full deep dive into the latest failed run — failing job and step, named failing tests (30+ frameworks recognized), and the failing step's log tail. The natural first call when someone asks why CI is failing or slow on their PR.
Preview the exact unified diff that gha-doctor --fix would apply for auto-fixable findings (10 of 21 rules), without writing anything. Pass repo for any GitHub repository (no clone needed) or dir for a local checkout. To actually apply fixes, run `gha-doctor --fix` in the repository — this MCP server never writes.
Deep-dive one workflow run: why was it slow, or why did it fail? Job waterfall (queue vs execution), every job and step compared against the workflow's own recent medians, named step regressions; failed runs lead with the failing job and step, name the failing tests (30+ test frameworks recognized), and inline the failing step's log tail (needs a token).
Mutually exclusive parameters not explicitly documented. analyze_repo accepts both 'repo' and 'dir' (mutually exclusive per description), but lint_repo and preview_fixes also have this pattern, should be stated in each parameter description.
No pagination or result-limiting guidance. org_overview returns per-repo stats but does not document max result count or whether results are sorted/paginated.