Hatchet MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HATCHET_CLIENT_TOKEN | Yes | Your Hatchet client token |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_workflowsA | List all registered Hatchet workflows. Returns a list of workflows with their IDs, names, and descriptions. |
| list_runsA | List workflow runs with optional filters. Args: workflow_name: Filter by workflow name (e.g., 'qa-workflow', 'embed-workflow') status: Filter by status ('queued', 'running', 'completed', 'failed', 'cancelled') since_hours: How many hours back to search (default: 24) limit: Maximum number of runs to return (default: 50) Returns a list of runs with their status, metadata, and timing info. |
| get_run_statusB | Get the current status of a specific workflow run. Args: run_id: The ID of the workflow run Returns the run's current status and details. |
| get_run_resultB | 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. |
| get_queue_metricsA | Get queue depth and job counts by status. Args: workflow_name: Optional workflow name to filter metrics Returns counts of jobs in each status (queued, running, completed, failed). |
| search_runsA | Search runs by metadata key-value pairs. Common metadata keys:
Args: metadata_key: The metadata key to search (e.g., 'audit_id') metadata_value: The value to match status: Optional status filter since_hours: How many hours back to search (default: 24) limit: Maximum runs to return (default: 50) Returns matching runs with their full metadata. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Most tools have distinct purposes focused on different aspects of workflow management (metrics, runs, workflows), but get_run_result and get_run_status could potentially overlap in some use cases since both retrieve information about specific runs. The descriptions help clarify that get_run_result focuses on output data while get_run_status focuses on current status, but an agent might still need to carefully choose between them.
All tools follow a consistent verb_noun pattern with clear, descriptive names. The naming convention is uniform throughout: get_queue_metrics, get_run_result, get_run_status, list_runs, list_workflows, and search_runs. This consistency makes it easy for agents to understand and predict tool functionality.
Six tools is an appropriate number for a workflow management server. This provides comprehensive coverage without being overwhelming. The tools cover metrics retrieval, run status checking, run listing/searching, and workflow listing - a well-scoped set that addresses the core needs of interacting with a workflow system.
The tool set provides strong read/search capabilities for workflows and runs, with good coverage for querying metrics, status, results, and metadata. Minor gaps exist in write operations (no tools for creating/triggering workflows or managing runs), but for a monitoring/query-focused server, the surface is reasonably complete for its apparent purpose.