Temporal MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TEMPORAL_HOST | No | Temporal server host and port | localhost:7233 |
| TEMPORAL_API_KEY | No | API key for authentication (enables TLS automatically) | |
| TEMPORAL_NAMESPACE | No | Temporal namespace | default |
| TEMPORAL_TLS_ENABLED | No | Enable TLS (auto-detected if API key or mTLS cert/key provided) | false |
| TEMPORAL_TLS_CLIENT_KEY_PATH | No | Path to mTLS client key | |
| TEMPORAL_TLS_CLIENT_CERT_PATH | No | Path to mTLS client certificate |
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| start_workflowC | Start a new Temporal workflow execution |
| query_workflowC | Query a running workflow for its current state |
| signal_workflowC | Send a signal to a running workflow |
| cancel_workflowC | Cancel a running workflow execution |
| get_workflow_resultB | Get the result of a completed workflow |
| describe_workflowC | Get detailed information about a workflow execution |
| list_workflowsC | List workflow executions based on a query. Specify 'limit' to control the number of results (default: 100, max recommended: 1000). Use 'skip' to paginate through results. |
| terminate_workflowC | Forcefully terminate a workflow execution |
| get_workflow_historyC | Get the complete event history of a workflow execution. Specify 'limit' to control the number of events (default: 1000). |
| get_workflow_eventB | Get a single workflow history event with decoded payload fields when present |
| start_activityC | Start a new standalone Temporal activity execution |
| execute_activityC | Execute a standalone Temporal activity and wait for result |
| get_activity_resultB | Get the result of a standalone activity |
| describe_activityC | Get detailed information about a standalone activity execution |
| list_activitiesC | List standalone activity executions based on a query. Specify 'limit' to control results and 'skip' for pagination. |
| count_activitiesB | Count standalone activity executions matching a query |
| cancel_activityC | Cancel a running standalone activity execution |
| terminate_activityC | Forcefully terminate a standalone activity execution |
| batch_signalB | Send a signal to multiple workflows matching a query. Specify 'limit' to control batch size (default: 100). |
| batch_cancelC | Cancel multiple workflows matching a query with concurrent processing for speed. Use 'concurrency' to control parallel operations (default: 50). |
| batch_terminateC | Terminate multiple workflows matching a query. Specify 'limit' to control batch size (default: 100). |
| batch_cancel_activitiesC | Cancel multiple standalone activities matching a query with concurrent processing for speed. Use 'concurrency' to control parallel operations (default: 50). |
| batch_terminate_activitiesC | Terminate multiple standalone activities matching a query. Specify 'limit' to control batch size (default: 100). |
| create_scheduleC | Create a new schedule for periodic workflow execution |
| list_schedulesA | List all schedules. Specify 'limit' to control the number of results (default: 100). Use 'skip' to paginate through results. |
| pause_scheduleC | Pause a schedule |
| unpause_scheduleB | Resume a paused schedule |
| delete_scheduleC | Delete a schedule |
| trigger_scheduleC | Manually trigger a scheduled workflow immediately |
| describe_scheduleB | Get detailed configuration and runtime information about a schedule, including its spec, action, state, recent executions, and upcoming action times |
| continue_as_newA | Signal a workflow to continue as new (restart with new inputs while preserving history link) |
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 31 tools
Each tool targets a distinct Temporal resource and action: workflow lifecycle, activity lifecycle, batch operations, and schedules are clearly separated. Overlaps like start_activity vs execute_activity and get_workflow_event vs get_workflow_history are differentiated by descriptions. No two tools appear to do the same thing.
Tool names consistently use snake_case with a predictable verb_noun pattern (e.g., start_workflow, get_workflow_result, batch_cancel, create_schedule). Minor exceptions like continue_as_new and batch_signal are still readable and match Temporal terminology. No mixed conventions.
31 tools is heavy for an MCP server, though Temporal is a complex platform. Some consolidation is possible, such as combining pause_schedule and unpause_schedule into an update operation, and the batch variants add surface area. The count is borderline over-scoped rather than clearly wrong.
Core workflow, activity, batch, and schedule lifecycles are well covered, including start, query, signal, cancel, terminate, list, and describe operations. Minor gaps exist, such as no update_schedule or schedule execution listing, but agents can work around these for most tasks.