Loading ToolBench
GoCD MCP demonstrates solid tool design with 18 well-named, verb-prefixed tools covering pipeline, stage, and job operations. All tools have descriptions (avg 180 chars, within 10-1024 baseline) and input schemas with typed parameters. Strengths: clear action verbs (list_, get_, trigger_, cancel_, parse_), comprehensive parameter descriptions, and logical composition (e.g., parse_gocd_url → analyze_job_failures chain). Weaknesses: output schemas not documented in source; error handling guidance minimal; no tool annotations (readOnlyHint/destructiveHint); some parameter descriptions lack format/constraint details (e.g., pageSize lacks min/max bounds); no batch variants despite agents likely calling tools in loops.
Comprehensive analysis of all failures and errors for a job. Use this when asked to 'get errors', 'analyze failures', 'what went wrong', 'why did this fail', or 'show me the problems'. Automatically finds JUnit test reports and extracts test failures with error messages and stack traces, plus checks console logs for build errors. This is the recommended tool for failure analysis.
Cancel a running stage and all its jobs immediately. Use this to stop a long-running stage, abort a deployment that's going wrong, or cancel jobs that are stuck or no longer needed. All running jobs in the stage will be terminated.
Download and read a specific artifact file from a job. Use this to retrieve specific files like test reports, coverage data, configuration files, or any other build artifact when you know the exact path. For test reports, consider using parse_junit_xml instead for structured output.
Get the complete console log output for a specific job run. Use this to see build logs, compilation errors, runtime errors, stack traces, or any output written to stdout/stderr during job execution. Essential for debugging build failures and understanding what happened during execution.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'shows run numbers, results, stage information') but formal output schema definitions are absent from source. LLMs cannot plan downstream tool calls or extract fields reliably without documented return types.
Pagination parameters lack bounds. pageSize and after parameters have no min/max constraints documented. Unbounded numeric parameters let LLMs pass absurd values (e.g., pageSize=999999) that break APIs or cause timeouts.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Risk levels are documented in the spec (READ_ONLY, WRITE, DESTRUCTIVE) but not exposed via MCP tool annotations. Agents cannot automatically determine which tools are safe to retry or require confirmation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | <=2025-11-25 | v2 |
Get the execution history of a specific job across multiple pipeline runs. Use this to see historical trends, past runs, or to find a specific job instance.
Get details of a specific job run including state (Scheduled, Building, Completed), result (Passed, Failed, Cancelled), agent information, and timestamps. Use this to check job status or get basic job information without downloading logs or artifacts.
Get the run history of a pipeline with pagination support. Use this to see recent pipeline runs, find the latest run, check historical results, or identify patterns in failures. Shows run numbers (counters), results, and stage information for each run. Essential for finding a specific pipeline run to investigate.
Get comprehensive details of a specific pipeline run including build cause (what triggered it), materials (git commits, dependencies), and all stages with their status. Use this to understand why a pipeline ran, what code was built, or see the full pipeline execution details. Essential for investigating a specific run.
Get the current status of a pipeline including pause state (paused or not), lock status (locked by another run), and schedulability (can it run now). Use this to check if a pipeline is currently running, why it's not running, or if it's paused. Quick status check without full history.
Get details of a specific stage run including all jobs, their states (Scheduled, Building, Completed), results (Passed, Failed), and approval information. Use this to see which jobs failed in a stage, check stage status, or understand the overall stage execution. Essential for identifying which job to investigate when a stage fails.
List all artifacts (files and folders) produced by a job, including test reports (JUnit XML), coverage reports, build outputs, and logs. Use this to discover what files are available before downloading specific artifacts. Essential first step when looking for test results or build artifacts.
List all pipelines in the GoCD server with their groups and pause status. Use this to discover available pipelines, check which pipelines are paused, or browse the pipeline catalog. Good starting point when you don't know the exact pipeline name.
Parse a GoCD URL to extract pipeline, stage, and job information. Use this FIRST when the user provides a GoCD URL (e.g., from their browser) before calling other tools. Supports job detail URLs, stage URLs, and pipeline URLs.
Parse a JUnit XML test report to extract structured test results, failures, and errors. Use this when analyzing test failures, understanding which tests failed, or getting detailed error messages and stack traces from test runs.
Pause a pipeline to prevent automatic scheduling and triggering. Use this to temporarily disable a pipeline during maintenance, stop automatic deployments, or prevent a problematic pipeline from running. Paused pipelines won't run automatically but can still be manually triggered. Can include a reason for the pause.
Schedule and trigger a new pipeline run immediately, optionally with custom environment variables. Use this to manually start a pipeline, trigger a deployment, or run a pipeline with specific configuration. Can pass environment variables to customize the run behavior. Note: Pipeline must not be paused.
Manually trigger or rerun a specific stage in a pipeline. Use this to retry a failed stage, run a manual approval stage, or trigger a stage that requires manual intervention. Common for deployment stages or stages with manual approval gates.
Unpause a previously paused pipeline to resume automatic scheduling and triggering. Use this to re-enable a pipeline after maintenance, restore normal operations, or allow automatic runs to resume. The pipeline will immediately become eligible for automatic triggering based on its material changes.
Error handling lacks recovery guidance. Server returns errors (e.g., UNAUTHORIZED in src/server.ts) but does not guide LLMs on next steps. Missing pattern: 'User not found. Try search_users() with a partial name.' Bare error codes force agents to guess.
No batch variants. Agents likely call tools in loops (e.g., trigger_stage for multiple stages). Single-item tools waste tokens and latency vs batch operations. Consider add_labels(array) vs add_label(single).