woodpecker-mcp

woodpecker_cron

Destructive

Manage Woodpecker CI cron schedules: list, get, create, update, delete, or run jobs. Write actions execute only with confirm=true and WOODPECKER_ALLOW_WRITES=true.

Instructions

Cron list, get, create, update, delete, and run. Writes run only when confirm is true and WOODPECKER_ALLOW_WRITES=true. Actions: list, get, create, update, delete, run.

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_cron"
  }
}

Input Schema

Name	Required	Description
`cron`	No
`name`	No
`page`	No
`action`	Yes	Woodpecker operation to call.
`branch`	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.
`enabled`	No	Cron enabled flag. false is sent when the caller sets it.
`perPage`	No
`repo_id`	No
`schedule`	No
`timezone`	No
`variables`	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 declare destructive=true, readOnly=false and idempotent=false, so the safety profile is partly covered. The description adds genuinely new behavioral context: the two-part write gate and the default dry-run behavior when confirm is omitted, which is exactly what an agent needs before mutating anything. It stops short of saying what delete destroys or which parameters each action requires.

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?

The write-gating sentence is front-loaded and valuable, but the closing 'Actions: list, get, create, update, delete, run' simply repeats the verb list from the first sentence and adds nothing. One of three sentences is pure redundancy.

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?

For a 12-parameter, action-dispatching tool that can delete and run, with no output schema and 25% parameter coverage, the description does not say which parameters belong to which action or what a successful response looks like. It covers the safety mechanism but leaves the calling contract largely to inference.

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?

Twelve parameters with only 25% schema description coverage means most parameters (repo_id, cron, name, schedule, branch, timezone, variables, enabled, page, perPage) are undocumented in both the schema and the description. The description's only parameter-level content is the confirm gate, which the schema already explains in more detail, so it does not compensate for the coverage gap or map parameters to specific actions.

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 (cron) and enumerates the six operations it multiplexes, so an agent can tell it manages cron schedules rather than logs, pipelines, repos, secrets or system info. It does not explicitly contrast with any sibling, but the resource scope is unambiguous.

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?

Usage context is given for the write path: writes require confirm=true plus WOODPECKER_ALLOW_WRITES=true, and omitting confirm yields a dry-run preview. Nothing tells the agent when to pick list vs get vs run, or when this tool is preferable to any alternative; the action names imply usage rather than state it.

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

Deploy Server