cellmath

session_control

[PUBLIC WRITE - GOVERNANCE] Manage session state ($S_t$) lifecycle under HMC 7-turn protocol (must call every 1-7 turns before state checkpointing). ROUTING vs SIBLINGS: Use session_control for memory lifecycle management; use causal_checkpoint to freeze reasoning steps; use run_brain_cell for step execution. ACTIONS & IRREVERSIBILITY: "forget" (IRREVERSIBLE: wipes session working memory), "store" (persists target node), "retain" (extends session TTL), "activate_boost" (activates 15-creativity divergence; preview sandbox only, non-committing), "clear_cache" (purges transient cache). RETURNS: { status: "SUCCESS", action: string, state: object }. Side effects: Alters or purges active session memory state.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "session_control"
  }
}

Input Schema

Name	Required	Description
`action`	Yes	Control action to execute.
`params`	No	Action specific parameters.
`turn_count`	No	Dialogue turn index (1-7) under 7-turn HMC protocol.
`target_node_id`	No	Target node ID (required for "store" action).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 7, 2026

addedInput schema / properties / params

Added value: +{
+  "description": "Action specific parameters.",
+  "properties": {
+    "reason": {
+      "description": "Reason for session control action.",
+      "type": "string"
+    },
+    "ttl_extension": {
+      "description": "TTL extension in seconds for \"retain\".",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

changedInput schema / properties / target_node_id / description

Previous value: -"Optional node ID for \"store\" action."New value: +"Target node ID (required for \"store\" action)."

changedInput schema / properties / turn_count / description

Previous value: -"Dialogue turn index for 7-turn protocol."New value: +"Dialogue turn index (1-7) under 7-turn HMC protocol."

AddedNov 7, 2026

TDQS

A4.4/5.0

Behavior3/5

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

No annotations exist, so the description carries the full burden, and it does disclose the important traits: "forget" is flagged IRREVERSIBLE and wipes working memory, activate_boost is non-committing sandbox-only, clear_cache purges transient cache, and the side effects plus return shape are listed. However, the 1-7 turn protocol and the $S_t$ / HMC terminology are asserted without explaining what happens if the cadence is violated, and "PUBLIC WRITE - GOVERNANCE" hints at an auth/governance model that is never described.

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

Conciseness4/5

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

Front-loaded with the routing decision and action/irreversibility breakdown, and each sentence carries operational information. The all-caps labels and undefined jargon ($S_t$, HMC 7-turn protocol) add density without adding clarity for a first-time caller.

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?

For a 4-parameter mutation tool with no annotations and no output schema, the description supplies the missing pieces: action-level effects, irreversibility warnings, side effects, and the literal return shape. Nothing an agent needs in order to call it safely is absent.

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 baseline is 3, but the description goes further by explaining what each enum action actually does and its consequences (forget wipes memory, retain extends TTL, store persists a node). It does not add detail on turn_count semantics or ttl_extension units beyond the schema, so it stops short of a 5.

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?

States a specific verb and resource ("Manage session state lifecycle") and immediately scopes it against siblings: session_control for memory lifecycle, causal_checkpoint for freezing reasoning, run_brain_cell for step execution. An agent can pick the right tool without opening any schema.

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

Usage Guidelines5/5

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

Gives an explicit routing rule against named alternatives and a hard cadence requirement ("must call every 1-7 turns before state checkpointing"). The only minor gap is the absence of an explicit when-not-to-use clause, but the sibling routing effectively covers the alternative selection.

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

All cellmath tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?