Skip to main content
Glama

cancelQueuedBuild

Cancel pending Jenkins builds in the queue before they start executing, either for a specific queue item or all queued items for a job.

Instructions

Cancel a pending/queued Jenkins build that hasn't started yet

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobFullNameYesFull path of the Jenkins job
queueIdNoSpecific queue item ID to cancel (optional, cancels all queued items for the job if not provided)

Implementation Reference

  • Main handler function for canceling queued Jenkins builds, either by specific queueId or all queued items for a job.
    export async function cancelQueuedBuild(client, args) {
    	const { jobFullName, queueId = null } = args;
    	const jobPath = encodeJobPath(jobFullName);
    
    	try {
    		// If queueId is provided, cancel that specific item
    		if (queueId) {
    			const cancelResponse = await client.post(
    				`${client.baseUrl}/queue/cancelItem`,
    				`id=${queueId}`,
    				{
    					headers: {
    						"Content-Type": "application/x-www-form-urlencoded",
    					},
    				}
    			);
    
    			if (
    				isSuccessStatus(cancelResponse.status) ||
    				cancelResponse.status === 204
    			) {
    				return success("cancelQueuedBuild", {
    					message: `Queue item #${queueId} cancelled successfully`,
    					queueId,
    					method: "direct",
    				});
    			} else {
    				return failure(
    					"cancelQueuedBuild",
    					`Failed to cancel queue item #${queueId}`,
    					{ statusCode: cancelResponse.status }
    				);
    			}
    		}
    
    		// If no queueId provided, find and cancel all queued items for this job
    		const queueResponse = await client.get(
    			`${client.baseUrl}/queue/api/json`
    		);
    
    		if (queueResponse.status !== 200) {
    			return failure(
    				"cancelQueuedBuild",
    				"Failed to fetch queue information",
    				{ statusCode: queueResponse.status }
    			);
    		}
    
    		const queueItems = queueResponse.data.items || [];
    
    		// Find items for this specific job
    		const jobQueueItems = queueItems.filter((item) => {
    			if (item.task && item.task.url) {
    				const itemJobPath = item.task.url
    					.replace(client.baseUrl, "")
    					.replace(/^\//, "")
    					.replace(/\/$/, "");
    				const targetJobPath = `job/${jobPath}`.replace(/\/$/, "");
    				return itemJobPath === targetJobPath;
    			}
    
    			if (item.task && item.task.name) {
    				const jobName = jobFullName.split("/").pop();
    				return (
    					item.task.name === jobFullName || item.task.name === jobName
    				);
    			}
    
    			return false;
    		});
    
    		if (jobQueueItems.length === 0) {
    			return failure(
    				"cancelQueuedBuild",
    				`No queued builds found for job: ${jobFullName}`,
    				{ totalQueueItems: queueItems.length }
    			);
    		}
    
    		// Cancel all found queue items for this job
    		const cancelResults = [];
    		for (const item of jobQueueItems) {
    			try {
    				const cancelResponse = await client.post(
    					`${client.baseUrl}/queue/cancelItem`,
    					`id=${item.id}`,
    					{
    						headers: {
    							"Content-Type": "application/x-www-form-urlencoded",
    						},
    					}
    				);
    
    				cancelResults.push({
    					queueId: item.id,
    					success:
    						isSuccessStatus(cancelResponse.status) ||
    						cancelResponse.status === 204,
    					statusCode: cancelResponse.status,
    					why: item.why || "No reason provided",
    					inQueueSince: item.inQueueSince,
    					params: item.params,
    				});
    			} catch (error) {
    				cancelResults.push({
    					queueId: item.id,
    					success: false,
    					error: error.message,
    				});
    			}
    		}
    
    		const successCount = cancelResults.filter((r) => r.success).length;
    		const allSuccess = successCount === cancelResults.length;
    
    		return allSuccess
    			? success("cancelQueuedBuild", {
    					message: `Successfully cancelled ${successCount} queued build(s) for ${jobFullName}`,
    					cancelledItems: cancelResults,
    					totalCancelled: successCount,
    					totalFound: jobQueueItems.length,
    			  })
    			: failure(
    					"cancelQueuedBuild",
    					`Cancelled ${successCount} out of ${cancelResults.length} queued build(s)`,
    					{
    						cancelledItems: cancelResults,
    						totalCancelled: successCount,
    						totalFound: jobQueueItems.length,
    					}
    			  );
    	} catch (error) {
    		return formatError(error, "cancel queued build");
    	}
    }
  • Tool registration in the central registry, including name, description, input schema, and handler reference.
    cancelQueuedBuild: {
    	name: "cancelQueuedBuild",
    	description:
    		"Cancel a pending/queued Jenkins build that hasn't started yet",
    	inputSchema: {
    		type: "object",
    		properties: {
    			jobFullName: {
    				type: "string",
    				description: "Full path of the Jenkins job",
    			},
    			queueId: {
    				type: "integer",
    				description:
    					"Specific queue item ID to cancel (optional, cancels all queued items for the job if not provided)",
    			},
    		},
    		required: ["jobFullName"],
    	},
    	handler: cancelQueuedBuild,
  • Input schema definition for the cancelQueuedBuild tool.
    inputSchema: {
    	type: "object",
    	properties: {
    		jobFullName: {
    			type: "string",
    			description: "Full path of the Jenkins job",
    		},
    		queueId: {
    			type: "integer",
    			description:
    				"Specific queue item ID to cancel (optional, cancels all queued items for the job if not provided)",
    		},
    	},
    	required: ["jobFullName"],
    },
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.

Install Server

Other Tools

Latest Blog Posts

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