Skip to main content
Glama
Octonove

crbro-memory

by Octonove
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Consolidate the session

crbro_consolidate
Idempotent

Close the current session to persist all knowledge, decisions, and topics touched. Call before ending a conversation to avoid losing session data.

Instructions

Write: close the session — the only way to log a session. Call it before the conversation ends. Persists pending knowledge and index writes, logs the session from summary (credentials stripped, kinds in redacted), sets the context's last_session, recalculates heat, links the neurons written this session with weak temporal synapses (synapses_updated), updates the manifest and syncs shared team spaces (offline is normal). Returns session_id, facts_saved, decisions_saved, topics_touched and per-space sync state; topics_touched logs neurons you only read. Not consolidating loses the session's knowledge. Mid-session open items go to crbro_context; housekeeping is crbro_maintenance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
summaryYesA headline paragraph, not a report: what was done, decided and left open, in a few sentences. The facts themselves belong in crbro_learn, where recall finds them; this text is re-read at every boot. Stored whole, after credential redaction. Session logs are not searched by recall: what only lives here is invisible to it.
topics_touchedNoNeuron ids this session used WITHOUT writing (recalled, inspected, discussed). Added to the log's topics_touched next to the ids written this session; write counters stay real. Unknown ids are dropped and listed in topics_unknown.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv2.1.2
    • changedInput schema / properties / summary / description
      Previous value: -"A headline paragraph, not a report: what was done, decided and left open, in a few sentences. The facts themselves belong in crbro_learn, where recall finds them; this text is re-read at every boot. Stored after credential redaction; beyond 3,000 characters it is cut and the response says so."New value: +"A headline paragraph, not a report: what was done, decided and left open, in a few sentences. The facts themselves belong in crbro_learn, where recall finds them; this text is re-read at every boot. Stored whole, after credential redaction. Session logs are not searched by recall: what only lives here is invisible to it."
  2. Changed1 schema field changedv2.1.0
    • changedInput schema / properties / summary / description
      Previous value: -"What was accomplished: concrete work, decisions, outcomes. Stored (after credential redaction) as the session log later sessions read."New value: +"A headline paragraph, not a report: what was done, decided and left open, in a few sentences. The facts themselves belong in crbro_learn, where recall finds them; this text is re-read at every boot. Stored after credential redaction; beyond 3,000 characters it is cut and the response says so."
  3. Changed2 schema fields changedv2.0.0
    • changedInput schema / properties / summary / description
      Previous value: -"What was accomplished: concrete work, decisions, outcomes. Stored verbatim as the session log later sessions read."New value: +"What was accomplished: concrete work, decisions, outcomes. Stored (after credential redaction) as the session log later sessions read."
    • addedInput schema / properties / topics_touched
      Added value: +{
+  "description": "Neuron ids this session used WITHOUT writing (recalled, inspected, discussed). Added to the log's topics_touched next to the ids written this session; write counters stay real. Unknown ids are dropped and listed in topics_unknown.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  4. Changed1 schema field changedv1.14.0
    • changedInput schema / properties / summary / description
      Previous value: -"Summary of the session being consolidated"New value: +"What was accomplished: concrete work, decisions, outcomes. Stored verbatim as the session log later sessions read."
  5. First observedv1.4.0

TDQS

A4.8/5.0
Behavior5/5

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

The description discloses numerous behavioral details beyond what annotations convey: persisting pending writes, credential redaction, heat recalculation, weak temporal synapse linking, manifest updates, shared-space syncing, offline tolerance, and the exact return payload. This is rich, honest disclosure for a side-effect-heavy tool and contradicts nothing in the annotations.

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?

The description is front-loaded with the action and timing, and every clause carries functional information. It is dense and uses long semicolon-chained sentences, which slightly reduces skimmability, but there is no wasted prose and the critical call-time guidance appears first.

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, state-mutating tool with no output schema, yet the description enumerates the full workflow and the returned fields (session_id, facts_saved, decisions_saved, topics_touched, per-space sync state). It also explains failure-mode expectations like offline sync and unknown topic ids, so an agent has everything needed to call it correctly.

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. The description adds meaningful semantic guidance beyond the schema: the summary is 're-read at every boot' and 'session logs are not searched by recall,' and topics_touched are clarified as read-only usages with unknown ids dropped. This helps an agent craft better parameter values, not just fill fields.

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 specific verb and resource: 'Write: close the session — the only way to log a session.' It clearly distinguishes this from siblings by naming excludes such as 'Mid-session open items go to crbro_context; housekeeping is crbro_maintenance.' An agent can tell exactly what crbro_consolidate is for and what it is not.

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?

Usage timing is explicit: 'Call it before the conversation ends.' The consequence of not using it is stated ('Not consolidating loses the session's knowledge'), and alternatives are named for related but different tasks. This gives an agent concrete decision rules for when to invoke this tool versus crbro_learn, crbro_context, or crbro_maintenance.

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

Install Server

Other Tools

Latest Blog Posts

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/Octonove/crbro-memory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server