woodpecker-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WOODPECKER_URL | No | URL of a Woodpecker CI instance (single instance configuration). | |
| WOODPECKER_TOKEN | No | Personal access token for the Woodpecker instance (required). | |
| WOODPECKER_SERVER | No | Alternative environment variable for the Woodpecker instance URL (official CLI variable). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_instancesA | Lists the Woodpecker CI instances this server is configured with (name and base URL); every other tool takes one of these names as |
| list_reposA | Lists repositories the instance's token can see, returning id, full_name, default_branch, active and forge_url for each. Active repositories only unless |
| list_pipelinesA | Lists pipelines for one repository, newest first, paged (default 10 per page, max 50). Each entry has number, status, event, branch, first line of the commit message, short commit SHA, author, ISO created time, duration_s and pipeline errors if any; get_pipeline gives the web URL. Filters are passed through to Woodpecker; |
| get_pipelineA | Gets one pipeline by its per-repo number, or the newest one when |
| get_step_logsA | Fetches the log output of one step and returns its last |
| recent_activityA | Lists the most recent pipelines across the repositories the token has push or admin access to, newest first: repo full_name, repo_id, pipeline number, status, event, branch, title, short commit, author, ISO created time and duration_s; get_pipeline gives the web URL. Use it to answer "what is failing / running right now?" without knowing a repo. Woodpecker returns only the 50 newest pipelines; |
| list_branchesA | Lists branch names of a repository as reported by its forge (Gitea, Forgejo, GitHub, GitLab, ...), paged (up to 50 per page). An empty list can also mean the forge does not support listing branches. |
| list_pull_requestsA | Lists open pull requests of a repository as reported by its forge, as index (the PR number) and title, paged (up to 50 per page). To check CI for one, call list_pipelines with event=pull_request and the PR's branch, or get_pipeline with number="latest" and that branch. An empty list can also mean the forge does not support listing pull requests. |
| get_pipeline_configA | Returns the workflow config files (e.g. .woodpecker/*.yaml) exactly as Woodpecker fetched them for one pipeline, as file name plus YAML text. This is the raw config at that commit, before matrix expansion or |
| diagnose_pipelineA | One-call failure triage: fetches a pipeline (by number, or "latest" on the default branch or |
| compare_pipelinesA | Answers "what broke?" on a branch: finds the newest failing pipeline (or |
| list_cronsA | Lists a repository's cron jobs: id, name, schedule, timezone, branch, enabled, next run (ISO) and the names of the variables each sets (not their values). Requires push access to the repository; Woodpecker answers 403 otherwise. Pipelines started by a cron have event "cron". |
| list_secretsA | Lists secret names with the events and plugin images each is available to, and its note. Secret values are never returned. Use it to debug "secret not found" or a secret missing for an event (e.g. pull_request). A pipeline sees repository, organization and global secrets, so check each |
| list_agentsA | Lists the instance's build agents: id, name, platform, backend, capacity, version, whether scheduling is paused (no_schedule), org_id (-1 for global agents), and ISO last contact / last work times. Use it to see whether agents are online when pipelines sit pending. Requires an admin token; Woodpecker answers 403 otherwise. |
| get_queue_infoA | Shows the instance's task queue: whether it is paused, counts of workers and of pending, waiting-on-dependencies and running tasks, and for each task its name, repo_id, pipeline_number, assigned agent and labels. Use it to explain why a pipeline is stuck pending (no matching agent labels, paused queue, saturated workers). Requires an admin token; Woodpecker answers 403 otherwise. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Most tools have clearly distinct purposes, but the pipeline-inspection cluster (list_pipelines, get_pipeline, recent_activity, compare_pipelines, diagnose_pipeline, get_pipeline_config, get_step_logs) overlaps in scope. The descriptions do a good job of clarifying when to use each, but an agent must read carefully to choose correctly.
Tool names are consistently snake_case and mostly follow a verb_noun pattern (list_repos, get_pipeline, diagnose_pipeline). The main deviation is recent_activity, which uses an adjective_noun phrase instead of a verb, but the overall convention remains predictable.
With 15 tools, the server sits in the well-scoped range. Coverage spans instances, queues, repositories, pipelines, logs, branches, PRs, configs, crons, secrets, and agents, and no tool appears redundant or trivial.
The surface is strong for read-only inspection and diagnostics, including pipeline triage, logs, and configs. However, it lacks obvious write/lifecycle operations such as triggering, cancelling, or restarting pipelines, and managing secrets, crons, or repository activation, which are notable gaps for a CI server.