Jenkins MCP Server

Overview Schema Source Related Servers Discussions Admin

Recent Builds

recent_builds

Read-onlyIdempotent

Lists every Jenkins build started within a chosen time window across one or all instances, newest first, with result, duration, age, culprits, and result counts for stand-up checks.

Instructions

Every build (not only the last one per job) started in the last hours, across one or all instances in parallel, newest first: 'job #n RESULT duration age | culprits | long-running note'. Counts per result. Uses ~1 request per instance (up to 10 newest builds per job are checked). Good for 'what ran/failed today', a morning check or a stand-up.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "recent_builds"
  }
}

Input Schema

Name	Required	Description	Default
`hours`	No
`folder`	No
`status`	No	Comma list: SUCCESS, FAILURE, UNSTABLE, ABORTED, NOT_BUILT, BUILDING. Empty = all
`instance`	No	Instance name or 'all'	all
`limit_per_instance`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 1, 2026

TDQS

A4/5.0

Behavior5/5

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

Beyond the annotations, it discloses important behavior: parallel instance querying, request cost (~1 request per instance), sampling limits (up to 10 newest builds per job checked), output shape, and result counts. These are exactly the operational details an agent needs before invoking the tool.

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?

The description is dense but front-loaded and every sentence adds useful information about scope, output, cost, or intended use. There is little wasted text despite the amount of detail.

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?

With an output schema present and annotations covering safety, the description provides strong context on scope, output format, sampling, and use cases. It is slightly incomplete on the `folder` and `limit_per_instance` parameters, but otherwise gives an agent enough to invoke the tool correctly.

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 40%, so the description should compensate more than it does. It explains `hours` and `instance`, but does not explain `folder` or `limit_per_instance`, and only indirectly relates to `status` through 'Counts per result'.

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 clearly states the resource and scope: all builds started within the last `hours`, across one or all instances, newest first. It distinguishes itself from a last-build-per-job view, but does not explicitly name a sibling tool, so it falls short of full sibling differentiation.

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?

It gives concrete usage contexts: 'what ran/failed today', a morning check, or a stand-up. It does not state when not to use it or name an alternative such as `get_build_summary`, but the intended context is clear.

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