Jenkins MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific Jenkins resources like builds, jobs, queue, artifacts, and system status. However, getBuild and getJob could potentially be confused if an agent isn't clear about the difference between a build (execution instance) and a job (configuration template), though their descriptions help clarify this distinction.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, using clear action verbs like get, list, cancel, trigger, update, read, and schedule paired with specific nouns. All names use camelCase consistently without any mixing of conventions, making them predictable and readable.
Tool Count5/5
With 14 tools, this server is well-scoped for Jenkins automation, covering core operations like job management, build control, queue monitoring, artifact handling, and system status. Each tool earns its place by addressing a specific aspect of Jenkins interaction without being overly bloated or too sparse.
Completeness4/5
The toolset provides comprehensive coverage for Jenkins operations, including job listing/inspection, build triggering/stopping/canceling/updating, queue management, artifact access, and system/user info. A minor gap exists in job lifecycle management (e.g., create/update/delete job operations), but agents can still accomplish most workflows with the available tools.
Average 3.1/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 3 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'gets information' but doesn't disclose behavioral traits such as required permissions, rate limits, error handling, or what specific information is returned (e.g., status, logs, metadata). This is a significant gap for a tool with no annotation coverage.
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 a single, efficient sentence that directly states the tool's function without any wasted words. It's front-loaded and appropriately sized for its purpose, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of build information retrieval, no annotations, and no output schema, the description is incomplete. It doesn't explain what information is returned (e.g., build status, duration, artifacts), potential side effects, or error cases, leaving the agent with insufficient context for effective use.
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 the schema already documents both parameters fully. The description adds minimal value beyond the schema by implying the tool can fetch 'the last build' if buildNumber is omitted, but this is already covered in the schema's description for buildNumber. Baseline 3 is appropriate as the schema does the heavy lifting.
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 verb ('Get') and resource ('information about a specific build or the last build'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'getJob' or 'getStatus', which might also retrieve build-related information, so it doesn't reach the highest score.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'getJob' (which might include build info) and 'getStatus' (which could be similar), there's no indication of context, prerequisites, or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'gets information' but doesn't disclose behavioral traits such as whether it's read-only, what permissions are needed, rate limits, or the format of returned information. This is inadequate for a tool with no annotation coverage.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what information is returned, error conditions, or behavioral details. For a tool with one parameter but missing structured context, it should provide more guidance to be fully helpful.
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%, with the parameter 'jobFullName' documented as 'Full path of the Jenkins job'. The description adds no additional meaning beyond this, such as examples or constraints, so it meets the baseline for high schema coverage without compensating value.
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 verb ('Get') and resource ('information about a Jenkins job'), making the purpose understandable. However, it doesn't distinguish this tool from similar siblings like 'getBuild' or 'getJobs', which also retrieve job-related information, so it misses full differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'getBuild' (for specific builds) and 'getJobs' (for listing jobs), there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns paginated results, or details the format of the returned information. This leaves significant gaps in understanding the tool's behavior.
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 a single, clear sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficiently communicates the core functionality, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'information' includes (e.g., status, timestamps, job details), how results are structured, or any error conditions. For a tool with no structured behavioral data, this leaves too much ambiguity for effective agent use.
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?
The input schema has 100% description coverage, with the parameter 'jobFullName' documented as optional and specifying it returns all queued items if not provided. The description doesn't add any additional meaning beyond this, such as examples or edge cases, so it meets the baseline for high schema coverage without compensating further.
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 action ('Get information') and resource ('queued builds'), making the tool's purpose immediately understandable. However, it doesn't differentiate itself from sibling tools like 'getQueueItem' or 'getBuild', which might also retrieve build-related information, so it doesn't achieve 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'getQueueItem' or 'getBuild'. It mentions 'queued builds' but doesn't specify if this is for all queued items or filtered views, nor does it explain prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists artifacts but doesn't describe what 'artifacts' include (e.g., files, metadata), how results are formatted, whether there are rate limits, or if authentication is required. This leaves significant gaps for an agent to understand the tool's behavior.
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 a single, efficient sentence that directly states the tool's purpose with zero wasted words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what artifacts are, how they're returned (e.g., list format, pagination), or any behavioral traits like error handling. For a tool with no structured metadata, this leaves too many unknowns for reliable agent use.
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 the input schema already documents both parameters thoroughly. The description adds minimal value by implying the optionality of 'buildNumber' ('specific build or the last build'), but this is already clear from the schema's optional designation and description. Baseline 3 is appropriate when the schema does most of the work.
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 action ('List all artifacts') and resource ('from a specific build or the last build'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'readBuildArtifact' or 'getBuild', which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like 'readBuildArtifact' (which likely retrieves a single artifact) or 'getBuild' (which might return build metadata). It also doesn't mention prerequisites or context for selecting between specific builds or the last build.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic action. It doesn't mention authentication requirements, rate limits, error conditions, or what happens with binary vs text files beyond the format parameter. For a read operation that could involve sensitive data or large files, this is insufficient.
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 a single, clear sentence that efficiently communicates the core function without any wasted words. It's appropriately sized and front-loaded with the essential information, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what format the content is returned in, how binary files are handled beyond the format parameter, potential size limitations, or authentication requirements. Given the complexity and lack of structured metadata, more context is needed.
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 all parameters are documented in the schema. The description adds no additional parameter information beyond what's already in the schema descriptions. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
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 action ('read') and resource ('content of a specific build artifact'), making the tool's function immediately understandable. However, it doesn't differentiate from sibling tools like 'listBuildArtifacts' or 'getBuild', which might cause confusion about when to use this specific read operation versus other artifact-related tools.
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?
No guidance is provided about when to use this tool versus alternatives like 'listBuildArtifacts' or 'getBuild'. The description only states what it does without context about prerequisites, typical use cases, or comparison to sibling tools, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'stop/kill a running Jenkins build,' implying a destructive mutation, but doesn't clarify if this is reversible, what permissions are required, or how it affects the build's status. This leaves significant gaps for a mutation 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 a single, efficient sentence with zero waste—'Stop/kill a running Jenkins build'—making it front-loaded and easy to parse. Every word earns its place by specifying the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., effects, permissions), usage context, and return values, which are critical for safe and effective tool invocation in a Jenkins environment.
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 the schema already documents both parameters fully. The description adds no additional meaning beyond implying the build must be 'running,' which is useful context but not detailed parameter semantics. Baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('stop/kill') and resource ('a running Jenkins build'), making the tool's purpose immediately understandable. However, it doesn't differentiate from the sibling 'cancelQueuedBuild' tool, which appears to handle queued rather than running builds.
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?
The description provides no guidance on when to use this tool versus alternatives like 'cancelQueuedBuild' for queued builds or 'updateBuild' for modifying builds. It mentions the target is 'a running Jenkins build' but offers no context about prerequisites, permissions, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions handling 'file and regular parameters', hinting at input types, but fails to describe critical behaviors like authentication needs, rate limits, side effects (e.g., queuing builds), or response format. This is a significant gap for a mutation tool with zero annotation coverage.
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 description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured (e.g., by separating key points) without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of triggering a Jenkins build (a mutation with parameters and no output schema), the description is incomplete. It lacks details on behavioral traits, error handling, and output expectations, leaving the agent under-informed. With no annotations and no output schema, the description should do more to compensate.
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 the schema already documents both parameters ('jobFullName' and 'parameters'). The description adds marginal value by noting 'file and regular parameters', which clarifies the scope of the 'parameters' object but doesn't provide syntax or format details beyond what the schema implies. Baseline 3 is appropriate when the schema does the heavy lifting.
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 action ('Trigger') and resource ('Jenkins job build'), specifying it handles both 'file and regular parameters'. It distinguishes from siblings like 'scheduleBuild' by emphasizing immediate triggering rather than scheduling, though it could be more explicit about this distinction.
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?
No explicit guidance on when to use this tool versus alternatives like 'scheduleBuild' or 'updateBuild'. The description implies usage for immediate builds with parameters, but lacks context on prerequisites, error conditions, or comparisons with sibling tools, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool updates build metadata, implying a mutation, but doesn't cover critical aspects like required permissions, whether changes are reversible, error conditions (e.g., invalid build numbers), or side effects. For a mutation tool with zero annotation coverage, this is a significant gap.
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 a single, efficient sentence with zero waste. It front-loads the core action ('Update build') and specifies the modifiable fields directly. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral traits like permissions, error handling, or what the tool returns. For a build update tool in a Jenkins context, more context on constraints or outcomes is needed.
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 the schema already documents all four parameters (jobFullName, buildNumber, displayName, description) with clear descriptions. The description adds minimal value by mentioning 'display name and/or description' as updatable fields, but doesn't provide additional syntax, format, or usage details beyond what the schema specifies. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb ('Update') and resource ('build') along with the specific fields that can be modified ('display name and/or description'). It distinguishes itself from siblings like 'getBuild' (read-only) and 'stopBuild' (different action), though it doesn't explicitly name alternatives. The purpose is specific and actionable.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing permissions to modify builds), when not to use it (e.g., for read-only operations), or refer to sibling tools like 'getBuild' for checking current values. Usage is implied by the action but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions pagination, which is useful, but fails to describe key traits like whether this is a read-only operation (implied but not stated), potential rate limits, authentication needs, or the format of returned data (e.g., job names, statuses). For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action ('Get a paginated list of Jenkins jobs'), making it easy to parse. Every part of the sentence contributes essential information, earning its place.
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?
Given the tool's moderate complexity (list operation with pagination), no annotations, and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose and hints at pagination but lacks details on return values, error handling, or behavioral constraints. For a tool with no structured output, more context would be beneficial to fully understand its operation.
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?
The input schema has 100% description coverage, providing clear details for all three parameters (parentFullName, skip, limit). The description adds no additional parameter semantics beyond what's in the schema, such as examples or edge cases. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately documents parameters without needing extra description.
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 verb ('Get') and resource ('paginated list of Jenkins jobs'), making the purpose unambiguous. It distinguishes itself from siblings like 'getJob' (singular) by specifying it returns a list. However, it doesn't explicitly differentiate from other list-like tools (e.g., 'getQueueInfo') beyond the resource type.
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?
No guidance is provided on when to use this tool versus alternatives. While it's clear this is for listing jobs, there's no mention of when to use it over other job-related tools like 'getJob' (for single job details) or 'getQueueInfo' (for queue status). The description lacks context about prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'Get information' implies a read operation, it doesn't disclose authentication requirements, rate limits, error conditions, or what specific user information is returned. For an authentication-focused tool with zero annotation coverage, this is inadequate.
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 a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an authentication/identity tool with no annotations and no output schema, the description is insufficient. It doesn't explain what user information is returned (permissions, roles, identifiers), authentication prerequisites, or how this differs from Jenkins' standard user management tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the empty input schema is self-explanatory for a parameterless tool.
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 action ('Get information') and target ('about the current authenticated user'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools (all Jenkins-related build/job tools), which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools focused on builds, jobs, and queue operations, there's no indication of when authentication status checking is appropriate versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions checking transition to a build, which adds behavioral context beyond basic retrieval. However, it lacks details on permissions, error handling, rate limits, or what 'see whether it transitioned' entails in the response, leaving significant gaps for a tool with mutation implications.
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 description is a single, efficient sentence that front-loads the core action. It could be slightly more structured by separating purpose from behavioral context, but it avoids redundancy and wastes no words.
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?
Given no annotations and no output schema, the description is moderately complete for a simple retrieval tool. It covers purpose and hints at behavioral outcome (transition check), but lacks details on response format, error cases, or integration with siblings like triggerBuild, leaving room for improvement in guiding the agent.
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%, with queueId documented as 'Queue item ID (from triggerBuild result)'. The description adds minimal value beyond this, only reiterating 'by queueId' without explaining format or constraints further. Baseline 3 is appropriate as the schema adequately covers the single parameter.
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 verb 'Get' and resource 'queued item', specifying retrieval of a specific item by queueId. It distinguishes from siblings like getBuild or getQueueInfo by focusing on queued items rather than builds or queue metadata. However, it doesn't explicitly contrast with all relevant siblings like getStatus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to check a queued item's transition to a build, suggesting context after triggerBuild. It doesn't provide explicit when-not-to-use guidance or name alternatives like getBuild for already-transitioned items, leaving some ambiguity about optimal tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves status and health information, implying a read-only operation, but doesn't specify details like authentication requirements, rate limits, or what specific health metrics are included. This is a significant gap for a tool with no annotation coverage.
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 a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for quick understanding.
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?
Given the tool's simplicity (0 parameters, no output schema) and lack of annotations, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects like return format or usage context, which could be helpful for an agent. It meets the minimum viable threshold without being fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents that no inputs are required. The description doesn't need to add parameter details, and it appropriately doesn't mention any, earning a baseline score above 3 for correctly aligning with the schema's emptiness.
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 verb 'Get' and the resource 'Jenkins instance status and health information', making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from siblings like 'whoAmI' or 'getQueueInfo', which might also provide status-related information, so it doesn't reach the highest score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or specific contexts for usage, such as checking system health before triggering builds. This leaves the agent with minimal direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions scheduling with parameters but lacks critical details: it doesn't specify authentication needs, rate limits, whether the schedule is guaranteed or best-effort, how errors are handled, or what the response includes. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence that front-loads the core purpose ('Schedule a Jenkins build') and includes key modifiers without redundancy. Every phrase earns its place by specifying parameters and timing, making it appropriately sized and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of scheduling a build (a mutation operation), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, error handling, or return values, and while the schema handles parameters well, the overall context for safe and effective use is lacking, making it inadequate for a tool with this level of responsibility.
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 the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by hinting at 'file and regular parameters' for the 'parameters' field, but doesn't provide additional syntax, format, or usage details. Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('Schedule a Jenkins build') and specifies the resource ('Jenkins build'), including key aspects like 'with file and regular parameters' and 'to run at a specific time'. It distinguishes from siblings like 'triggerBuild' (immediate execution) by emphasizing scheduling, but doesn't explicitly name alternatives or detail scope differences beyond timing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deferred execution ('at a specific time'), suggesting it's for future builds rather than immediate ones. However, it doesn't explicitly state when to use this tool versus alternatives like 'triggerBuild' (for immediate builds) or 'cancelQueuedBuild' (for managing scheduled ones), nor does it mention prerequisites or exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it states the tool cancels builds, it doesn't mention permission requirements, whether the action is reversible, potential side effects (e.g., notifications, downstream impacts), or what happens on success/failure. For a destructive operation with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and immediately clarifies the target state ('pending/queued... hasn't started yet'), making it easy to parse quickly.
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?
Given the tool's destructive nature and lack of annotations/output schema, the description is minimally adequate but incomplete. It covers the basic purpose and target state well, but fails to address critical context like authentication needs, error conditions, or result format. For a mutation tool with no structured safety hints, more behavioral detail would be beneficial.
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 the schema already fully documents both parameters (jobFullName and queueId). The description doesn't add any parameter-specific information beyond what's in the schema, such as format examples for jobFullName or clarification on queueId sourcing. This meets the baseline for high schema coverage.
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?
The description clearly states the specific action ('cancel') and target resource ('a pending/queued Jenkins build that hasn't started yet'), distinguishing it from sibling tools like 'stopBuild' (which presumably stops running builds) and 'scheduleBuild'/'triggerBuild' (which create builds). The verb+resource combination is precise and unambiguous.
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 description provides clear context about when to use this tool ('a pending/queued Jenkins build that hasn't started yet'), which implicitly distinguishes it from tools for active builds. However, it doesn't explicitly name alternatives (like 'stopBuild' for running builds) or provide exclusion criteria, leaving some inference required for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Jenkins-mcp-server MCP server](https://glama.ai/mcp/servers/umishra1504/Jenkins-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/umishra1504/Jenkins-mcp-server)

Score Badge

Copy to your README.md:

[![Jenkins-mcp-server MCP server](https://glama.ai/mcp/servers/umishra1504/Jenkins-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/umishra1504/Jenkins-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/umishra1504/Jenkins-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server