woodpecker-mcp

woodpecker_pipelines

Destructive

Manage Woodpecker CI pipelines through MCP: list, inspect, configure, trigger, cancel, restart, approve, decline, or delete runs. Write actions require confirm=true and WOODPECKER_ALLOW_WRITES=true.

Instructions

Pipeline list, get, trigger, cancel, restart, approve, decline, delete, config, and metadata. Writes run only when confirm is true and WOODPECKER_ALLOW_WRITES=true. Actions: list, get, create, cancel, restart, approve, decline, delete, config, metadata.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "woodpecker_pipelines"
  }
}

Input Schema

Name	Required	Description
`fork`	No
`page`	No
`after`	No
`event`	No
`action`	Yes	Woodpecker operation to call.
`before`	No
`branch`	No
`status`	No
`confirm`	No	Boolean true runs the write when WOODPECKER_ALLOW_WRITES is true. Omit it or pass false for a dry-run preview that sends nothing. The string true is rejected.
`message`	No
`perPage`	No
`repo_id`	No
`workflow`	No
`deploy_to`	No
`variables`	No
`pipeline_number`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 11, 2026

TDQS

B3.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds genuinely non-redundant behavior: writes are gated behind a confirm flag and an environment variable, and the default is a dry-run that sends nothing. It does not disclose irreversibility of delete/cancel or any rate limits, which keeps it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded, with no filler prose. However, the action list is stated twice (inline and again after 'Actions:'), and the redundant repetition is also where the 'trigger' vs 'create' inconsistency appears.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a 16-parameter, destructive, multi-action tool with no output schema and near-zero schema descriptions, so the description carries a heavy load. It omits the action-to-parameter mapping and any indication of what each action returns, leaving the agent to guess which fields matter for, say, 'create' versus 'metadata'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 13% across 16 parameters, so the description must compensate and largely does not. It only echoes the confirm gate already documented in the schema and says nothing about repo_id, pipeline_number, branch, status, variables, deploy_to, or the pagination pair page/perPage, nor which parameters apply to which action.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (Woodpecker pipelines) and enumerates the concrete operations it dispatches, so an agent can tell this apart from woodpecker_cron, woodpecker_repos, or woodpecker_logs. The one flaw is the first sentence advertising a 'trigger' operation that does not exist in the action enum (the enum uses 'create'), which can send an agent looking for a non-existent action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly states the precondition for write operations (confirm=true plus WOODPECKER_ALLOW_WRITES=true) and that omitting confirm yields a dry-run preview. It gives no guidance on which action to choose for a given intent, nor when to defer to sibling tools such as woodpecker_logs for run output.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server