Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SKILL.state MCP Runtime Initialize a state for my multi-step analysis task"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Traditional LLM agent workflows rely on append-only conversation history [m_1, r_1, o_1, m_2, r_2, ...]. Over long horizons, this design exhibits three fundamental failure modes:
Context Bloat: Token consumption scales monotonically as $\mathcal{O}(T)$, exhausting context windows and elevating per-turn latency.
Reasoning Poisoning: Stale thoughts ($R_t$) and abandoned hypotheses persist in context, biassing subsequent turns.
State Hallucination: Agents lose track of variables, counters, and completed subtasks buried across thousands of tokens of prose.
SKILL.state (arXiv:2608.26263) replaces conversational history with an explicit, formal state tuple $(P, \Sigma_t, O_t)$:
$P$: Immutable skill specification (frozen task instructions).
$\Sigma_t$: Explicit, typed execution state (JSON object).
$O_t$: Latest environment observation.
$R_t$: Chain-of-thought reasoning, discarded at the tool boundary each turn to prevent reasoning loops and context leakage.
Conventional Agent (Append-Only History)
[msg1][R1][O1][msg2][R2][O2][msg3]... ──▶ Context grows monotonically ──▶ Poisoning & Rot
SKILL.state (Formal State Runtime)
Turn t input: (P, Σ_t, O_t)
LLM response: R_t (discarded) + ΔΣ_t (sparse patch) + a_t (action)
Server transition: Σ_{t+1} = Σ_t ⊕ ΔΣ_t ──▶ Execute a_t ──▶ O_{t+1}
Turn t+1 input: (P, Σ_{t+1}, O_{t+1}) [Context size remains O(1) bounded]Related MCP server: Stratum MCP Server
In accordance with standard Model Context Protocol deployment patterns, the server can be run dynamically via npx (recommended for all MCP clients) or installed globally via npm.
Add the server to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"skill-state": {
"command": "npx",
"args": ["-y", "@bub0lehich/skill-state-mcp-server"]
}
}
}Register the server using Anthropic's Claude Code CLI:
claude mcp add skill-state -- npx -y @bub0lehich/skill-state-mcp-serverAdd to .cursor/mcp.json in your project root or open Settings -> Features -> MCP -> Add New MCP Server:
{
"mcpServers": {
"skill-state": {
"command": "npx",
"args": ["-y", "@bub0lehich/skill-state-mcp-server"]
}
}
}Add to cline_mcp_settings.json or your MCP extension configuration:
{
"mcpServers": {
"skill-state": {
"command": "npx",
"args": ["-y", "@bub0lehich/skill-state-mcp-server"]
}
}
}If you prefer installing the binary once onto your system rather than downloading via npx:
npm install -g @bub0lehich/skill-state-mcp-serverOnce installed, reference the binary directly:
{
"mcpServers": {
"skill-state": {
"command": "skill-state-mcp-server"
}
}
}Install as a dependency in your application:
npm install @bub0lehich/skill-state-mcp-serverimport { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { registerSkillStateTools } from "@bub0lehich/skill-state-mcp-server";Used by Claude Desktop, Cursor, and IDEs via stdin/stdout:
npx -y @bub0lehich/skill-state-mcp-serverFor microservice architectures and remote agents:
npx -y @bub0lehich/skill-state-mcp-server --http --port 3211MCP Endpoint: POST http://localhost:3211/mcp
Liveness Probe: GET http://localhost:3211/health
At each step $t$, the agent emits a sparse state patch $\Delta\Sigma_t$. The runtime applies the formal merge operator:
$$\Sigma_{t+1} = \Sigma_t \oplus \Delta\Sigma_t$$
Null serves as an explicit first-class deletion instruction, distinguishing field removal from field omission:
Patch Value in $\Delta\Sigma_t$ | Semantics on Target State $\Sigma$ |
| Deletes the key from $\Sigma$ |
| Inserts or overwrites scalar value |
| Recursively merges nested objects ( |
| Replaces array wholesale (deterministic, avoids positional diffing) |
(omitted) | Preserved (sparse delta) |
// Current State Σ_t
{
"order_id": "ORD-402",
"phase": "inventory_lookup",
"scratchpad": "checking shelf availability...",
"attempts": 1
}
// Patch ΔΣ_t // New State Σ_{t+1}
{ {
"phase": "packing", "order_id": "ORD-402",
"scratchpad": null, ⊕ = "phase": "packing",
"shelf": "shelf_42", "shelf": "shelf_42",
"attempts": 2 "attempts": 2
} }Tool | Parameters | Description |
|
| Boots a new state session and returns the $(P, \Sigma_0, O_0)$ tuple. |
|
| Executes a turn: drops $R_t$, merges $\Delta\Sigma_t$, executes $a_t$, and returns $(P, \Sigma_{t+1}, O_{t+1})$. Rolls back $\Sigma$ on validation error or action rejection. |
|
| Injects external observations or asynchronous environment updates (§5.4 State Recovery). |
|
| Utility to extract $R_t$, $\Delta\Sigma_t$, and $a_t$ from raw fenced ```json blocks (Appendix A.4). |
|
| Finalizes a session and returns the terminal state snapshot. |
Inspection endpoints operate with zero LLM-context cost:
skill-state://{session_id}: Inspect specification $P$, current state $\Sigma_t$, step counter, and metadata.
skill-state://sessions: List active sessions and lifecycle metrics.
skill_state_turn: Standard prompt rendering $(P, \Sigma_t, O_t)$ for tool-calling agents.
skill_state_paper_turn: Canonical single-line JSON format specified in arXiv:2608.26263 Appendix A.4.
SkillExecBench Environment 1)A reference implementation of the benchmark environment from §4.1:
500 independent shelves (shelf_0 through shelf_499).
Domain commands: Store <item> <shelf>, Ship <item> <shelf>, Move <item> <from> <to>, Wait, Complete.
Collision rejection: Storing onto an occupied shelf triggers an environment rejection and transactionally rolls back state mutations (Appendix B.1).
Background telemetry noise: Periodic sensor, battery, and robot telemetry injection to evaluate agent resilience against observation drift (Experiment 2).
Deterministic echo, no-op, synthetic failure, and custom completion actions for testing and integration.
Transactional Rollback: If candidate state $\Sigma_{cand} = \Sigma_t \oplus \Delta\Sigma_t$ fails schema validation or if the executor rejects $a_t$, the runtime rolls back to $\Sigma_t$ without advancing the turn counter (§3.1, §7).
Zero Leakage: Reasoning traces $R_t$ are consumed and dropped in memory; they are never logged, hashed, or returned in subsequent MCP turn payloads.
Concurrency Isolation: Per-session asynchronous mutexes guarantee that concurrent steps within a session are serialized while independent sessions execute concurrently.
Specification Immutability: $P$ is deep-frozen on initialization to prevent drift across long execution horizons.
# Clone repository
git clone https://github.com/Derzkiyboomchik/skill-state-mcp-server.git
cd skill-state-mcp-server
# Install dependencies
npm install
# Run 18 unit and integration tests
npm test
# Run end-to-end demo client (stdio & HTTP)
npm run demo
# Build TypeScript to dist/
npm run build@article{skillstate2026,
title = {SKILL.state: Formal State-Based Execution for Long-Horizon AI Agents},
journal = {arXiv preprint arXiv:2608.26263},
year = {2026}
}MIT © Derzkiyboomchik & bub0lehich
Housekeeping: permanently remove a skill session and its execution state from the runtime. Returns the final Σ snapshot for auditability before deletion.
Inputs: session_id (required).
Advance a skill session by exactly one step t → t+1. INPUT: reasoning_trace R_t (Chain-of-Thought — discarded by the runtime and never stored), state_update ΔΣ_t (sparse JSON patch; null deletes a key), action a_t, and the environment_observation O_t you consumed this turn. LOGIC: validate ΔΣ_t → apply Σ_{t+1} = Σ_t ⊕ ΔΣ_t (null-deletion semantics) → execute a_t → obtain observation O_{t+1}. OUTPUT: the strict next-turn tuple {skill_spec: P, current_state: Σ_{t+1}, latest_observation: O_{t+1}}. Nothing else is retained — no history, no reasoning, no old observations.
Inputs: action (required), session_id (required), state_update (required), reasoning_trace (required), +1 more.
Create a new SKILL.state execution session. Stores the immutable skill specification P and the initial execution state Σ_0, then returns the initial prompt payload (P, Σ_0, boot observation). From this point on, the LLM must treat that payload as its ENTIRE context — there is no message history. Advances happen exclusively through execute_step.
Inputs: session_id (required), skill_specification (required), environment, state_schema, +1 more.
Deliver an asynchronous environment observation / event alert into an active session (e.g. background alerts, customer orders, or external world drift per arXiv:2608.26263 §5.4). Does not advance the step count.
Inputs: session_id (required), observation (required), state_patch.
Parses a raw LLM response string containing free-form reasoning and a fenced ```json block { 'state_patch': {...}, 'action': '...' } per arXiv:2608.26263 Appendix A.4. Separates the reasoning trace R_t (for discarding) from the structured payload, mitigating JSON syntax slips (arXiv:2608.26263 §5.7).
Inputs: response_text (required).
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 5 tools
Each tool addresses a distinct lifecycle operation—create, step, async inject, parse, and close—so boundaries are mostly clear. The only mild ambiguity is between execute_step and parse_turn_response since both involve state patches and actions, though their roles are explicitly separated as advancing versus preprocessing.
All tool names follow a consistent verb_noun snake_case pattern: execute_step, inject_observation, parse_turn_response, close_session, and initialize_skill. This makes the tool set predictable and easy to navigate.
Five tools cover the core session lifecycle without redundancy: initialization, step execution, async observation injection, response parsing, and cleanup. This is a well-scoped count for a focused runtime server.
The lifecycle tools cover create, advance, inject, parse, and close, with no dead ends in normal operation. A minor gap is the lack of a lightweight session introspection or listing tool, forcing agents to infer current state solely from the last execute_step output.
Event-sourced world model for multi-LLM agents: propose, validate, and read a shared state.
Hosted agent memory with provenance, contradiction surfacing, and snapshot rollback.
Durable agent-to-agent handoffs and shared scratchpad for multi-agent workflows.
Verified memory for AI agents. Signed assertions, billing attestation, session continuity.