ASTRA

tcai_cycle

Destructive

Run one or more ACM consciousness cycles through SNN binding, ignition, emotion, reward, memory, and self-model; halt early on sustained recursive satisfaction.

Instructions

Run one or more ACM cycles (the_consciousness_ai port): SNN signals → AKOrN binding → GNW ignition → qualia → emotion → reward shaping → emotional memory → self-model → second-order loop. Set stopWhenSatisfied to halt early once the recursive loop reaches a sustained satisfactory (converged, low-curiosity, stable) regime.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "tcai_cycle"
  }
}

Input Schema

Name	Required	Description
`cycles`	No	Number of cycles (default 1; upper bound if stopWhenSatisfied)
`threat`	No
`novelty`	No	Surprise/curiosity ∈ [0,1]
`setpoint`	No	Continuous controller substrate setpoint to regulate toward (v2.9, default 0.3)
`narrative`	No	Annotation for the memory record
`closedLoop`	No	Enable closed-loop actuation (AIF action drives the substrate); default on
`maxEpistemic`	No	Halt threshold: expected info gain ≤ (default 0.1)
`rewardSignal`	No	Task feedback ∈ [−1,1]
`epsFreeEnergy`	No	Halt threshold: absolute \|ΔF\| ≤ (nats, default 0.02)
`relFreeEnergy`	No	Halt threshold: \|ΔF\| ≤ rel·F, scale-free (default 0.03)
`minTaskQuality`	No	Halt threshold: realized task quality ≥ (default 0.6)
`productionLoop`	No	Close the loop through the shared production SNN (read+write); default off (v2.9)
`controllability`	No
`predictionError`	No	World-model surprise (raw)
`stopWhenSatisfied`	No	Halt early when the second-order loop reports sustained satisfaction
`predictionConfidence`	No
`satisfactionPatience`	No	Consecutive satisfied cycles required to halt (default 3)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.1.0Sep 23, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=false, so the safety profile is partly covered. The description adds the internal stage sequence and the early-halt semantics, but never explains what the destructive annotation actually destroys or what reconfiguring the actuation/production loop entails, which is the highest-value missing detail for a destructive tool.

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?

Two sentences, front-loaded with the action verb, with the pipeline compressed into an arrow chain rather than verbose prose. The stage enumeration is long but carries genuine structural information, so almost every token earns its place.

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

Completeness3/5

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

For a destructive, 17-parameter tool with no output schema and no required parameters, the description covers the what but omits the return shape, the side effects implied by destructiveHint, and any routing context. It is adequate but leaves meaningful gaps an agent would need filled.

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

Parameters3/5

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

Schema description coverage is 82%, so the schema already documents most of the 17 parameters, making 3 the baseline. The description adds meaning only for stopWhenSatisfied (defining 'sustained satisfactory' as converged/low-curiosity/stable) and implicitly for cycles as an upper bound; the remaining halt thresholds and inputs get no extra context.

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

Purpose4/5

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

States a specific verb and resource ('Run one or more ACM cycles') and enumerates the exact pipeline from SNN signals through the second-order loop, so an agent can tell it is the full-cycle driver rather than a single-stage sibling. It does not explicitly contrast itself with near-neighbors like tcai_second_order, orch_cycle, or ovo_cycle.

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

Usage Guidelines2/5

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

The only guidance is about setting stopWhenSatisfied, which is parameter behavior rather than when-to-use context. There is no statement of when to pick this over sibling cycle tools, no prerequisites, and no when-not-to-use. An agent must infer usage entirely.

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

Deploy Server