Retrieve the Jenkins server version from the X-Jenkins response header to identify the installed release without requiring admin access.
Return Jenkins version from the X-Jenkins response header.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| ok | Yes | ||
| data | Yes |
Changes observed during successful MCP inspections.
v2.0.0Output schema / additionalPropertiesRemoved value: -trueOutput schema / descriptionAdded value: +"Structured content returned by successful Jenkins tools."Output schema / propertiesAdded value: +{
+ "data": {
+ "title": "Data"
+ },
+ "ok": {
+ "const": true,
+ "title": "Ok",
+ "type": "boolean"
+ }
+}Output schema / requiredAdded value: +[
+ "ok",
+ "data"
+]Output schema / titlePrevious value: -"jenkins_versionDictOutput"New value: +"ToolSuccess"v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, establishing the safety profile. The description adds a specific behavioral detail—that the version is read from the X-Jenkins response header—giving the agent insight into how the result is obtained. This is useful context beyond the annotations, though it doesn't cover error handling or auth requirements, which are minor for such a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that delivers the core purpose and a notable behavioral detail. It has no filler or redundant content, and the key action is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with an output schema present, the description fully covers what the tool does and where the data comes from. An agent has everything needed to invoke it correctly. No additional context is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100% (empty schema). The baseline for zero-parameter tools is 4. The description does not need to add parameter details, and mentioning the response header is not parameter-related. No gaps exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Return'), a specific resource ('Jenkins version'), and the data source ('X-Jenkins response header'). This clearly distinguishes it from siblings like jenkins_health or jenkins_whoami, which address different purposes. There is no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, nor any mention of exclusions or prerequisites. However, the purpose is self-evident, so an agent can reasonably infer that it should be used when the Jenkins server version is needed. This falls under implied usage rather than no guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.