Temporal MCP Server
# Temporal MCP Server
## Overview
This is a Model Context Protocol (MCP) server that provides tools for interacting with Temporal workflow orchestration. It enables AI assistants and other MCP clients to manage Temporal workflows, schedules, and workflow executions through a standardized interface. The server supports both local and remote Temporal instances.
Read more on the [Temporal Code Exchange](https://temporal.io/code-exchange/temporal-mcp-server)
## Distributions
- PyPI - https://pypi.org/project/temporal-mcp-server/
- Docker - https://hub.docker.com/r/mcp/temporal
## Tools
### Workflow Execution
- **`start_workflow`** - Start a new Temporal workflow execution with specified parameters, workflow ID, and task queue
- **`get_workflow_result`** - Retrieve the result of a completed workflow execution
- **`describe_workflow`** - Get detailed information about a workflow execution including status, timing, and metadata
- **`list_workflows`** - List workflow executions based on a query filter with pagination support (limit/skip)
- **`get_workflow_history`** - Retrieve the complete event history of a workflow execution
- **`get_workflow_event`** - Retrieve a single workflow history event with decoded payload fields when present
### Workflow Control
- **`query_workflow`** - Query a running workflow for its current state without affecting execution
- **`signal_workflow`** - Send a signal to a running workflow to change its behavior or provide data
- **`cancel_workflow`** - Request cancellation of a running workflow execution
- **`terminate_workflow`** - Forcefully terminate a workflow execution with a reason
- **`continue_as_new`** - Signal a workflow to continue as new (restart with new inputs while preserving history link)
### Batch Operations
- **`batch_signal`** - Send a signal to multiple workflows matching a query (configurable batch size)
- **`batch_cancel`** - Cancel multiple workflows matching a query (configurable batch size)
- **`batch_terminate`** - Terminate multiple workflows matching a query with a specified reason (configurable batch size)
### Schedule Management
- **`create_schedule`** - Create a new schedule for periodic workflow execution using cron expressions
- **`list_schedules`** - List all schedules with pagination support (limit/skip)
- **`describe_schedule`** - Get detailed configuration and runtime information about a schedule, including its spec, action, state, recent executions, and upcoming action times
- **`pause_schedule`** - Pause a schedule to temporarily stop workflow executions
- **`unpause_schedule`** - Resume a paused schedule
- **`delete_schedule`** - Permanently delete a schedule
- **`trigger_schedule`** - Manually trigger a scheduled workflow immediately
## Temporal Documentation
For more information about Temporal, refer to the official Temporal documentation:
- **Temporal Documentation**: https://docs.temporal.io/
- **Workflows**: https://docs.temporal.io/workflows
- **Activities**: https://docs.temporal.io/activities
- **Python SDK**: https://docs.temporal.io/dev-guide/python
## VS Code MCP Config
Add a `.vscode/mcp.json` file to your workspace. Choose the approach that fits your setup.
### Docker (environment variables)
Recommended when running via Docker. Configuration is passed through environment variables.
```json
{
"servers": {
"temporal": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "TEMPORAL_HOST",
"-e", "TEMPORAL_NAMESPACE",
"-e", "TEMPORAL_TLS_ENABLED",
"-e", "TEMPORAL_TLS_CLIENT_CERT_PATH",
"-e", "TEMPORAL_TLS_CLIENT_KEY_PATH",
"-e", "TEMPORAL_API_KEY",
"mcp/temporal"
],
"env": {
"TEMPORAL_HOST": "localhost:7233",
"TEMPORAL_NAMESPACE": "default",
"TEMPORAL_TLS_ENABLED": "false",
"TEMPORAL_TLS_CLIENT_CERT_PATH": "/path/to/client.pem",
"TEMPORAL_TLS_CLIENT_KEY_PATH": "/path/to/client.key",
"TEMPORAL_API_KEY": "your-api-key"
}
}
}
}
```
### Python via uvx (CLI arguments)
Recommended when running from PyPI via [`uvx`](https://docs.astral.sh/uv/guides/tools/). No local install required — `uvx` fetches and runs the package automatically. Configuration is passed as CLI arguments.
```json
{
"servers": {
"temporal": {
"command": "uvx",
"args": [
"temporal-mcp-server",
"--host", "localhost:7233",
"--namespace", "default",
"--tls-enabled", "false",
"--tls-cert", "/path/to/client.pem",
"--tls-key", "/path/to/client.key",
"--api-key", "your-api-key"
]
}
}
}
```
### Configuration Options
| Option | CLI Argument | Environment Variable | Default |
|--------|-------------|----------------------|---------|
| Temporal host | `--host` | `TEMPORAL_HOST` | `localhost:7233` |
| Namespace | `--namespace` | `TEMPORAL_NAMESPACE` | `default` |
| Allowed namespaces | — | `TEMPORAL_ALLOWED_NAMESPACES` | configured namespace only |
| TLS | `--tls-enabled` | `TEMPORAL_TLS_ENABLED` | auto-detect |
| mTLS cert path | `--tls-cert` | `TEMPORAL_TLS_CLIENT_CERT_PATH` | — |
| mTLS key path | `--tls-key` | `TEMPORAL_TLS_CLIENT_KEY_PATH` | — |
| API key | `--api-key` | `TEMPORAL_API_KEY` | — |
CLI arguments take precedence over environment variables. When `TEMPORAL_API_KEY` is set, TLS is enabled automatically. When mTLS cert/key paths are provided, TLS is also enabled automatically.
Every tool accepts an optional `namespace` argument. If omitted, the server uses `--namespace`, then `TEMPORAL_NAMESPACE`, then `default`. Runtime overrides are disabled by default: set `TEMPORAL_ALLOWED_NAMESPACES` to a comma-separated allowlist such as `default,payments`, or set it to `*` to permit any namespace reachable through the configured Temporal host and credentials. A finite allowlist must include the configured default namespace.
## Development
### Running Tests
Install development dependencies:
```bash
pip install -r requirements-dev.txt
```
Run the test suite:
```bash
pytest test.py -v
```
### Building the Docker Image
```bash
docker build -t mcp/temporal:latest .
```
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.