Skip to main content
Glama
Octonove

crbro-memory

by Octonove
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Working context

crbro_context
DestructiveIdempotent

Read or update persistent working context: active topics, open items, recently closed, and last session. Close completed items so later sessions do not repeat them.

Instructions

Read or write the working context: active topics, open items, recently closed, last session. Called with no arguments it only reads (written:false, nothing touched); any argument writes and returns the full state plus resolved and discarded. Close items as soon as they are done — resolve_pending records them in recently_closed, discard_pending drops one without recording it, clear empties everything — because an item left open is repeated back to the user in later sessions long after it was finished. Sessions are logged by crbro_consolidate, not here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
clearNoEmpty active_topics, pending_tasks and recently_closed. Runs before the other updates in the same call.
set_topicsNoReplace the whole active-topics list with these neuron ids (no merge). crbro_consolidate also rewrites it from the session.
add_pendingNoAdd an open item, written so it can be checked later. Identical text is deduplicated, so re-adding is a safe no-op.
discard_pendingNoDrop an open item by id or 8+ characters of its text WITHOUT recording it as done (it never appears in recently_closed). Same matcher as resolve_pending; matches come back in discarded.
resolve_pendingNoClose an open item by id (e.g. "p_ab12cd") or by 8+ characters of its text (case-insensitive substring; several items can close at once). Matches move to recently_closed, newest first, capped at 15. An empty resolved in the reply means nothing matched.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.4.0
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  2. Changed3 schema fields changedv2.0.0
    • addedInput schema / properties / clear
      Added value: +{
+  "description": "Empty active_topics, pending_tasks and recently_closed. Runs before the other updates in the same call.",
+  "type": "boolean"
+}
    • addedInput schema / properties / discard_pending
      Added value: +{
+  "description": "Drop an open item by id or 8+ characters of its text WITHOUT recording it as done (it never appears in recently_closed). Same matcher as resolve_pending; matches come back in discarded.",
+  "type": "string"
+}
    • changedInput schema / properties / set_topics / description
      Previous value: -"Replace the whole active-topics list with these neuron ids (no merge). crbro_session_log also overwrites it."New value: +"Replace the whole active-topics list with these neuron ids (no merge). crbro_consolidate also rewrites it from the session."
  3. Changed3 schema fields changedv1.14.0
    • changedInput schema / properties / add_pending / description
      Previous value: -"Add a pending task"New value: +"Add an open item, written so it can be checked later. Identical text is deduplicated, so re-adding is a safe no-op."
    • changedInput schema / properties / resolve_pending / description
      Previous value: -"Mark a pending task as resolved"New value: +"Close an open item by id (e.g. \"p_ab12cd\") or by 8+ characters of its text (case-insensitive substring; several items can close at once). Matches move to recently_closed, newest first, capped at 15. An empty resolved in the reply means nothing matched."
    • changedInput schema / properties / set_topics / description
      Previous value: -"Set active topics (neuron IDs)"New value: +"Replace the whole active-topics list with these neuron ids (no merge). crbro_session_log also overwrites it."
  4. First observedv1.4.0

TDQS

A4.9/5.0
Behavior5/5

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

With annotations already declaring non-read-only, destructive, and idempotent behavior, the description adds substantial additional context: no-argument calls touch nothing, any argument writes, the full state plus resolved and discarded is returned, resolve_pending records to recently_closed while discard_pending does not, and open items are repeated back in later sessions. That last point is a crucial behavioral consequence not captured by 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 a single dense paragraph that front-loads the read/write distinction and then explains consequences, with no filler sentences. It is slightly dense and could be broken into shorter statements for faster scanning, but every sentence carries information.

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?

Given five parameters, no output schema, and annotation coverage of the safety profile, the description supplies the missing context: return shape on write, what resolved and discarded contain, the difference between resolve and discard, and the long-term consequence of leaving items open. An agent can call this correctly without reading the schema.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline for parameter semantics is 3, but the description adds operational meaning beyond the schema: it explains the call-level semantics (no arguments reads, any argument writes), the ordering (clear runs before other updates), and the relationship between resolve_pending, discard_pending, and recently_closed. These are behavioral contracts that the schema field descriptions alone do not fully state as a unified model.

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 states a clear verb pair (read or write) and a specific resource (the working context), then enumerates what the context contains (active topics, open items, recently closed, last session). The no-argument read behavior and the write-on-any-argument behavior are both explicit, distinguishing it from siblings like crbro_consolidate, which the description also names as the session logger.

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?

Explicitly states when to call with no arguments (read-only) versus any argument (write), and it names the alternative tool for session logging (crbro_consolidate) so the agent knows not to use this for that purpose. It also gives a clear operational rule — close items as soon as they are done — and explains which fields do the closing, which is exactly the when-to-use guidance an agent needs.

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

Deploy Server

Other Tools