semantic-saga-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SAGA_HOST | No | Host for SSE transport. | |
| SAGA_PORT | No | Port for SSE transport. | |
| SAGA_DATABASE | No | Path to the SQLite database file. Alternative to --database. | |
| SAGA_TRANSPORT | No | Transport type: stdio (default) or sse. | stdio |
| SAGA_ACTIONS_FILE | No | Path to the actions configuration file. Alternative to --actions. |
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
} |
| prompts | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| begin_sagaB | Start a durable transactional workflow. |
| execute_saga_stepC | Immediately execute an action after current governance, schema, and action-policy checks. |
| plan_saga_stepB | Persist a version-pinned workflow node; governance may add an approval gate or reject the plan. |
| run_ready_stepsC | Re-evaluate current governance and execute ready DAG nodes in bounded dependency waves. |
| approve_saga_stepC | Approve or reject a workflow node; approvals are subject to tenant governance while rejection remains fail-safe. |
| retry_saga_stepC | Return a failed/rejected/blocked workflow node to scheduling after current governance checks. |
| checkpoint_sagaC | Persist a named workflow checkpoint and operator/agent-provided checkpoint data. |
| commit_sagaC | Commit a completed saga after current tenant governance checks. |
| rollback_sagaC | Compensate saga steps in reverse order; rollback remains available as the safety path. |
| trigger_rollbackB | Immediately start compensation after a client-detected failure. |
| get_sagaA | Inspect saga, workflow DAG, checkpoints, action versions, results, approvals, and recovery state. |
| get_saga_timelineC | Inspect a payload-safe timeline combining steps, workflow nodes, audit evidence, and integrity status. |
| get_audit_eventsC | Read append-only audit events without exposing action inputs, results, or secret material. |
| verify_audit_chainC | Verify the per-saga SHA-256 audit hash chain. |
| get_policy_statusB | Inspect the effective governance backend, revision, budgets, approval threshold, and rule ids for the caller tenant. |
| get_policy_decisionsB | Read durable governance decisions and safety overrides for one tenant-owned saga. |
| list_actionsA | List active action contracts, schemas, semantic effects, risk, hashes, and execution policies. |
| get_actionA | Inspect one registered action contract by id and optional version. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| saga-coordinator | Wrap multi-step side effects in the Saga Coordinator. Inspect actions and governance before execution. Use `plan_saga_step` for governed workflows because policy can require approval based on action risk, tenant rules, or budgets. Obtain approvals when required, then call `run_ready_steps`; current policy is re-evaluated before side effects. Use `get_policy_status` and `get_policy_decisions` for governance evidence, and `get_saga_timeline` plus `verify_audit_chain` for operational review. If a saga enters RECOVERY_REQUIRED, reconcile the external outcome before forcing a retry; rollback remains available for compensation safety. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Most tools have distinct purposes, but several pairs create real ambiguity: trigger_rollback vs rollback_saga both initiate compensation, and execute_saga_step vs run_ready_steps overlap as execution entry points. The descriptions help clarify intent, but an agent could easily select the wrong tool in failure and execution scenarios.
All tools follow a consistent snake_case verb_noun pattern, such as begin_saga, get_saga, plan_saga_step, and commit_saga. The naming is predictable and clearly signals the resource being acted on, with no mixing of conventions.
At 18 tools, the server is on the heavier side but each tool addresses a distinct facet of saga orchestration, governance, audit, and action management. The count feels slightly high but is justified by the domain complexity.
The saga lifecycle is well covered: begin, plan, execute, approve, retry, checkpoint, commit, rollback, and inspect. Minor gaps exist, such as no list_sagas endpoint for enumerating existing sagas and no action registration tools, but agents can work around these limitations.