Loading ToolBench
Model Context Protocol (MCP) server for Woodpecker CI. Lets AI assistants like Claude inspect pipelines, workflows, steps and decoded build logs. Zero dependencies, single-file, stdio transport.
Four tools with clear verb-noun naming (list_*, get_*, pipeline_logs). All have input schemas with required fields and descriptions. However, parameter descriptions are minimal (10-30 chars), output schemas are undocumented (responses are free-text summaries, not structured objects), and error handling is generic. No tool annotations. Descriptions are adequate but lack WHEN/WHY guidance. Baseline: avg tool description ~120 chars (below 194 baseline); avg param description ~25 chars (below 72 baseline). No pagination support despite list_pipelines potentially returning many results.
Pipeline details: status plus the workflow/step tree (with step ids for fetching logs). Params: repo_id, number.
Recent pipelines for a repository. Params: repo_id (number), limit (number, default 20).
List repositories the token can access (id, full name, default branch).
Decoded logs for a single step. Params: repo_id, number (pipeline), step_id (from woodpecker_get_pipeline). Optional tail (last N lines).
Output schemas undocumented. All tools return free-text summaries (e.g., 'pipeline #123 status=success') instead of structured JSON objects. LLMs cannot reliably parse or chain results. Violates pattern:response-shaper.
Parameter descriptions are minimal (10-30 chars, well below 72-char baseline). E.g., 'repo_id' has only 'Woodpecker repository ID', no guidance on how to obtain it or what happens if invalid. Violates pattern:tool-description.
No pagination support in list_pipelines despite 'limit' parameter. No 'total', 'next_cursor', or 'has_more' in response. Large repo histories will be truncated silently, and LLM cannot iterate. Violates pattern:paginated-result.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | <=2025-11-25 | v2 |
Error handling is generic. All errors caught in tool.handler() return 'Error: <message>' as plain text. No error classification (retryable vs fatal), no recovery guidance, no invalid-value echoing. Violates pattern:recovery-guide.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are read-only but this is not declared in the schema. Violates current spec (2026-07-28) tool annotation pattern.