Skip to main content
Glama
GJakobi

Hatchet MCP Server

by GJakobi

get_run_result

Retrieve the output or current status of a completed Hatchet workflow run using its run ID to monitor execution results.

Instructions

Get the result/output of a completed workflow run.

Args: run_id: The ID of the workflow run

Returns the run's output data if completed, or current status if still running.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
run_idYes

Implementation Reference

  • The handler function 'get_run_result' which retrieves the result of a workflow run using the Hatchet SDK.
    async def get_run_result(run_id: str) -> dict:
        """
        Get the result/output of a completed workflow run.
    
        Args:
            run_id: The ID of the workflow run
    
        Returns the run's output data if completed, or current status if still running.
        """
        try:
            hatchet = get_hatchet_client()
            result = await hatchet.runs.aio_get_result(run_id)
            return {"run_id": run_id, "result": result}
        except Exception as e:
            return {"error": str(e), "run_id": run_id}
  • Tool registration for 'get_run_result' using the @mcp.tool() decorator.
    @mcp.tool()
    async def get_run_result(run_id: str) -> dict:
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the important behavioral trait of returning current status instead of output when the run is incomplete, but omits safety characteristics (read-only nature), error handling, or rate limiting that agents need when annotations are absent.

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?

Uses standard docstring format with Args/Returns sections that front-load the purpose before implementation details. Three information-dense sentences with no filler, though the structured labels slightly reduce immediate scanability for LLMs compared to plain prose.

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?

Adequate for a single-parameter retrieval tool with no output schema: it explains the dual return format (output vs status). However, given the existence of 'get_run_status', the description should clarify why both tools exist and their specific domains.

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 coverage is 0% (only 'title' present, no descriptions). The description compensates with 'The ID of the workflow run' in the Args section, which adds minimal semantic meaning beyond the parameter name itself, but does not specify format constraints, validity rules, or how to obtain the ID.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool retrieves result/output of a completed workflow run using specific verb 'Get' and resource 'result/output'. However, it fails to explicitly distinguish from sibling tool 'get_run_status', which creates ambiguity about when to use each.

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?

Describes conditional behavior (returns output if completed, status if running), implying usage patterns, but provides no explicit guidance on when to prefer this over 'get_run_status' or other sibling tools. The overlap with 'get_run_status' remains unresolved.

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/GJakobi/hatchet-mcp'

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