Skip to main content
Glama

get_execution

Read-onlyIdempotent

Retrieve detailed information about a specific Rundeck execution, including status, timing, node results, and arguments used.

Instructions

Get detailed information about a specific execution.

Returns the full execution details including status, timing, node results,
and the arguments used.

Args:
    execution_id: The execution ID (integer)

Returns:
    Execution object with full details

Examples:
    >>> execution = get_execution(12345)
    >>> print(execution.status)
    'succeeded'
    >>> print(execution.duration_seconds)
    45.2

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
execution_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe execution ID
jobNoReference to the job (None for adhoc executions)
hrefNoAPI URL for this execution
userYesUser who started this execution
statusYesExecution status
projectYesThe project name
argstringNoThe argument string used for this execution
permalinkNoWeb UI URL for this execution
date-endedNoWhen the execution ended (None if still running)
descriptionNoExecution description
failedNodesNoList of nodes that failed
date-startedNoWhen the execution started
successfulNodesNoList of nodes that succeeded

Implementation Reference

  • The get_execution tool handler: retrieves detailed execution information from Rundeck API via HTTP GET /execution/{execution_id} and parses the response.
    def get_execution(execution_id: int) -> Execution:
        """Get detailed information about a specific execution.
    
        Returns the full execution details including status, timing, node results,
        and the arguments used.
    
        Args:
            execution_id: The execution ID (integer)
    
        Returns:
            Execution object with full details
    
        Examples:
            >>> execution = get_execution(12345)
            >>> print(execution.status)
            'succeeded'
            >>> print(execution.duration_seconds)
            45.2
        """
        client = get_client()
        response = client.get(f"/execution/{execution_id}")
    
        return _parse_execution(response)
  • Pydantic schema/model for the Execution return type of get_execution tool, including fields, validators, and computed properties.
    class Execution(BaseModel):
        """A job execution instance.
    
        Represents a single run of a job, including its status, timing, and results.
        """
    
        id: int = Field(description="The execution ID")
        href: str | None = Field(default=None, description="API URL for this execution")
        permalink: str | None = Field(default=None, description="Web UI URL for this execution")
        status: ExecutionStatus = Field(description="Execution status")
        project: str = Field(description="The project name")
        job: JobReference | None = Field(default=None, description="Reference to the job (None for adhoc executions)")
        user: str = Field(description="User who started this execution")
        date_started: datetime | None = Field(
            default=None,
            alias="date-started",
            description="When the execution started",
        )
        date_ended: datetime | None = Field(
            default=None,
            alias="date-ended",
            description="When the execution ended (None if still running)",
        )
        argstring: str | None = Field(
            default=None,
            description="The argument string used for this execution",
        )
        description: str | None = Field(default=None, description="Execution description")
        successful_nodes: list[str] | None = Field(
            default=None,
            alias="successfulNodes",
            description="List of nodes that succeeded",
        )
        failed_nodes: list[str] | None = Field(
            default=None,
            alias="failedNodes",
            description="List of nodes that failed",
        )
    
        @field_validator("date_started", "date_ended", mode="before")
        @classmethod
        def parse_date_dict(cls, v: Any) -> datetime | None:
            """Parse date from Rundeck's dict format or ISO string."""
            if v is None:
                return None
            if isinstance(v, datetime):
                return v
            if isinstance(v, dict):
                # Rundeck returns {"unixtime": 1234567890, "date": "..."}
                if "unixtime" in v:
                    return datetime.fromtimestamp(v["unixtime"] / 1000)
                if "date" in v:
                    return datetime.fromisoformat(v["date"].replace("Z", "+00:00"))
            if isinstance(v, str):
                return datetime.fromisoformat(v.replace("Z", "+00:00"))
            return None
    
        @computed_field
        @property
        def duration_seconds(self) -> float | None:
            """Calculate duration in seconds."""
            if self.date_started and self.date_ended:
                return (self.date_ended - self.date_started).total_seconds()
            return None
    
        @computed_field
        @property
        def execution_summary(self) -> str:
            """Generate a human-readable summary of this execution."""
            parts = [f"Execution #{self.id}: {self.status.upper()}"]
    
            if self.job:
                parts.append(f"Job: {self.job.name}")
                if self.job.group:
                    parts[-1] = f"Job: {self.job.group}/{self.job.name}"
    
            if self.user:
                parts.append(f"User: {self.user}")
    
            if self.duration_seconds is not None:
                parts.append(f"Duration: {self.duration_seconds:.1f}s")
    
            if self.argstring:
                parts.append(f"Args: {self.argstring}")
    
            return " | ".join(parts)
    
        @computed_field
        @property
        def type(self) -> Literal["execution"]:
            return "execution"
  • MCP server registration loop that adds get_execution (via read_tools list) as a read-only tool with appropriate annotations.
    # Register read-only tools (always available)
    for tool in read_tools:
        add_read_only_tool(mcp, tool)
  • Definition of read_tools list that includes get_execution for registration in MCP server.
    read_tools = [
        # Jobs
        list_jobs,
        get_job,
        # Executions
        list_executions,
        get_execution,
        get_execution_output,
  • Helper function to parse raw API response data into Execution model instance.
    def _parse_execution(data: dict[str, Any]) -> Execution:
        """Parse execution data from API response.
    
        Args:
            data: Raw API response data
    
        Returns:
            Parsed Execution model
        """
        # Parse job reference if present
        job_data = data.get("job")
        job_ref = None
        if job_data:
            job_ref = JobReference(
                id=job_data.get("id", ""),
                name=job_data.get("name", ""),
                group=job_data.get("group"),
                project=job_data.get("project", data.get("project", "")),
                href=job_data.get("href"),
                permalink=job_data.get("permalink"),
            )
    
        return Execution(
            id=data["id"],
            href=data.get("href"),
            permalink=data.get("permalink"),
            status=data.get("status", "running"),
            project=data.get("project", ""),
            job=job_ref,
            user=data.get("user", "unknown"),
            date_started=data.get("date-started"),
            date_ended=data.get("date-ended"),
            argstring=data.get("argstring"),
            description=data.get("description"),
            successful_nodes=data.get("successfulNodes"),
            failed_nodes=data.get("failedNodes"),
        )
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds value by specifying the return content ('full execution details including status, timing, node results, and the arguments used'), which provides useful context beyond annotations. No contradiction with annotations exists.

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 well-structured with clear sections (purpose, returns, args, examples), front-loaded with the core purpose, and every sentence adds value without redundancy. It efficiently conveys necessary information in a compact format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter), rich annotations (covering safety and idempotency), and the presence of an output schema (implied by 'Returns: Execution object'), the description is complete enough. It explains the purpose, parameter, return content, and includes examples, addressing all key aspects without overloading.

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 0%, but the description includes an 'Args' section that documents the single parameter (execution_id) as 'The execution ID (integer)', adding meaning beyond the schema's basic type. However, it does not elaborate on format constraints or examples beyond the integer type, so it partially compensates for the low 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 verb ('Get') and resource ('detailed information about a specific execution'), distinguishing it from siblings like list_executions (which lists multiple executions) and get_execution_output (which focuses on output rather than full details). The purpose is specific 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by specifying it retrieves details for 'a specific execution' (via execution_id), but it does not explicitly state when to use this tool versus alternatives like list_executions or get_execution_output. No exclusions or prerequisites are mentioned, leaving some ambiguity for the agent.

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/justynroberts/rundeck-mcp'

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