Skip to main content
Glama
Sign In
Jenkins MCP Server

Jenkins MCP Server

by TelmanH
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Propose Kb Update

propose_kb_update

Propose an update to an existing knowledge base entry instead of duplicating it: write a new draft in knowledge/drafts/, merge added regexes and build URLs, and report whether the build matches.

Instructions

Propose an update of an EXISTING knowledge base entry instead of writing a duplicate: writes a NEW draft next to it in knowledge/drafts/ with the build URL added to builds, the extra regexes merged in and an 'Update proposal' section. Never touches the entry itself or Jenkins, never overwrites a file. Reports whether the entry matches the given build.

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": {
      "id": "<id>"
    },
    "name": "propose_kb_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesReviewed entry to update, e.g. KB-0001
jobNoJob full name or Jenkins URL. Empty = not tied to a build.
noteNoWhat is new: another occurrence, a better fix, a wrong regex...
buildNoBuild number or permalink: lastBuild, lastFailedBuild, lastSuccessfulBuild, lastCompletedBuild, lastUnsuccessfulBuild. Empty = build from the URL, else lastBuild.
instanceNoJenkins instance name from list_instances. Empty = default instance.
add_matchNoPython regexes (case-insensitive). Use specific phrases copied from the log, not generic words like 'ERROR'.
add_consequencesNoPython regexes (case-insensitive). Use specific phrases copied from the log, not generic words like 'ERROR'.
add_red_herringsNoPython regexes (case-insensitive). Use specific phrases copied from the log, not generic words like 'ERROR'.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare a non-destructive, non-read-only, non-idempotent write, and the description adds substantial detail beyond them: it writes a separate draft rather than mutating the entry, never touches the entry itself or Jenkins, never overwrites a file, and reports whether the entry matches the given build. This is exactly the extra context the annotations cannot convey.

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?

The distinguishing constraint is front-loaded in the first clause, and each subsequent sentence adds distinct information about what is created and what is left untouched. The one long sentence packing three draft modifications is dense but not wasteful; only minor tightening is possible.

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 the description need not explain return values, yet it still notes that the call reports build-match status. Safety and side effects are fully covered for an 8-parameter write tool. What is missing is only marginal: no mention of what happens on an unknown or un-reviewed id.

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 every parameter (id, job, note, build, instance, add_match, add_consequences, add_red_herrings) is already documented in the schema. The description reinforces that the regex arguments are merged into the existing entry and that build data is appended, but adds no syntax, format, or constraint detail beyond the schema, so the baseline 3 applies.

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 ('Propose an update of an EXISTING knowledge base entry') and immediately contrasts it with the duplicate-creating alternative. The concrete effect — a new draft under knowledge/drafts/ with the build URL appended, regexes merged, and an 'Update proposal' section — makes the outcome unambiguous and distinguishes it from siblings like draft_kb_entry.

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?

The opening clause gives a clear when-to-use rule: prefer this over writing a duplicate when an entry already exists. It also implies the precondition that the target must be an existing reviewed entry (id, e.g. KB-0001). It stops short of naming a sibling tool or stating explicit when-not conditions, so it is clear context rather than full routing guidance.

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