MCP Jenkins

Get All Items

get_all_items

Retrieves all Jenkins items with optional field selection and limit controls, returning compact inventory results for discovery; use filtered queries on large instances.

Instructions

Get all items from Jenkins, compact: prefer query_items with a filter on a large instance

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": "get_all_items"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum number of items, 1-1000 (default 200); a final row says how many were dropped
`fields`	No	Fields to return, from fullname, name, kind, class_, url, color (default: fullname, kind, color)

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.6.0+microtech.5Nov 7, 2026

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden, and it does disclose one meaningful trait: results are 'compact'. It says nothing about read-only semantics, ordering, truncation behavior, or pagination beyond what the schema already documents (limit and the dropped-rows row).

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?

Two short clauses, front-loaded with the action and resource before the alternative. The colon-separated 'compact:' fragment is slightly clipped but costs nothing in clarity.

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

Completeness3/5

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

An output schema exists and the parameters are fully documented, so the description needn't explain return values. However, for an unfiltered bulk-list tool on a potentially large instance, it omits what an 'item' covers and any hint of how the unfiltered result scales, leaving the agent to infer scope.

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 description coverage is 100%, so both limit and fields are already fully documented, including the default field set and the dropped-row notice. The description's only parameter-adjacent contribution is the word 'compact', which loosely implies the reduced default projection but adds no new syntax or format detail.

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?

Names a specific verb and resource (get all items from Jenkins) and adds a scope qualifier ('compact'), which lets an agent distinguish it from the narrowed sibling query_items. It stops short of defining what an 'item' is in Jenkins terms (job/folder/view), so the resource remains slightly ambiguous against siblings like get_all_views or get_all_nodes.

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?

Explicitly routes the agent to query_items with a filter 'on a large instance', giving a real alternative plus the condition that selects it. It does not cover the small-instance case or when to prefer get_item for a single object, but the primary routing decision is stated.

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