Skip to main content
Glama
Derzkiyboomchik

SKILL.state MCP Runtime

Execute one SKILL.state step

execute_step

Advance a skill session by one step: validate and apply a sparse state update, execute the action, and return the next state and observation.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesa_t — the action to execute. A free-text command or a structured JSON action, e.g. {'type':'echo','message':'...'}, {'type':'fail','reason':'...'}, {'type':'complete','summary':'...'}. The mock executor produces O_{t+1}.
session_idYesIdentifier of the active skill session to advance by one step.
state_updateYesΔΣ_t — sparse JSON patch to apply as Σ_{t+1} = Σ_t ⊕ ΔΣ_t. NULL-DELETION SEMANTICS: {'key': null} deletes 'key' from Σ; a value inserts/updates the key; nested objects merge recursively; arrays replace wholesale. Keys absent from ΔΣ_t are left untouched.
reasoning_traceYesR_t — your free-form Chain-of-Thought for this step. WARNING: the runtime DISCARDS this field entirely. It is never stored, logged, hashed or replayed. Write reasoning here instead of polluting Σ.
environment_observationYesO_t — the latest observation you (the model) consumed this turn, i.e. the 'latest_observation' from the previous tool response. The runtime uses it for context-drift detection, then discards it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden, and it delivers: it discloses that reasoning_trace is discarded and never stored, logged, hashed, or replayed, that old observations are not retained, and that state updates use null-deletion merge semantics. These are precisely the non-obvious runtime behaviors an agent needs to know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is densely informative yet well structured with INPUT, LOGIC, and OUTPUT sections, and the first sentence states the core purpose immediately. Every sentence contributes either behavioral disclosure, parameter semantics, or execution order, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex 5-parameter tool with no output schema, but the description fully specifies the input contract, the execution pipeline, and the exact next-turn return tuple. It also covers retention and discard behavior. Minor failure-mode details are absent, but nothing needed for correct selection and invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value beyond the schema. It explains that state_update is a sparse patch with null-deletion semantics, that reasoning_trace is a scratchpad that is discarded, and that environment_observation is the previous response's latest_observation used for context-drift detection.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb-resource pair: 'Advance a skill session by exactly one step t → t+1.' It clearly defines this as the per-step execution tool and distinguishes it from the sibling session lifecycle tools by describing the strict next-turn output tuple.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear operational context: it explicitly says this advances a session by exactly one step and consumes the current observation to produce the next one. It does not explicitly name sibling tools or state when not to use it, but the t → t+1 contract makes the intended usage unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.