Skip to main content
Glama

build_item

Trigger a Jenkins build for an item by providing its fullname. Optionally pass parameters for parameterized builds.

Instructions

Build an item in Jenkins

Args: fullname: The fullname of the item data: The parameters to trigger the build with. Required if build_type is 'buildWithParameters'. build_type: If your item is configured with parameters, you must use 'buildWithParameters' as build_type.

Returns: The queue item number of the item.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullnameYes
build_typeYes
dataNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The core implementation of build_item in the Jenkins REST client. Parses the fullname into folder/name, sends a POST request to the ITEM_BUILD endpoint, and returns the queue item number from the Location header.
    def build_item(
        self,
        *,
        fullname: str,
        build_type: Literal['build', 'buildWithParameters'],
        data: dict | None = None,
    ) -> int:
        """Trigger a build for a specific item.
    
        Warnings:
            If your job is configured with parameters, you must use 'buildWithParameters' as build_type.
    
        Args:
            fullname: The fullname of the job.
            build_type: The type of build to trigger.
            data: The parameters to trigger the build with. Required if build_type is 'buildWithParameters'.
    
        Return:
            The queue item number of the job.
        """
        folder, name = self._parse_fullname(fullname)
        response = self.request(
            'POST',
            rest_endpoint.ITEM_BUILD(folder=folder, name=name, build_type=build_type),
            data=data,
        )
    
        return int(response.headers.get('Location', None).strip('/').split('/')[-1])
  • The MCP tool handler for build_item. This is the async function decorated with @mcp.tool that exposes the tool to MCP clients. Delegates to the Jenkins REST client.
    @mcp.tool(tags=['write'])
    async def build_item(
        ctx: Context,
        fullname: str,
        build_type: Literal['build', 'buildWithParameters'],
        data: dict | None = None,
    ) -> int:
        """Build an item in Jenkins
    
        Args:
            fullname: The fullname of the item
            data: The parameters to trigger the build with. Required if build_type is 'buildWithParameters'.
            build_type: If your item is configured with parameters, you must use 'buildWithParameters' as build_type.
    
        Returns:
            The queue item number of the item.
        """
        return jenkins(ctx).build_item(fullname=fullname, build_type=build_type, data=data)
  • The REST endpoint definition for ITEM_BUILD, which formats to '{folder}job/{name}/{build_type}'.
    ITEM_BUILD = RestEndpoint('{folder}job/{name}/{build_type}')
  • The mcp (JenkinsMCP) instance is created here, and the item module is imported (line 34) which triggers the @mcp.tool decorators to register build_item as an MCP tool.
    mcp = JenkinsMCP('mcp-jenkins', lifespan=lifespan)
    
    # Import tool modules to register them with the MCP server
    # This must happen after mcp is created so the @mcp.tool() decorators can reference it
    from mcp_jenkins.server import build, item, node, plugin, queue, view  # noqa: F401, E402
  • The RestEndpoint class used by ITEM_BUILD. It supports string formatting via __call__ so endpoint templates like '{folder}job/{name}/{build_type}' can be filled in with parameters.
    from string import Formatter
    
    
    class RestEndpoint(str):
        def __new__(cls, value: str) -> str:
            obj = str.__new__(cls, value)
            obj._fields = {name for _, name, _, _ in Formatter().parse(value) if name}
            return obj
    
        def __call__(self, **kwargs: str | int) -> str:
            if missing := self._fields.difference(kwargs):
                raise KeyError(f'Missing: {missing}')
    
            return self.format(**kwargs)
    
    
    CRUMB = RestEndpoint('crumbIssuer/api/json')
    
    ITEM = RestEndpoint('{folder}job/{name}/api/json?depth={depth}')
    ITEMS = RestEndpoint('{folder}/api/json?tree={query}')
    ITEM_CONFIG = RestEndpoint('{folder}job/{name}/config.xml')
    ITEM_BUILD = RestEndpoint('{folder}job/{name}/{build_type}')
    
    QUEUE = RestEndpoint('queue/api/json?depth={depth}')
    QUEUE_ITEM = RestEndpoint('queue/item/{id}/api/json?depth={depth}')
    QUEUE_CANCEL_ITEM = RestEndpoint('queue/cancelItem?id={id}')
    
    NODE = RestEndpoint('computer/{name}/api/json?depth={depth}')
    NODES = RestEndpoint('computer/api/json?depth={depth}')
    NODE_CONFIG = RestEndpoint('computer/{name}/config.xml')
    
    VIEW = RestEndpoint('{view_path}/api/json?depth={depth}')
    VIEWS = RestEndpoint('api/json?tree=views[name,url]')
    
    BUILD = RestEndpoint('{folder}job/{name}/{number}/api/json?depth={depth}')
    BUILD_CONSOLE_OUTPUT = RestEndpoint('{folder}job/{name}/{number}/consoleText')
    BUILD_STOP = RestEndpoint('{folder}job/{name}/{number}/stop')
    BUILD_REPLAY = RestEndpoint('{folder}job/{name}/{number}/replay')
    BUILD_PARAMETERS = RestEndpoint('{folder}job/{name}/{number}/api/json?tree=actions[parameters[name,value]]')
    BUILD_TEST_REPORT = RestEndpoint('{folder}job/{name}/{number}/testReport/api/json?depth={depth}')
    BUILD_ARTIFACT = RestEndpoint('{folder}job/{name}/{number}/artifact/{relative_path}')
    BUILD_ARTIFACTS = RestEndpoint('{folder}job/{name}/{number}/api/json?tree=artifacts[fileName,relativePath,displayPath]')
    
    PLUGIN_LIST = RestEndpoint('pluginManager/api/json?depth={depth}')
    PLUGIN_LIST_TREE = RestEndpoint('pluginManager/api/json?tree=plugins[{tree}]')
Behavior3/5

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

Discloses the return type (queue item number) and parameter conditions, but lacks depth on side effects, error handling, authentication needs, or rate limits. With no annotations, the description carries full burden and only gives basic behavior.

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?

Structured with Args and Returns sections, front-loaded with purpose. Slightly verbose but clear and organized.

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?

Covers main inputs and return value, but lacks error states, prerequisites, or integration with sibling tools. An output schema exists but the description only mentions the queue item number without format details.

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% schema description coverage, the description adds critical meaning: condition for data, explanation of build_type enum, and clarifies fullname role. This compensates for the schema's lack of descriptions.

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 'Build an item in Jenkins', specifying the verb (build) and resource (item). It distinguishes from sibling tools like get_item (retrieval) and cancel_queue_item (cancellation).

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?

Provides guidance on when to use 'buildWithParameters' and the data parameter conditionally required. However, it does not explicitly contrast with alternative tools or state prerequisites like item existence.

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/lanbaoshen/mcp-jenkins'

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