Skip to main content
Glama
GethosTheWalrus

Temporal MCP Server

by GethosTheWalrus
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_workflow_history

Retrieve the complete event history for a workflow execution to inspect steps, debug failures, or audit runs. Set limit to control events returned (default 1000).

Instructions

Get the complete event history of a workflow execution. Specify 'limit' to control the number of events (default: 1000).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of history events to return (default: 1000)
run_idNoOptional run ID for the workflow execution; omit to target the latest run
namespaceNoTemporal namespace for this operation; omit to use the server default
workflow_idYesThe workflow execution ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.10.1
    • addedInput schema / properties / namespace
      Added value: +{
+  "description": "Temporal namespace for this operation; omit to use the server default",
+  "enum": [
+    "default"
+  ],
+  "minLength": 1,
+  "type": "string"
+}
  2. Addedv1.9.0
  3. Removedv1.5.0
  4. First observedv1.3.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read, but nothing is said about permissions required, whether results are ordered, whether history is truncated/retained, or how the limit interacts with pagination. The default value of 1000 is disclosed, which is the one concrete behavioral fact offered.

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?

Two short sentences, front-loaded with the core purpose and followed by the one parameter worth calling out. No filler, though the second sentence is largely redundant with the schema.

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?

With no annotations and no output schema, the description should explain more about the read operation and its result shape. The fully-covered input schema compensates for parameter documentation, but the missing differentiation from get_workflow_event leaves a real gap for an agent choosing between history-level and event-level retrieval.

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 100%, so the schema already documents all four parameters, including run_id and namespace. The description only restates the 'limit' parameter and its default, adding no syntax or format detail beyond the schema; baseline 3 applies when the schema does the heavy lifting.

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 states a specific verb and resource: 'Get the complete event history of a workflow execution.' That is clear enough for an agent to understand the operation. However, it does not distinguish itself from the sibling get_workflow_event (single event) or query_workflow, so the agent gets no help telling these apart.

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?

There is no statement of when to use this tool versus alternatives such as get_workflow_event or query_workflow, and no preconditions are given. The only guidance is the incidental mention of 'limit', which is a parameter detail rather than usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools