Skip to main content
Glama

get_all_nodes

Retrieve a list of all Jenkins nodes to monitor build agents and manage distributed builds.

Instructions

Get all nodes from Jenkins

Returns: A list of all nodes

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The actual tool handler: 'get_all_nodes' registered via @mcp.tool decorator. Calls jenkins(ctx).get_nodes(depth=0) and returns Node model dumps excluding executors.
    @mcp.tool(tags=['read'])
    async def get_all_nodes(ctx: Context) -> list[dict]:
        """Get all nodes from Jenkins
    
        Returns:
            A list of all nodes
        """
        return [node.model_dump(exclude={'executors'}) for node in jenkins(ctx).get_nodes(depth=0)]
  • Tool registration via @mcp.tool(tags=['read']) decorator on the get_all_nodes async function.
    @mcp.tool(tags=['read'])
    async def get_all_nodes(ctx: Context) -> list[dict]:
  • Jenkins.get_nodes() method that makes the REST API call to 'computer/api/json?depth={depth}' endpoint and deserializes the 'computer' field into Node objects.
    def get_nodes(self, *, depth: int = 0) -> list[Node]:
        """Get a list of nodes connected to the Master
    
        Args:
            depth: The depth of the information to retrieve.
    
        Returns:
            A list of Node objects.
        """
        response = self.request('GET', rest_endpoint.NODES(depth=depth))
        return [Node.model_validate(node) for node in response.json()['computer']]
  • REST endpoint definition for NODES: 'computer/api/json?depth={depth}' used by get_nodes.
    NODES = RestEndpoint('computer/api/json?depth={depth}')
  • Node Pydantic model with fields displayName, offline, executors. The handler excludes executors via model_dump(exclude={'executors'}).
    class Node(BaseModel):
        displayName: str
        offline: bool
    
        executors: list['NodeExecutor']
Behavior2/5

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It merely states 'Returns a list of all nodes' without addressing permissions, side effects, or rate limits. The agent receives minimal insight into behavior beyond the return value.

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 extremely concise: two sentences totaling 10 words. It front-loads the core purpose immediately and contains no unnecessary language.

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 the tool's simplicity (no parameters, output schema exists) and the presence of an output schema, the description adequately covers what the tool does. However, it lacks any behavioral context that would help an agent decide when to call it.

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 no parameters and 100% schema description coverage. The description adds no param info, which is acceptable as there are none. Baseline 4 for zero-parameter tools, though no extra value beyond schema.

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?

Description clearly states 'Get all nodes from Jenkins', specifying verb and resource. This differentiates from sibling tools like 'get_node' and 'get_node_config' which operate on individual nodes or their config.

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 does not provide any guidance on when to use this tool versus alternatives, such as when a specific node is needed instead of all nodes. No context on prerequisites or limitations is given.

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