temporal

Overview ¶

Package temporal implements the Temporal workflow orchestration source for the MCP server. It exposes a focused subset of the Temporal Go SDK (go.temporal.io/sdk/client) as MCP tools, covering workflow lifecycle, standalone activity lifecycle, query/signal, batch operations, and schedule management.

All five feature areas share the same clientManager (built in client.go) and feed off the same `connect:` map. Feature-specific tools live in their own handler file:

schedule_handlers.go      → scheduleTools(manager)
workflow_handlers.go      → workflowTools(manager)
activity_handlers.go      → activityTools(manager)
query_signal_handlers.go  → querySignalTools(manager)
batch_handlers.go         → batchTools(manager)

This file is the package wiring: the package doc, the embedded input/output JSON Schemas for every tool, the shared default values, the per-tool description preambles, the unified temporalClient interface (the handler-test seam), the activityHandle interface, the config struct, the connect-map decoder, and the Connect entry point that registers all thirty tools.

The thirty tools are:

// 7 schedule
temporal_create_schedule     (mutating, non-idempotent)  → register a new schedule
temporal_list_schedules      (read-only)                  → discover schedule_id
temporal_describe_schedule   (read-only)                  → full ScheduleDescription
temporal_pause_schedule      (mutating, idempotent)       → gate firing
temporal_unpause_schedule    (mutating, idempotent)       → resume firing
temporal_trigger_schedule    (mutating, non-idempotent)   → fire immediately
temporal_delete_schedule     (mutating, idempotent, destructive) → permanently remove

// 8 workflow
temporal_start_workflow                (mutating, non-idempotent) → new execution
temporal_cancel_workflow               (mutating, idempotent, destructive) → cooperative stop
temporal_terminate_workflow            (mutating, idempotent, destructive) → forced stop
temporal_get_workflow_result           (read-only)              → block on completion
temporal_describe_workflow             (read-only)              → server-side description
temporal_list_workflows                (read-only)              → Visibility query
temporal_get_workflow_history          (read-only)              → event stream
temporal_continue_as_new               (mutating, non-idempotent) → signal CAN

// 8 activity
temporal_start_activity                (mutating, non-idempotent) → new standalone activity
temporal_execute_activity              (mutating, non-idempotent) → start + await
temporal_get_activity_result           (read-only)              → block on completion
temporal_describe_activity             (read-only)              → state + attempt
temporal_list_activities               (read-only)              → Visibility query
temporal_count_activities              (read-only)              → aggregate count
temporal_cancel_activity               (mutating, idempotent, destructive) → cooperative stop
temporal_terminate_activity            (mutating, idempotent, destructive) → forced stop

// 2 query/signal
temporal_query_workflow                (read-only)              → read state via named handler
temporal_signal_workflow               (mutating)               → deliver event

// 5 batch
temporal_batch_signal                  (mutating, non-idempotent) → fan out over Visibility

query

temporal_batch_cancel                  (mutating, idempotent, destructive) → fan out cancel
temporal_batch_terminate               (mutating, idempotent, destructive) → fan out terminate
temporal_batch_cancel_activities       (mutating, idempotent, destructive) → fan out activity

cancel temporal_batch_terminate_activities (mutating, idempotent, destructive) → fan out activity terminate

All thirty share the same `connect:` map: a Temporal frontend address (host:port) and an optional namespace; plus optional TLS materials (api_key, tls_client_cert_path, tls_client_key_path, tls_enabled).