Skip to main content
Glama
Sign In
woodpecker-ci-mcp

woodpecker-ci-mcp

by ni-c
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Set the server log level

set_log_level
Idempotent

Changes the log level of the running Woodpecker server without a restart. Admin only; use debug/trace for diagnostics and restore normal level afterward.

Instructions

Changes the log level of the running Woodpecker server, without a restart. Admin only. "debug" and "trace" are loud — set it back when you are done, and remember that trace logs request bodies.

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": {
      "level": "<level>"
    },
    "name": "set_log_level"
  }
}

Input Schema

NameRequiredDescriptionDefault
levelYesThe new log level. The default is "info". "disabled" turns server logging off entirely — including the records of what happened next. Lowering it below "warn" needs a confirm_token.
confirm_tokenNoRequired only for the levels that suppress records — fatal, panic and disabled.

Output Schema

NameRequiredDescriptionDefault
truncatedNoPresent only when the answer was shortened to fit the budget.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the live no-restart effect, the admin authorization requirement, that debug/trace are noisy and should be reverted, and that trace logs request bodies (a real privacy consideration). The idempotentHint=true and destructiveHint=false annotations are consistent with the described behavior, and the description materially enriches what the annotations alone convey.

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

Conciseness5/5

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

Three short sentences earn their place: the core action, the access precondition, and the operational warning. The most decision-relevant information (what it changes, that no restart is needed) is front-loaded, with zero filler.

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

Completeness5/5

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

For a two-parameter tool with 100% schema coverage, an output schema, and safety-relevant annotations, nothing essential is missing. The description covers access control, live behavior, and operational risks; return-value details are covered by the output schema, and the confirm_token mechanism is documented in the schema.

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

Parameters4/5

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

Schema coverage is 100% and both parameters already have rich descriptions, so the baseline is 3. The description adds value by characterizing specific enum values ('debug' and 'trace' are loud; trace logs request bodies), which reinforces the playbook for the level parameter without duplicating the schema's content.

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

Purpose5/5

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

States a specific verb and resource ('Changes the log level of the running Woodpecker server') and adds a scope-defining detail ('without a restart') that separates it from config-file-based alternatives. It reads clearly as the mutating counterpart to the sibling get_log_level, so an agent can distinguish it from the 60+ siblings without opening the schema.

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

Usage Guidelines4/5

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

Gives clear operational context: use this for live changes that take effect without a restart, and it flags the admin-only precondition. It also cautions to revert debug/trace after use, which is actionable guidance. However, it does not name an explicit alternative or state a when-not-to-use condition, so it falls just short of a 5.

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

Deploy Server

Other Tools