MCP State Sidecar Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DB_PATH | No | Path to the SQLite database file | state_sidecar.db |
| REDIS_URL | No | Redis connection URL | redis://localhost:6379 |
| SIDECAR_HOST | No | IP host to bind the HTTP SSE server | 0.0.0.0 |
| SIDECAR_PORT | No | Port for the HTTP SSE server | 8000 |
| STATE_BACKEND | No | Storage backend: sqlite or redis | sqlite |
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": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| state_setA | Set a key-value pair in the shared state store. The value can be any JSON-serialisable type (dict, list, str, int, …). If ttl_seconds is provided, the entry will expire automatically after that many seconds. Existing entries are overwritten silently. If agent_id is provided, it is recorded in the audit history so the caller can be identified in history_log results. Use a structured key prefix to avoid collisions in multi-workflow deployments, e.g. 'shared:my_namespace:my_key' or simply 'fact_1'. |
| state_getA | Get the value stored under key. Returns found=True and the value if the key exists and has not expired. Returns found=False and value=None if the key is missing or expired. |
| state_deleteA | Delete a key from the state store. Returns ok=True if the key existed and was removed, ok=False if the key was not found (idempotent — safe to call multiple times). |
| state_listA | List all live (non-expired) keys, optionally filtered by prefix. Example: state_list(prefix='fact_') returns all keys starting with 'fact_'. Returns an empty list if no keys match. |
| workflow_createA | Register a new workflow and get back a unique run_id. Call this from the orchestrator before spawning workers. The returned run_id is stored in the sidecar — workers do NOT need to receive it out-of-band; they use workflow_discover() to find it. Tags are arbitrary key-value metadata used for discovery filtering: e.g. tags={'pipeline': 'data-etl', 'customer': 'acme', 'priority': 'high'} Status starts as 'created'. Lifecycle: created → claimed → running → done/failed. |
| workflow_discoverA | Find workflows available for a worker to pick up. Filters by tag key/value pairs (AND semantics) and/or status. Common usage: workflow_discover(status='created') to find unclaimed work. Workers should follow this with workflow_claim() to atomically take ownership of one of the returned workflows. Returns an empty list if no matching workflows are found. |
| workflow_claimA | Atomically claim a workflow for this agent. Only succeeds if the workflow is in 'created' status. If two agents call this concurrently for the same run_id, exactly one will succeed. After claiming, call workflow_checkpoint() as each step completes. If this agent crashes, use workflow_discover() + workflow_claim() from a replacement agent to resume — the sidecar preserves all checkpoint state. Returns claimed=False with a reason if the workflow is already taken or does not exist. |
| workflow_checkpointA | Atomically persist a completed step's output and advance the step counter. Call this immediately after each pipeline step completes, before starting the next one. A replacement agent can resume from the last checkpoint using workflow_resume(). The output can be any JSON-serialisable value (dict, list, str, …). If step N was already checkpointed, calling again with the same step overwrites the stored output (idempotent replay support). |
| workflow_resumeA | Get everything a replacement agent needs to resume a crashed workflow. Returns:
|
| workflow_statusA | Get the current status of a workflow — lightweight alternative to workflow_resume. Returns the status, last completed step, assigned agent, and timestamps. Does NOT return step outputs (use workflow_resume for that). |
| workflow_listA | List all registered workflows (all statuses). For filtered listing, use workflow_discover(status=..., tags={...}) instead. |
| lease_acquireA | Try to acquire an exclusive, TTL-based lease on a named resource. Use this to prevent split-brain when multiple agents could simultaneously work on the same resource. Only one holder can hold the lease at a time. If the current holder crashes, the lease expires automatically after ttl_seconds and another agent can acquire it. Returns acquired=True on success with the expiry timestamp. Returns acquired=False with the current holder's ID on failure. |
| lease_releaseA | Voluntarily release a lease this agent holds. Only the current holder can release their own lease (holder_id must match). No-op if the lease has already expired or belongs to someone else. |
| lease_renewA | Extend an existing lease's TTL while still holding it. Call this periodically from long-running agents to prevent their lease from expiring mid-execution. The holder_id must match the current holder. |
| sidecar_healthA | Check sidecar liveness and get backend diagnostics. |
| sidecar_resetA | Wipe all sidecar state: kv_store, leases, workflows, step_outputs, history, and sessions. |
| session_saveC | Persist the full workflow context for a session_id. |
| session_restoreC | Retrieve the workflow context saved for a session_id. |
| history_logB | Return the last N state-transition records in reverse chronological order. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/askadvaith/MCP-State-Sidecar'
If you have feedback or need assistance with the MCP directory API, please join our Discord server