crbro-memory

by Octonove

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Working context

crbro_context

DestructiveIdempotent

Instructions

Read or write active topics and pending tasks. No mutation fields means read-only (written:false), including scope-only calls. Defaults to this connection project plus global legacy items; scope=all reads across projects. Add optional due and done_when only when agreed. resolve_pending closes matches, discard_pending removes them without completion; prefer IDs over ambiguous text. clear removes the selected project state, or all state without a project. Recently closed is capped at 15 globally. No automatic reminders or age-based deletion. Sessions are logged by crbro_consolidate.

Input Schema

Name	Required	Description
`due`	No	Optional real calendar day YYYY-MM-DD for add_pending.
`clear`	No	Empty active_topics, pending_tasks and recently_closed. Runs before the other updates in the same call.
`scope`	No	all reads/changes global context; otherwise use the current project when bound. clear in a project never clears other projects.
`project`	No	Registered project id or alias. Omitted uses this connection's boot project.
`done_when`	No	Observable completion condition for add_pending; not an instruction to execute automatically.
`set_topics`	No	Replace the selected project active-topics list (or global list without a project) with these neuron ids, without merging.
`add_pending`	No	Add an open item, written so it can be checked later. Identical text is deduplicated within its project; re-adding may update due or done_when.
`discard_pending`	No	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.
`resolve_pending`	No	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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv2.10.0Oct 21, 2026

changedInput schema / properties / add_pending / description

Previous value: -"Add an open item, written so it can be checked later. Identical text is deduplicated, so re-adding is a safe no-op."New value: +"Add an open item, written so it can be checked later. Identical text is deduplicated within its project; re-adding may update due or done_when."

addedInput schema / properties / done_when

Added value: +{
+  "description": "Observable completion condition for add_pending; not an instruction to execute automatically.",
+  "type": "string"
+}

addedInput schema / properties / due

Added value: +{
+  "description": "Optional real calendar day YYYY-MM-DD for add_pending.",
+  "type": "string"
+}

addedInput schema / properties / project

Added value: +{
+  "description": "Registered project id or alias. Omitted uses this connection's boot project.",
+  "type": "string"
+}

addedInput schema / properties / scope

Added value: +{
+  "description": "all reads/changes global context; otherwise use the current project when bound. clear in a project never clears other projects.",
+  "enum": [
+    "project",
+    "all"
+  ],
+  "type": "string"
+}

changedInput schema / properties / set_topics / description

Previous value: -"Replace the whole active-topics list with these neuron ids (no merge). crbro_consolidate also rewrites it from the session."New value: +"Replace the selected project active-topics list (or global list without a project) with these neuron ids, without merging."

Changed1 schema field changedv2.4.0Sep 13, 2026
- removedInput schema / $schema
```
Removed value: -"http://json-schema.org/draft-07/schema#"
```

Changed3 schema fields changedv2.0.0Sep 3, 2026

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."

Changed3 schema fields changedv1.14.0Sep 3, 2026

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."

First observedv1.4.0Aug 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, it discloses conditional read-only behavior, project/global defaults, clear semantics, resolve/discard distinctions, the 15-item closed cap, no automatic reminders or age-based deletion, and logging by crbro_consolidate. These details materially help an agent predict side effects and boundaries.

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 and dense, with no filler sentences. It is slightly long for nine parameters, but each sentence contributes operational meaning rather than repeating the schema verbatim.

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 complex tool with no output schema, the description covers the important call semantics: read/write mode, default scope, clear behavior, matching rules, caps, absence of automatic cleanup, and session logging. An agent has enough context to call it correctly and avoid misinterpretation.

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 schema already documents all nine parameters. The description adds cross-parameter semantics: no mutation fields implies read-only, scope-only calls stay read-only, prefer IDs over ambiguous text, and clear removes selected project state before other updates.

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 statement: 'Read or write active topics and pending tasks.' That precisely identifies the tool's domain and distinguishes it from sibling operations such as crbro_learn, crbro_recall, and crbro_consolidate.

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?

It gives clear operational context: no mutation fields means read-only, scope=all reads across projects, and due/done_when should be added only when agreed. However, it does not explicitly name when to choose this tool over alternatives or when it should not be used.

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

Deploy Server

Working context

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools