Hatchet MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.6/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it returns 'current status and details' implying a read operation, but doesn't specify possible status values (running/completed/failed), whether data is real-time or cached, or what 'details' includes.
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?
Front-loaded with clear purpose sentence. 'Args' and 'Returns' sections are structured and functional given lack of schema/output descriptions. No redundant or wasted sentences, though docstring-style formatting is slightly verbose.
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 read operation. Mentions return value (status/details) to compensate for missing output schema, and describes the parameter to compensate for 0% schema coverage. However, sibling tool confusion (result vs status) leaves a gap that should be addressed.
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 has 0% description coverage (only 'title': 'Run Id'). Description adds 'The ID of the workflow run' which provides basic context, but with only one parameter and no schema docs, it could elaborate on ID format or source (e.g., obtained from list_runs).
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?
Clear verb+resource ('Get the current status of a specific workflow run'), but lacks differentiation from sibling 'get_run_result' (status vs. output data) and 'list_runs' (specific vs. list).
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?
No guidance on when to use this versus 'get_run_result' (which also takes a run_id) or when to prefer 'list_runs' followed by this call. No prerequisites mentioned (e.g., obtaining run_id from list_runs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must carry the full burden of behavioral disclosure. It partially satisfies this by specifying return fields (IDs, names, descriptions), but omits critical safety characteristics (read-only nature, idempotency), pagination behavior, or performance implications of listing 'all' workflows.
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?
Extremely efficient two-sentence structure: first sentence declares purpose, second declares return payload. Every word earns its place with no redundancy or extraneous text.
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?
Appropriate for a zero-parameter list operation with existing output schema. Previewing the return fields (IDs, names, descriptions) provides helpful context without duplicating the full schema. Minor gap: lacks mention of pagination behavior or maximum result limits typical for unfiltered 'list all' endpoints.
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?
Input schema contains zero parameters, establishing a baseline score of 4 per evaluation rules. The description appropriately does not invent parameter documentation where none exist.
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?
Uses specific verb 'List' with clear resource 'registered Hatchet workflows'. Effectively distinguishes from siblings like 'list_runs' and 'search_runs' through explicit use of 'workflows' terminology, though could be strengthened by explicitly contrasting workflow definitions versus run executions.
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?
Contains no guidance on when to select this tool over alternatives. Does not clarify the distinction between retrieving workflow definitions (this tool) versus querying run executions (list_runs/search_runs siblings), leaving the agent to infer from naming alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It successfully documents default values (24 hours, 50 limit) and return structure ('status, metadata, and timing info'), but omits critical behavioral details like result ordering (chronological?), pagination mechanics beyond the limit parameter, and whether archived/completed runs are included indefinitely or time-boxed.
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?
The docstring-style format with explicit 'Args' and 'Returns' sections is clear and pragmatic given the schema deficiencies. While the Args block is lengthy, every line is necessary to compensate for the undocumented schema. No tautology or repetition of the tool name.
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 existence of an output schema (which handles return value details) and the comprehensive Args documentation, the description is largely complete for a filtering tool. The only notable gaps are the lack of sibling differentiation and absence of result ordering guarantees or time-window behavior explanations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Excellent compensation for 0% schema description coverage. The Args section provides detailed semantics for all 4 parameters: workflow_name includes realistic examples ('qa-workflow'), status enumerates valid values not present in the schema enum, and since_hours/limit explain units and defaults. This adds substantial meaning beyond the bare schema titles.
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?
The description clearly states the verb ('List') and resource ('workflow runs') with scope ('with optional filters'). However, it fails to distinguish from the sibling tool 'search_runs', leaving ambiguity about which to use for filtering vs searching.
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?
No guidance is provided on when to use this tool versus siblings like 'search_runs' or 'get_run_status'. The description does not specify prerequisites, expected query patterns, or when 'list_runs' is insufficient and 'search_runs' should be preferred instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 successfully discloses the return structure (counts by status: queued, running, completed, failed) and the filtering behavior. However, it lacks safety/performance notes (e.g., whether this is cached, rate limits, or real-time vs. eventually consistent data).
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?
Uses an efficient docstring format (Args/Returns) that front-loads the purpose and provides structured supplemental detail. Every sentence earns its place; the description is appropriately compact for a single-parameter tool.
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 low complexity (1 optional parameter, no nested objects) and lack of output schema, the description adequately compensates by specifying the return format (counts by four status categories). It is complete enough for an agent to invoke successfully.
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 schema has 0% description coverage (only types and title provided). The description compensates well by stating the parameter is 'Optional workflow name to filter metrics,' adding both semantic meaning (filtering) and cardinality (optional) that the JSON schema structure alone does not convey.
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?
The opening line 'Get queue depth and job counts by status' provides a clear verb and specific resource. However, it does not explicitly differentiate from sibling tools like list_runs or get_run_status, which also deal with job status but at a per-run rather than aggregate queue level.
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 Args section explains the optional workflow_name filter provides filtering capability, implying this is used for aggregate monitoring. However, it lacks explicit guidance on when to choose this over list_runs (aggregate counts vs. individual job listings) or mention of prerequisites like workflow existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions time-bounded search (since_hours) and that it returns full metadata, but does not explicitly confirm read-only nature, rate limits, or behavior when no matches exist.
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?
Well-structured with distinct sections for purpose, common keys, and arguments. Metadata key list is domain-specific and valuable. Slightly verbose but every section earns its place by aiding correct invocation.
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?
With output schema present, description adequately covers all inputs and provides crucial domain context (common keys). Sufficient for correct invocation though could clarify what constitutes a 'run' in this system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the Args section fully compensates by documenting all 5 parameters with clear semantics, optionality, and default values (e.g., since_hours defaults to 24).
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?
Clear specific verb (Search) + resource (runs) + method (by metadata key-value pairs). Effectively distinguishes from sibling list_runs (unfiltered listing) and get_run_* tools (direct ID lookup).
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?
Provides valuable 'Common metadata keys' section (audit_id, patient_id, etc.) implying search capabilities, but does not explicitly contrast with list_runs or state when to prefer this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![hatchet-mcp MCP server](https://glama.ai/mcp/servers/GJakobi/hatchet-mcp/badges/card.svg)](https://glama.ai/mcp/servers/GJakobi/hatchet-mcp)

Score Badge

Copy to your README.md:

[![hatchet-mcp MCP server](https://glama.ai/mcp/servers/GJakobi/hatchet-mcp/badges/score.svg)](https://glama.ai/mcp/servers/GJakobi/hatchet-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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