Jenkins MCP Server

Overview Schema Source Related Servers Discussions Admin

Recurring Errors

recurring_errors

Read-onlyIdempotent

Groups errors across a job's newest finished builds, showing failed/green counts, first/last build, and whether each is a new regression or also occurs in green builds; attaches knowledge-base notes.

Instructions

Error groups across the newest finished builds of one job (max 20): in how many failed and green builds each occurs, first/last build, and a verdict - 'new since #N' (regression) or 'also in green builds' (red_herring candidate for the knowledge base). Knowledge base notes are attached. Cost: one log per build (cached afterwards).

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": {
      "job": "<job>"
    },
    "name": "recurring_errors"
  }
}

Input Schema

Name	Required	Description
`job`	Yes	Job full name like 'cd/master/my-app' (folders separated by '/'), or a Jenkins job/build URL (instance is then detected from the URL).
`last_n`	No
`instance`	No	Jenkins instance name from list_instances. Empty = default instance.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 1, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover read-only/idempotent safety, and the description adds genuinely useful operational context: a cap of 20 error groups, the verdict classification logic, KB note attachment, and an explicit cost model ('one log per build, cached afterwards'). It stops short of describing caching lifetime or how 'newest finished builds' are selected.

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

Conciseness4/5

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

Purpose is front-loaded and every clause carries information (verdict semantics, KB notes, cost). The telegraphic multi-clause sentence and dangling '(max 20)' placement add slight parsing friction, but there is no filler.

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

Completeness4/5

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

For a read-only analytical tool with an output schema, the description supplies what the schema cannot: verdict meaning, the KB linkage, and the log-read cost. Only the last_n semantics and the exact build window remain underspecified.

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

Parameters3/5

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

Schema coverage is 67%: job and instance are documented, but last_n has no description at all. The description's 'newest finished builds ... (max 20)' is the only hint about how many builds are scanned, and it does not clearly reconcile with last_n's default of 8, leaving the control ambiguous.

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?

States a specific analysis verb over a specific resource: recurring error groups aggregated across the newest finished builds of one job, with counts in failed vs green builds, first/last build, and a verdict. The aggregation-over-builds framing naturally separates it from per-build siblings like get_log_errors or get_build_summary, though no sibling is named explicitly.

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?

Use is implied by the verdict labels ('regression', 'red_herring candidate for the knowledge base') and the note that KB notes are attached, which hints at a triage workflow. However, there is no explicit statement of when to call this versus failures_overview, get_log_errors, or find_known_issues, and no stated prerequisites.

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