Jenkins MCP Server

Overview Schema Source Related Servers Discussions Admin

List Known Issues

list_known_issues

Read-onlyIdempotent

List team knowledge base entries with ID, status, category, scope, and title plus build match counts; filter by text query, category, Jenkins instance, or drafts.

Instructions

List knowledge base entries: 'id | status | category | scope | title', plus how many builds each entry matched since the server started. query = case-insensitive text filter on title and content.

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

Input Schema

Name	Required	Description
`query`	No
`category`	No
`instance`	No	Jenkins instance name from list_instances. Empty = default instance.
`include_drafts`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 1, 2026

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds genuinely useful non-obvious behavior: the match counter is scoped 'since the server started', meaning it resets on restart and is not a persistent statistic. It says nothing about ordering, limits, or how pagination behaves for a potentially long listing.

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?

Two short sentences: the first front-loads what is returned, the second defines the filter. Nothing is redundant and no sentence could be removed without losing information.

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, so the column listing is a bonus rather than a necessity. But for a 4-parameter listing tool the description leaves two filters (category, include_drafts) unexplained and gives no routing guidance against find_known_issues, which an agent needs to choose correctly.

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 low at 25% — only 'instance' carries a schema description — and the text compensates for exactly one parameter, explaining that query filters case-insensitively on title and content. 'category' and 'include_drafts' remain undocumented in both schema and description, so compensation is only partial.

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?

It states a specific verb ('List') and resource ('knowledge base entries') and even enumerates the returned columns, so the operation is unambiguous. However, it never distinguishes itself from the closely related siblings find_known_issues and get_known_issue, leaving the agent to guess which one is the filtered search versus the plain listing.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus find_known_issues or get_known_issue, and no mention of preconditions such as needing list_instances first (only implied by the instance param schema). The query-filter sentence describes mechanics, not selection criteria between alternatives.

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