Skip to main content
Glama

get_build_scripts

Retrieve scripts used in a Jenkins build job. Provide job fullname and optional build number to get scripts from a specific build.

Instructions

Get the scripts used in a specific build in Jenkins

Args: fullname: The fullname of the job number: The number of the build, if None, get the last build

Returns: A list of scripts used in the build

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullnameYes
numberNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The main handler for the get_build_scripts tool. Decorated with @mcp.tool(tags=['read']), it accepts a fullname (job path) and optional build number, fetches the build replay data, and returns the list of scripts.
    @mcp.tool(tags=['read'])
    async def get_build_scripts(ctx: Context, fullname: str, number: int | None = None) -> list[str]:
        """Get the scripts used in a specific build in Jenkins
    
        Args:
            fullname: The fullname of the job
            number: The number of the build, if None, get the last build
    
        Returns:
            A list of scripts used in the build
        """
        if number is None:
            number = jenkins(ctx).get_item(fullname=fullname, depth=1).lastBuild.number
    
        return jenkins(ctx).get_build_replay(fullname=fullname, number=number).scripts
  • The tool is registered via the @mcp.tool(tags=['read']) decorator on the get_build_scripts function. The 'mcp' object is a JenkinsMCP (subclass of FastMCP) instance created in src/mcp_jenkins/server/__init__.py line 30.
    @mcp.tool(tags=['read'])
  • The BuildReplay model defines the return type: a list of strings (scripts) parsed from the Jenkins replay page.
    class BuildReplay(BaseModel):
        scripts: list[str]
  • The get_build_replay method on the REST client fetches the replay page HTML, parses out textarea elements matching the script name pattern, and returns a BuildReplay object.
    def get_build_replay(self, *, fullname: str, number: int) -> BuildReplay:
        """Get the build replay of a specific build.
    
        If you want to get the pipeline source code of a specific build in Jenkins, you can use this method.
    
        Args:
            fullname: The fullname of the job.
            number: The build number.
    
        Returns:
            The build replay object containing the pipeline scripts.
        """
    
        folder, name = self._parse_fullname(fullname)
        response = self.request('GET', rest_endpoint.BUILD_REPLAY(folder=folder, name=name, number=number))
    
        soup = BeautifulSoup(response.text, 'html.parser')
    
        scripts = [textarea.text for textarea in soup.find_all('textarea', {'name': re.compile(r'_\..*Script.*')})]
        return BuildReplay(scripts=scripts)
  • The BUILD_REPLAY endpoint template used to construct the URL for fetching build replay data.
    BUILD_REPLAY = RestEndpoint('{folder}job/{name}/{number}/replay')
Behavior2/5

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

No annotations are provided, so the description must carry the burden. It only states that the tool returns a list of scripts, but does not disclose any behavioral traits such as whether it is a read-only operation, authentication requirements, or rate limits. Minimal transparency beyond purpose.

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 brief and structured with 'Args' and 'Returns' sections. Every sentence is necessary and front-loaded with the purpose. No redundancy or unnecessary detail.

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?

Given that there is an output schema (not shown in detail but present), the description appropriately notes that the return is a list of scripts. The inputs are fully explained. The tool is simple, and the description covers the essential aspects, though it could specify what 'scripts' refers to (e.g., build steps).

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?

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'fullname' is the job's fullname and 'number' is the build number (defaults to last if None). This goes beyond the schema's type/requirement information.

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 it gets scripts used in a specific build in Jenkins, using the verb 'get' and specifying the resource 'build scripts'. It distinguishes from sibling tools like get_build_artifact and get_build_console_output by focusing specifically on scripts.

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 explains the parameters and their roles (fullname required, number optional defaults to last build), which guides usage. However, it does not explicitly state when not to use this tool or mention alternatives, though the context of siblings makes the purpose clear.

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