Living Stack MCP — Retired Beta Listing
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LIVING_STACK_STATE_DIR | No | Directory for state storage. Defaults to ~/.living-stack-mcp/state. | ~/.living-stack-mcp/state |
| LIVING_STACK_ALLOWED_ROOTS | No | Explicit roots allowed for release-manifest verification. |
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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| livingstack.statusA | Describe this standalone Living Stack MCP server, its enforced boundaries, configured risk policy, and available capability classes. This does not inspect a customer session. |
| livingstack.session_startA | Create an isolated capability session with an immutable scope, goal, retention period, and hard between-action budget ceiling. |
| livingstack.session_statusA | Read the current scope hash, lifecycle status, budget, pending authorization count, and ledger integrity for one session. |
| livingstack.context_putA | Add redacted, provenance-labeled context to the current session. Stored context remains historical until independently reverified. |
| livingstack.retrieve_contextA | Search only the current session context using deterministic lexical retrieval and return provenance plus receipt hashes. |
| livingstack.authorize_actionA | Evaluate an intended action against server-owned risk policy and the session budget. The default policy denies external and destructive risks, and this server never executes the action itself. |
| livingstack.record_outcomeA | Consume one prior authorization, reconcile reserved cost, and append a tamper-evident outcome with typed evidence references. |
| livingstack.check_claimC | Determine whether a completion, working, integrity, or deployment claim has fresh successful typed evidence in the verified session ledger. |
| livingstack.checkpoint_saveB | Redact and persist a bounded state object bound to the session scope and current ledger lineage. |
| livingstack.checkpoint_loadB | Load a checkpoint only after session, scope, state hash, expiry, ledger integrity, and lineage checks pass. |
| livingstack.trace_reportA | Verify the event chain and return aggregate event, outcome, budget, and lifecycle data without raw private payloads. |
| livingstack.trace_exportA | Convert the verified lifecycle ledger into metadata-only OTLP/JSON trace data and sign the exact export with the local workspace Ed25519 identity. Raw context, goals, targets, summaries, and checkpoint state are excluded. |
| livingstack.verify_releaseA | Freshly hash each declared file from a JSON manifest under a host-configured allowed root. Paths outside configured roots remain unresolved. |
| livingstack.session_closeA | Mark a session closed while preserving its tamper-evident evidence history. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Living Stack MCP capabilities | Product capabilities, boundaries, and integration contract. |
TDQS
Scored across 14 tools
Each tool targets a distinct resource or lifecycle step: session status vs server status, context retrieval vs checkpoint loading, and trace report vs trace export are all clearly separated by their descriptions. No two tools appear to perform the same operation.
All tools share the livingstack prefix and snake_case, but the object/verb order is inconsistent: session_start, context_put, and checkpoint_save are noun-verb while retrieve_context, authorize_action, and check_claim are verb-noun. Status, session_status, trace_report, and trace_export are noun-like, so no single naming pattern dominates.
Fourteen tools is within the ideal 3-15 range and each tool maps to a distinct capability class such as session lifecycle, context management, authorization, checkpointing, tracing, and release verification. The count feels deliberately scoped rather than padded.
The core session, context, authorization, outcome, checkpoint, trace, and release verification lifecycle is well covered. Minor gaps exist: context_put mentions independent reverification but no explicit tool exposes that operation, and there is no session-listing or session-deletion tool beyond close.