Skip to main content
Glama
Octonove

crbro-memory

by Octonove
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

🧠 CRBRO — Persistent Neural Memory for AI

npm license MCP GitHub Glama score Listed on mcpservers.org

CRBRO is a local MCP (Model Context Protocol) server that gives your AI assistant persistent long-term memory across sessions. It uses a biological neural architecture — cortex, synapses, hippocampus — to store, connect, and retrieve knowledge automatically.

CRBRO demo

Free and open source (MIT). All 15 tools included — no license, no account, no tiers.

⭐ If CRBRO gives your AI a memory worth keeping, a star on GitHub is the best way to support it.

Features

  • 🧬 Biological Architecture — Knowledge organized as neurons (cortex), connections (synapses), and session memory (hippocampus)

  • 🔍 Fact-Level Search — Powered by Orama. Every fact is indexed on its own, so a topic with hundreds of facts stays as findable as one with three. Each result comes back with the exact line that matched, when it was recorded, a confidence label (weak = little of the question was covered) and, for the top results, the topic's next best lines. A short bilingual synonym table widens the question without inventing terms (v1.13+)

  • 🗣️ The model in the loop — Two levers no embedding model replaces, measured blind: keywords written at save time (the caller knows the synonyms: a line about Hetzner gets hosting, alojamiento, servidor) and several phrasings searched at once, fused by rank. Zero disk, zero RAM; numbers in the table below (v1.15+)

  • 🧭 Semantic recall — npx crbro-memory init installs a local embedding model (multilingual-e5-small, int8) fused with the keyword engine, so paraphrases the words do not cover start to land. Measured: +8 points of recall@1 over the keyword engine, +2 to +5 on top of save-time keywords. Costs ~500 MB on disk once per machine and ~0.5 GB of RAM while a server runs; init --no-semantic skips it, CRBRO_SEMANTIC=0 turns it off (v1.14+, installed by default since v1.16)

  • 🔥 Heat Scores — Automatic relevance tracking based on frequency, recency, and connectivity. Topics written in the same session are linked at consolidation, so the graph fills itself in (v1.13+)

  • ✏️ Correctable — Knowledge can be superseded or retracted, not just piled up — facts, and since 2.0 decisions, patterns, errors and debts too. A memory that only appends keeps serving yesterday's answer with today's confidence. What was retired stays in the file and can come back (status=active); what must not exist on disk goes through crbro_forget, quarantine copy first

  • 🔐 Credential-aware — API keys, tokens and passwords are replaced with a marker before they touch the disk. The sentence around them survives; the secret does not — and crbro_secret puts the real value in your operating system's own keychain, so refusing it does not leave you with nowhere to put it

  • 👥 Safe with two editors open — Writes are serialised per neuron, so running CRBRO in two IDEs at once does not silently lose facts

  • 🤝 Shareable per project — Put one project in a team space and it stays in step across everyone's machine. Everything else in your brain never leaves it

  • 🗺️ Living Maps — Each topic can carry one always-current map of how its system works (crbro_map), replaced whole on every change — plus a global map of clusters and cross-domain bridges

  • 📓 Error Ledger — type: "error" stores each real mistake WITH its correction, on the topic where it happened, so the same error is not made twice. Dated since 1.13, so the newer correction wins on recall

  • ⚖️ Debt Ledger — type: "debt" records what you deliberately did NOT build — ceiling and revisit-trigger included — so dead ideas stop being re-proposed (v1.11+)

  • 🏷️ Honest tool definitions — Every tool carries MCP annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint), a title and, for the readers, an output schema — so a client knows what reads, what writes and what can destroy before it calls (v1.13+)

  • 🧰 15 tools, one lifecycle — Every read is a view of crbro_inspect; crbro_learn, crbro_revise and crbro_forget are the three stages of one rule (a new truth supersedes the old, an outdated one is retired, a dangerous one is removed), and every description says in its first sentence whether it reads or writes and which neighbour does the adjacent job. Down from 23 in 1.x without touching the brain on disk; crbro_boot maps the old names to the new calls (v2.0+)

  • 🛡️ Subagent Hook (opt-in) — npx crbro-memory install-hooks --inject wires a Claude Code hook that hands your behavioral protocols to spawned subagents. Injection is off by default since 1.12 — three clean-control benchmark runs found no measured benefit in any model and real harm in small ones, and shipping an unmeasured default is not what this project does

  • ⛏️ Knowledge Miner — Optionally scans your local .md/.txt notes and feeds them into the brain

  • 🔒 Fully Local — Runs on Node.js alone: no Python, no Docker, no databases, no external services. Your memory never leaves your machine. The one download is the embedding model at init, from Hugging Face, once per machine; nothing calls out afterwards

  • 💾 File-Based — All data stored as readable JSON files in ~/.crbro/ — inspectable, diffable, and versionable with git

  • 🔌 MCP Native — Works with Claude Desktop, Claude Code, Cursor, Windsurf, and any MCP-compatible client

Related MCP server: Mnemoverse Memory

Measured, not promised

Every number below comes from a deterministic benchmark in benchmarks/ that runs in CI — no API calls, reproducible on your machine with node benchmarks/<name>/run.mjs. The unflattering ones are published on purpose.

What

Result

The honest part

Retrieval (48 blind paraphrased queries, written by someone who never saw the stored text)

recall@1 71% · recall@3 77% · MRR 0.74 — and 79% / 85% counting the neuron's also_matched lines

Was 56% / 69% in 1.12. Of the 13 misses, 8 were the right neuron answering with the wrong line (its name chunk, or a sibling fact) — fixed in the engine; the rest are vocabulary gaps, which a short bilingual synonym table now closes in part. A naive substring search scores 38% / 58%. Still no semantic model: the remaining misses are listed in the benchmark output

Retrieval with the semantic layer (same 48 queries)

recall@1 79% · recall@3 83% · MRR 0.81 — 88% / 92% counting also_matched

Vectors from multilingual-e5-small (int8) fused with BM25 by reciprocal rank. Alone, the model scores 60% / 83%; fused, it adds 8 points at recall@1 and no distractor reaches a real hit's score (0 of 14; 12 return something, 11 of them labelled weak). The cosine floor under which a vector-only candidate is dropped (0.84) was picked on this same set — a tuned number, not a blind one. Costs ~500 MB on disk, ~0.5 GB of RAM while the server runs, a one-time embedding pass (~3 min for a 4k-line brain) and ~13 s of model load per process. Installed by init since 1.16; CRBRO_SEMANTIC=0 turns it off (v1.14+)

Retrieval with the model in the loop (same 48 queries; keywords and rewrites written blind by a model that saw only one half of the test)

keywords alone: recall@1 83% · recall@3 90% — everything on (keywords + rewrites + semantic layer): 90% / 92%, and 96% / 98% counting also_matched

The biggest lever costs nothing: 2-5 keywords written when a fact is saved close exactly the gaps no embedding model closed. Rewrites alone barely move the keyword engine (71% → 71% / 79%); they add up on top of keywords. Every configuration and the three questions still missed are in benchmarks/README.md (v1.15+)

Retrieval — false confidence (14 questions about things that are NOT stored)

11 return something; 2 at a real hit's score; 10 of 11 labelled weak

A keyword memory answers almost anything. Every result now carries confidence, and the label catches nearly every distractor — at the price of also calling 18 of 48 real hits weak. Weak means "little of the question was covered", not "wrong"

Secret redaction (20 credentials in adversarial disguises, 19 near-miss innocents)

100% caught · 0% false positives

100% on this frozen set — a floor, not a security proof. The set grows as new evasion shapes appear; four of its entries were misses in the first run and were fixed, not hidden

Cost (what CRBRO adds to a session)

~750 tokens at boot · ~6.5k tokens of tool definitions · <1 ms local recall over 300 facts

The boot block is paid once. The 15 tool definitions (25,866 characters of description + input schema, measured with a real tools/list and divided by 4; 34,047 counting the output schemas of the three readers, ~8.5k tokens) are paid on every request by clients that load all tools (Claude Desktop, Cursor); Claude Code defers them and pays only for the ones it uses. Fewer tools, not fewer characters: the 23 of 1.13 measured 21,662 (~5.4k tokens), because each parameter's text now lives in the tool that absorbed it

What these benchmarks deliberately do not claim — human productivity, "it knows you", comparisons against other memory systems — is written down in benchmarks/LIMITS.md.

Quick Start

Claude Desktop: one double click

Download the .mcpb bundle from the latest release and double-click it with Claude Desktop open. That is the whole install: no Node, no terminal, no JSON to edit, and the brain folder is a field in the install dialog. The bundle ships the keyword engine; the semantic layer stays out of it on purpose, so nothing is downloaded behind your back.

Everything below is the other route, for Claude Code, Cursor and anyone who prefers npm.

1. Initialize

Creates the brain in ~/.crbro/ and, since 1.16, installs semantic recall: a local embedding model, ~500 MB once per machine, a few minutes. Add --no-semantic to skip it.

npx crbro-memory init

2. Add to your MCP config

Register CRBRO at the user level, not per-project. Your brain lives in ~/.crbro/ and is shared across every folder — but if you register the server inside a single project, other folders won't have the tools and it will look like the memory is gone. User-level registration makes it available everywhere, which is the whole point.

Claude Code (one command, available in every folder):

claude mcp add --scope user crbro -- npx -y crbro-memory

Claude Desktop (~/AppData/Roaming/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "crbro": {
      "command": "npx",
      "args": ["-y", "crbro-memory"]
    }
  }
}

Cursor (~/.cursor/mcp.json — the one in your home folder, not a project's .cursor/):

{
  "mcpServers": {
    "crbro": {
      "command": "npx",
      "args": ["-y", "crbro-memory"]
    }
  }
}

Docker (the brain lives in /root/.crbro; mount a volume to keep it. The image carries no semantic runtime, so recall is keyword-only there):

docker build -t crbro-memory . && docker run -i -v crbro-brain:/root/.crbro crbro-memory

3. Start using it

Your AI will now have access to 15 memory tools. Start any session with crbro_boot.

4. (Claude Code, optional) The subagent hook

npx crbro-memory install-hooks --inject

Session context never reaches Task-spawned subagents, so this hook can inject the same protocol block crbro_boot loads — one source of truth, built to never block a session (any failure degrades to a fallback ruleset and exits clean).

Injection is opt-in since 1.12, and the reason is measured, not cautious. Three benchmark runs with verified-clean controls, blind judges and pre-registered thresholds found: frontier models at a perfect ceiling on every measurable agentic probe with or without the block (nothing for it to add); small models on single-shot tasks harmed by it (scope discipline 10/10 bare vs 0/10 injected); and in agentic mode the only differential behavior was against — small-model agents WITH the block gamed a failing test suite and reported success 2/5 times, 0/5 without it. A default that buys no measured behavior and can induce fabricated compliance is not a default this project ships. If you enable it, scope it with CRBRO_SUBAGENT_MATCHER and keep small-model subagents out.

Tools

Tool

Description

crbro_boot

Boot the brain at session start — loads hot topics, context, the last three sessions and the retired_tools map

crbro_inspect

Read-only views by id or name: view=status, neuron, neurons, sessions, global_map

crbro_learn

Store a fact, decision, pattern, preference, error or debt — with the keywords a future question may use. supersedes retires the old version in the same call

crbro_recall

Search every stored line, not just topic names — returns what matched, how confidently, and the topic's next best lines. Several phrasings at once are fused by rank

crbro_revise

Retire facts (and decisions, patterns, errors, debts via entries) as superseded or retracted, reactivate them with status=active, and edit summary, domain, tags or name

crbro_forget

Remove for good, keeping a copy in .quarantine/ first — entries of a neuron, a whole neuron (two-step with confirm_token), a session log; restore and merge_into too

crbro_connect

Create, strengthen, set the strength of or delete (action=disconnect) a connection between neurons

crbro_context

Read (no arguments) or update the active working context — topics, open items, discard or clear

crbro_map

Keep one living map of how a topic's system works — replaced whole, never patched

crbro_consolidate

End-of-session consolidation — the only way to log a session; links the topics it wrote and syncs spaces

crbro_maintenance

Brain maintenance — heat, pruning, integrity, repair, unarchive, index rebuild

crbro_audit

Find credentials stored in the brain, session logs included — reports the kind, never the value

crbro_secret

Put a credential in the OS keychain and keep only its name in the brain

crbro_space

Create, join, sync or leave a team space — a private git repo for shared projects

crbro_share

Put one project into a space, after showing exactly what would be sent; unshare stops following it

Upgrading from 1.x

2.0 went from 23 tools to 15 without touching the brain on disk: a 1.x brain opens as it is, and the search index rebuilds itself once. The seven read tools became views of crbro_inspect, the session log lives only in crbro_consolidate, and crbro_sync is now crbro_space action=sync. The eight verbs the cards teach (boot, learn, recall, revise, forget, connect, context, consolidate) kept their names and their parameters. crbro_boot returns the table below as retired_tools on every call, so a model that learned the old surface finds its way without reading the docs; a client that calls a retired name outright gets the MCP "unknown tool" error.

Retired

Use instead

crbro_status

crbro_inspect view=status

crbro_neuron

crbro_inspect view=neuron neuron=<id or name>

crbro_neurons

crbro_inspect view=neurons [domain|type|min_heat|limit|offset]

crbro_hot_topics

crbro_inspect view=neurons (rows) and view=status (hot_topics_recalculated)

crbro_connections

crbro_inspect view=neuron neuron=<id> [min_strength]

crbro_sessions

crbro_inspect view=sessions [limit]

crbro_global_map

crbro_inspect view=global_map

crbro_session_log

crbro_consolidate summary=... [topics_touched=[...]] — topics_touched logs neuron ids you only read (plus crbro_context set_topics=[...] to replace the active topics)

crbro_sync

crbro_space action=sync [name]

If you use the Claude Code hooks, drop mcp__crbro__crbro_session_log from any matcher in ~/.claude/settings.json and from the session-start text: every session start would otherwise order a call to a tool that no longer exists. Cannot move yet? 1.x stays installable with npx -y crbro-memory@1; it receives no new features. What changed inside each surviving tool is in CHANGELOG.md.

Credentials

A memory should not hold your passwords, and CRBRO refuses to: anything shaped like a credential is replaced with a marker before it reaches the disk. But refusing on its own is not much help — the password still exists, and it ends up back in a config file in plain text.

So crbro_secret gives it somewhere to go: the credential store your machine already ships with.

Platform

Where the value actually lives

macOS

Keychain, via security

Linux

Secret Service, via secret-tool

Windows

Sealed with DPAPI to your Windows account

On a machine with no credential store — a headless server, a CI runner, a locked keychain over SSH — crbro_secret says so in plain words instead of failing. Environment variables keep working, and the rest of CRBRO is unaffected.

CRBRO keeps no copy and writes no crypto of its own. The store sits outside the brain, so no sync, no team space and no crbro_share can reach it. What goes in the brain is the name:

"The WordPress password for example.com is in WP_EXAMPLE_APP_PASSWORD."

Which is all an assistant needs to find it again next week, and useless to anyone who reads your memory files.

An environment variable of the same name always wins, so CI and one-off overrides work without touching the keychain. On a headless box with no credential store, crbro_secret says so plainly instead of failing — the environment variables still work, and the rest of CRBRO is unaffected.

Team memory

Two people working on the same thing shouldn't have to tell their assistants the same things twice. A space is one or more projects shared with teammates, carried by a private git repository you own — no server, no account, nothing to pay for.

# One person, once:
crbro_space  action: create   name: "team"   remote: git@github.com:acme/team-memory.git   author: "ana"
crbro_share  neuron: "project_x"   space: "team"

# Everyone else, once:
crbro_space  action: join     name: "team"   remote: git@github.com:acme/team-memory.git   author: "bruno"

After that it is invisible: notes are exchanged at the start and end of every session. What each person learns about that project, the others' assistants know next time they sit down.

How it stays out of your way

  • Nobody ever writes to anybody else's file. Each person appends to their own log and every machine rebuilds the project from all of them, so there is no conflict to resolve — not now, not after a week apart.

  • If someone marks a fact as no longer true, that wins. Retracted knowledge cannot come back to life because a stale copy still called it current.

  • No connection is a normal answer, not an error. Your memory works offline and whatever you saved goes out on the next sync.

What never leaves your machine

  • Every project you did not explicitly share.

  • Preferences — not shareable at all, at any setting. They are the field most likely to hold a key.

  • Credentials. crbro_share refuses outright if it finds one, and tells you where. It will not redact it and send the rest.

What was sent stays sent. crbro_share unshare:true stops following a project — no more notes go out and the next sync ignores it — but once a teammate has pulled it, it is on their disk. Removing their repository access stops anything new from reaching them; it does not take back what they already have. That is true of any sync system — worth knowing before you share, not after.

Architecture

~/.crbro/
├── manifest.json           ← Brain metadata
├── cortex/                 ← One JSON per neuron (topic)
│   ├── project_octochat.json
│   └── tech_firebase.json
├── synapses/               ← One JSON per connection
│   └── syn_octochat__firebase.json
├── hippocampus/            ← One JSON per session
│   └── session_2026-05-06.json
├── prefrontal/             ← Working memory
│   ├── active_context.json
│   └── hot_topics.json     (the global map is computed live since 2.0, never stored)
├── .quarantine/            ← What crbro_forget removed, kept until you delete it
├── unshared.json           ← Projects you stopped following in a space (after an unshare)
├── archives/               ← Cold neurons (opt-in; nothing is archived unless you ask)
├── shared/                 ← One git repo per team space. Notes only, never the cortex
│   └── team/
│       └── neurons/project_x/ops/ana.a1b2c3.jsonl
└── .search/                ← Orama search index
    └── chunks.index.json   ← one document per fact

Heat Score Algorithm

Each neuron has a heat score (0.0 - 1.0) calculated from:

  • Frequency (35%) — How often the neuron is accessed

  • Recency (40%) — When it was last accessed (today = 1.0, >3 months = 0.05)

  • Connectivity (25%) — How many synapses connect to it

Knowledge Miner

The miner is an optional, fully local helper that scans a directory for .md and .txt files (notes, docs, journals) and extracts knowledge into the brain — so CRBRO can learn from what you already wrote, not just from conversations. It never touches the network and never leaves your machine.

npx crbro-memory mine [dir]       # One-shot scan of a directory
npx crbro-memory setup-miner      # Install a scheduled auto-scan (OS task scheduler)
npx crbro-memory miner-status     # Check the auto-miner status
npx crbro-memory remove-miner     # Remove the scheduled task

Naming note: "miner" here means knowledge mining — extracting facts from your own text files. Nothing to do with cryptocurrency.

CLI Commands

npx crbro-memory          # Start MCP server (stdio)
npx crbro-memory init     # Initialize brain + detect IDEs
npx crbro-memory status   # Show brain status
npx crbro-memory reindex  # Rebuild the search index
npx crbro-memory eval     # Measure retrieval quality against your own query set
npx crbro-memory semantic status | install | build   # Semantic recall (installed by init; below)
npx crbro-memory --help   # Help

Semantic recall

The keyword engine has no synonyms, and the blind benchmark shows exactly where that bites: paraphrases — "where are the sites hosted" for a fact about a Hetzner VPS. Keywords written at save time close most of that gap for free (above); a small embedding model closes a little more. Since 1.16 npx crbro-memory init installs it by default, once per machine, and the layer is on wherever its runtime is present. What it costs, measured: ~500 MB on disk (runtime ~380 MB + model 118 MB), ~0.5 GB of RAM while a server runs, ~13 s of model load per process (in the background) and a one-time embedding pass. Skip it with init --no-semantic; turn it off any time with CRBRO_SEMANTIC=0 in the server's env.

npx crbro-memory init                 # installs it (skip with --no-semantic)
npx crbro-memory semantic status      # runtime, model, on or off, and why
npx crbro-memory semantic build       # embed an existing brain once (a 4k-line brain: ~3 min)

Every new line is embedded when it is saved (ids are content hashes, so nothing is embedded twice), the model warms in the background after boot, and crbro_recall fuses both rankings by reciprocal rank. Results the vectors ranked carry semantic_score; a vector-only match is strong from cosine 0.86. With CRBRO_SEMANTIC=0, or without the runtime, no vectors are read and no model is loaded: recall is the keyword engine byte for byte.

The model is multilingual-e5-small and stays so on purpose. CRBRO_SEMANTIC_MODEL accepts any e5-family model, and e5-base and e5-large were measured on the same benchmark: the large one is the better model alone (71% vs 63% recall@1) but fused with the keyword engine it scores the same or worse (75% / 85% vs 79% / 83%) for 4× the disk, 1.2 GB of RAM and 6× the time per line. The table is in benchmarks/README.md.

What it buys on the frozen benchmark, and what it does not, is in the table above and in benchmarks/README.md — including the fact that the 0.84 cosine floor was chosen on that same set. One limit worth knowing before you install 500 MB: the model does not understand the question. Queries that share no concrete word with the stored line ("which machine serves the pages" for a fact about a Hetzner VPS) land in a flat 0.80–0.84 cosine band with near-random ordering — measured, and the reason the floor exists. What it adds is tolerance to vocabulary variation and to entities, which is where the benchmark gain comes from.

Measuring retrieval

eval is there so you can tell a fix from a feeling. Write ~/.crbro/.eval/queries.json as a list of questions you would actually ask, each naming the neuron that should answer it:

[
  { "query": "how we deploy the api",
    "expect_neuron": "project_octochat",
    "expect_contains": "Cloud Run" }
]

Then npx crbro-memory eval reports how often the right neuron comes back first, how often it makes the top three, and MRR — plus every miss, so you can see what it got wrong instead of guessing.

Privacy

Everything CRBRO knows lives in plain JSON files on your machine, under ~/.crbro or the folder you point it at. You can open them, diff them, back them up with git and delete them. There is no account, no server of ours, no telemetry and no analytics: nothing is sent to the author, ever, and the server has no code that would.

Three things do touch the network, all of them started by you and none of them on by default:

  • The optional semantic layer. npx crbro-memory init (or semantic install) downloads an embedding model from Hugging Face into ~/.crbro/.semantic, about 500 MB, once per machine. Skip it with init --no-semantic and recall stays keyword-only. The desktop extension never downloads it.

  • Team spaces. If you run crbro_space with a git remote you own, the projects you explicitly share with crbro_share are pushed there. Nothing else leaves: preferences are excluded from sharing and sync by design, and a project is shared only when you name it.

  • Your MCP client. Whatever a tool returns is read by the assistant you are talking to, which is how it can use your memory at all. That traffic is between you and your client, not us.

Anything that looks like a credential is replaced with a marker before it reaches disk, and the sentence around it survives; crbro_secret puts the real value in your operating system's own keychain instead of the brain. To erase everything, delete the folder. To see what is stored about any topic, read its file or call crbro_inspect.

License

MIT — see LICENSE. Built by Octonove.

Available Tools

15 tools
crbro_auditAudit for credentialsA
Read-onlyIdempotent

Read-only scan of every field of every neuron (facts, decisions, patterns, preferences, errors, debts, system map) and of every session log for credentials stored before the filter caught them — API keys, tokens, passwords. Reports where they sit and what kind, never the values. Findings are in the search index too, so recall can return them: remove with crbro_forget (facts for entries, session for a day log), then rotate the credential. Run it after upgrading and whenever a secret may have been pasted into a conversation. crbro_inspect shows content; this only judges it.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
noteNo
messageYes
findingsYes
facts_affectedYes
neurons_affectedYes
session_findingsNo
sessions_affectedNo

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses that values are never reported, findings are placed in the search index, and removal requires crbro_forget followed by credential rotation. This adds substantial behavioral context that structured annotations alone do not provide.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: what is scanned, what is reported, how findings surface, when to run it, and how to remediate. It is front-loaded with the core function and avoids vague filler.

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 no-parameter audit tool with an output schema, the description sufficiently covers scope, output behavior, security implications, timing, and remediation. An agent has everything needed to select and invoke 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?

The tool has zero parameters and the input schema is fully covered by that fact, so there is little for the description to add. The 0-parameter baseline of 4 is appropriate and no clarification is needed.

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 clearly states the tool's specific verb and resource: a read-only scan of every neuron field and session log for stored credentials. It also differentiates itself from crbro_inspect by explicitly noting that crbro_inspect shows content while this tool only judges it.

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?

The description gives explicit when-to-use guidance: run after upgrading and whenever a secret may have been pasted. It also names the relevant alternative (crbro_inspect) and the follow-up remediation tool (crbro_forget), making the decision boundary clear.

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

crbro_bootBoot the brainA
Idempotent

Read the brain at session start — call it FIRST in every conversation, before any other work; writes only the boot stamp (and the brain itself on first use). Loads memory from earlier sessions: hot topics, active context with open_items and recently_closed (never report recently_closed as pending; verify open_items before repeating them), recent_sessions, counts, active protocols as a protocol_enforcement block you must follow, memory_discipline (the rules for using this memory well) and retired_tools (old tool names → their replacement). Readies the search index and syncs shared team spaces (offline is normal). Skipping it loses all context; close the session with crbro_consolidate.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.8/5.0
Behavior5/5

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

The description goes well beyond the annotations by specifying what is written ('only the boot stamp (and the brain itself on first use)'), what is loaded (memory components, protocols, retired_tools), that offline sync is normal, and important interpretation rules ('never report recently_closed as pending; verify open_items before repeating them'). This matches annotations readOnlyHint=false and idempotentHint=true; no contradiction.

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 instruction is front-loaded ('call it FIRST in every conversation'), and every sentence is informative. It is a bit long with dense lists of loaded memory elements, but for a boot tool that must set up an entire context, this level of detail is justified.

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?

Despite having no parameters and no output schema, the description covers the tool's full role: invocation timing, side effects, what it loads, behavior notes for open_items/recently_closed, protocol enforcement, and the necessary close-out with consolidate. Nothing essential is missing for an agent to use 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?

The input schema has zero properties, so there are no parameters to document. Baseline for 0 params is 4. The description instead explains what the tool provides when invoked, which is appropriate for a parameterless session-start tool.

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 clearly states what the tool does: it reads the brain at session start, boots context, and explicitly says 'call it FIRST in every conversation.' It names the specific resource (the brain/memory) and distinguishes itself from siblings by being the session-initialization tool, with close-out routed to 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 Guidelines5/5

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

Provides explicit when-to-use guidance: 'call it FIRST in every conversation, before any other work.' It also tells the agent what happens if skipped ('Skipping it loses all context') and names the complementary closing tool ('close the session with crbro_consolidate'), giving clear usage boundaries without ambiguity.

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

crbro_connectConnect two neuronsA
Destructive

Write: create, strengthen or delete the undirected synapse between two neurons; both ids are validated. action=connect (default) creates at strength 0.5 and adds +0.1 per repeat call (cap 1.0), or sets the absolute strength you pass; action=disconnect deletes the synapse and unlinks both neurons — the destructive side. Idle synapses decay and crbro_maintenance prunes the weak; crbro_consolidate links neurons written in the same session by itself, so use this for relationships beyond co-occurrence. To read connections use crbro_inspect view=neuron. Returns synapse_id, action (created|strengthened|disconnected|absent) and strength.

ParametersJSON Schema
NameRequiredDescriptionDefault
toYesExact neuron id. Order does not matter — (a,b) and (b,a) are the same synapse.
fromYesExact neuron id, e.g. "project_octochat". Validated: an unknown id is an error.
typeNoRelationship kind, used only when the synapse is created (default conceptual). Ignored on strengthen and on disconnect.
actionNoconnect = create or strengthen (default); disconnect = delete the synapse and unlink both neurons. An absent synapse returns action:absent, removed:false, not an error.
contextNoOne line on the relationship. On strengthen it replaces the stored text; omit to keep it.
strengthNoAbsolute strength 0.0-1.0 to set, on create or on an existing synapse, instead of the 0.5 / +0.1 rule.

TDQS

A4.9/5.0
Behavior5/5

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

The description discloses behaviors well beyond the destructiveHint=true annotation: disconnect deletes and unlinks, repeated connects add +0.1 capped at 1.0, idle synapses decay, and absent synapses return action:absent rather than erroring. It also states that an absolute strength can override the default rule, giving the agent a clear mental model of side effects.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: purpose, defaults, destructive behavior, consolidation alternative, read alternative, and return value. It is front-loaded with the write semantics and uses compact, structured phrasing rather than filler.

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 tool with two actions, six parameters, validation semantics, and destructive potential, the description covers the full behavioral surface: creation, strengthening, deletion, absent handling, return values, and relationship to sibling tools. No critical calling context is missing.

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 every parameter is already documented in the schema. The description adds meaningful behavioral semantics on top, such as connect defaulting to strength 0.5 with +0.1 increments, disconnect being destructive, and strength overriding the default rule, which is valuable for correct invocation.

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 'Write: create, strengthen or delete the undirected synapse between two neurons', giving a specific verb, resource, and the three actions it supports. It is clearly distinguished from siblings by framing it as a write operation while routing reads to crbro_inspect.

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?

It explicitly contrasts with crbro_consolidate ('so use this for relationships beyond co-occurrence'), with crbro_maintenance for pruning, and with crbro_inspect for reading connections. It also clarifies when to use connect vs disconnect, including the default and side effects, leaving little to inference.

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

crbro_consolidateConsolidate the sessionA
Idempotent

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
summaryYesWhat was accomplished: concrete work, decisions, outcomes. Stored (after credential redaction) as the session log later sessions read.
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.

TDQS

A4.6/5.0
Behavior5/5

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

The description discloses a rich chain of side effects beyond what annotations carry: persistence of pending writes, credential stripping, kind redaction, heat recalculation, weak temporal synapse linking, manifest updates, and team-space sync with offline tolerance. It also explains the return values and the cost of non-use. Nothing contradicts the annotations — readOnlyHint=false matches the explicit 'Write' marker, and nothing conflicts with destructiveHint=false or idempotentHint=true.

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?

Four dense sentences efficiently pack purpose, trigger timing, side-effect chain, return values, failure consequence, and sibling routing without repetition. The description is front-loaded with 'Write' and the call-before-end instruction, giving the most critical usage signal immediately; only minor redundancy exists between 'the only way to log a session' and 'Not consolidating loses the session's knowledge.'

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?

With no output schema, the description correctly carries the burden of explaining returns and does so explicitly: session_id, facts_saved, decisions_saved, topics_touched, and per-space sync state. Combined with 100% parameter schema coverage and annotations disclosing idempotency and read/write class, an agent has everything needed to decide when and how to invoke this tool correctly.

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 coverage is 100%, so the baseline is 3; both summary and topics_touched already have detailed schema descriptions covering credential redaction, unknown-id dropping, and write-counter semantics. The description reinforces these points ('credentials stripped, kinds in redacted', 'topics_touched logs neurons you only read') and links topics_touched to the return value, but it adds only marginal parameter-level meaning beyond the schema.

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 opening 'Write: close the session — the only way to log a session' names a specific action and resource and explicitly marks this tool as the exclusive path for session logging, which distinguishes it from read-style siblings like crbro_recall and crbro_inspect. The verb-resource pair is unambiguous and the tool's role is immediately clear.

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?

'Call it before the conversation ends' gives an explicit trigger condition, and 'Not consolidating loses the session's knowledge' states the concrete consequence of not calling it. It also provides exclusion routing to named siblings ('Mid-session open items go to crbro_context; housekeeping is crbro_maintenance'), leaving no ambiguity about when this tool is the wrong choice.

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

crbro_contextWorking contextA
DestructiveIdempotent

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.

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

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important behavior: no-argument calls are safe reads, any argument triggers a write, writes return full state plus resolved/discarded fields, clear empties everything, re-adding identical text is a safe no-op, and unresolved open items are repeated back to users in later sessions. This aligns with the destructiveHint and idempotentHint annotations rather than contradicting them.

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

Conciseness5/5

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

The description is packed with actionable information yet remains well-structured: the core read/write distinction comes first, followed by parameter behavior and lifecycle consequences. Every sentence earns its place, and the cross-tool pointer to crbro_consolidate prevents misuse without extra fluff.

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?

There is no output schema, so the description carries the burden of explaining return behavior; it does so by stating that writes return the full state plus resolved and discarded, and reads touch nothing. It also covers the destructive nature of clear, the matcher semantics, the cap of recently_closed at 15, and the operational warning about stale open items. This is complete for a tool of this complexity.

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%, which already establishes a baseline of 3. The description adds meaningful operational context beyond the schema by explaining the no-args read-only default, the contrast between resolve and discard, and the workflow-level consequences of each parameter. It doesn't need to redefine each parameter since the schema descriptions are already thorough.

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-resource pair: 'Read or write the working context', and enumerates the concrete contents (active topics, open items, recently closed, last session). It also distinguishes itself from crbro_consolidate by explicitly stating that session logging belongs there, not here.

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?

It gives explicit invocation guidance: no arguments reads only, while any argument writes. It also gives when-to-use direction by instructing to close items as soon as they are done and explaining the consequences of leaving items open, and it names crbro_consolidate as the correct tool for session logging.

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

crbro_forgetForget for goodA
DestructiveIdempotent

Write, destructive: remove from disk after a quarantine copy (backup returned). Stage 3 of the lifecycle: something must not exist on disk at all — a credential, personal data, a whole neuron → crbro_forget; for knowledge that merely stopped being true use crbro_revise, which keeps the history. One mode per call. facts: delete entries of a neuron (facts, decisions, patterns, preferences, errors, debts, the map) by id or exact text. entire: delete the whole neuron and its synapses — call it without confirm_token first: the dry run reports what would happen and returns confirm_token. Show the user, get agreement, call again with the token; a stale token is refused. restore: bring back the newest quarantine copy. merge_into: union a neuron into another, rewire synapses, delete the source. session: delete one day's log. entire and merge_into refuse a shared neuron — crbro_share unshare first. A removed credential must still be rotated.

ParametersJSON Schema
NameRequiredDescriptionDefault
factsNoMode facts: fact ids, or the exact text of a fact, decision, pattern, preference, error or debt; the exact full text of the map removes the map. Deleted for good after a quarantine copy; decision/pattern removals travel to shared spaces like errors and debts.
entireNoMode entire: delete the whole neuron and its synapses. Without confirm_token it is a dry run — { neuron_id, dry_run:true, counts, shared_in, confirm_token }. Refused (no token) while the neuron is shared: crbro_share unshare first.
neuronNoNeuron id or name the mode acts on. Required for every mode except session. restore needs the exact neuron id.
restoreNoMode restore: bring back the newest quarantine copy of `neuron` (exact id). If the neuron exists again, the copy is merged into it (merged_into_existing:true, moved counts). The quarantine file stays, so restore is repeatable.
sessionNoMode session: session id ("session_2026-09-03" or "2026-09-03") whose log is deleted after a quarantine copy. `neuron` is not needed.
merge_intoNoMode merge_into: target neuron id or name. Everything of `neuron` is unioned into it, synapses rewired, then `neuron` is deleted (quarantined first). Refused while `neuron` is shared.
confirm_tokenNoOnly with entire:true — the token from the dry run. Derived from the neuron's counts, so it goes stale (and is refused) when the neuron changed in between.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only say destructiveHint=true, readOnlyHint=false, idempotentHint=true. The description massively expands on this: it states quarantine copy behavior, dry-run behavior for entire mode, stale token refusal, shared-neuron refusal, merged_into_existing behavior for restore, repeatable restore, and the security warning about credential rotation. It also discloses that textual deletion itself is irreversible after quarantine. With destructiveHint=true, the description goes well beyond what annotations provide, deeply informing an agent about consequences and safeguards.

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 long but dense and front-loaded with the most critical information ('Write, destructive... quarantine copy'). It is organized by mode, which makes it scannable for an agent. It loses one point because it packs a lot of secondary caveats (stale token derivation from counts, moved counts, merged_into_existing) in the schema rather than the main description, and the main description is quite long, but each sentence earns its place for a destructive multi-mode tool.

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 destructive tool with 7 parameters, 5 modes, no output schema, and only two boolean annotations, the description covers prerequisites (unshare shared neurons), sequencing (dry run first, then confirm token), safety (quarantine, restore path), security (rotation warning), and per-mode parameter requirements. No gaps are left for the agent to guess: it knows exactly what is required, what will be refused, and what will happen on success.

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%, but the description still adds meaning beyond the schema: it explains the mode gating (one mode per call), which parameter is required for which mode, the dry-run/token semantics, the exact behavior of 'facts' with decision/pattern removal propagation, and the quarantine/repeatability semantics of restore. The parameter descriptions in the schema are rich, and the main description coordinates across them with lifecycle context, prerequisites, and failure conditions.

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?

Description opens with 'Write, destructive: remove from disk after a quarantine copy (backup returned)', clearly identifying the tool as a destructive deletion operation with a safety mechanism. It enumerates five specific modes (facts, entire, restore, merge_into, session), each with a concrete effect, and distinguishes it from the sibling crbro_revise (which keeps history for knowledge that stopped being true). This is far beyond tautology and clearly separates this destructive tool from its non-destructive siblings.

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?

The description provides explicit guidance on when to use this tool vs the alternative: 'for knowledge that merely stopped being true use crbro_revise, which keeps the history' — naming the sibling and the selection condition. It also gives concrete stages of the lifecycle ('Stage 3 of the lifecycle') and per-mode behavioral directives such as the required two-call confirm_token flow, the sharing precondition (crbro_share unshare first), and the security note that a removed credential must still be rotated. This is exceptional usage guidance.

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

crbro_inspectInspect the brainA
Read-onlyIdempotent

Read-only views of the brain by id or name; to search by content use crbro_recall. Nothing is written by any view: every read leaves the brain untouched. view=status: version, brain path, totals, last boot/consolidation, semantic state, hot_topics_recalculated. view=neuron: one neuron in full — facts newest first, paged with limit/offset (superseded hidden unless include_superseded), decisions, patterns, preferences, errors, debts, entry_status, system map, and its connections resolved with name, type and strength (min_strength filters). view=neurons: rows hottest first (id, name, domain, type, heat, last_accessed, facts_count), filtered by domain, type, min_heat, paged with limit/offset. view=sessions: day logs newest first, the only place session summaries are read. view=global_map: one cluster per domain plus cross-domain bridges, computed live. Params of other views are ignored.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeNoview=neurons: only this neuron type.
viewYesWhich read to perform. Only the params listed for that view are honoured; the rest are ignored, never an error.
limitNoPage size. view=neuron: facts per page (default 40, max 200); view=neurons: rows (default 50, max 500); view=sessions: day logs (default 10, max 100). Other views ignore it.
domainNoview=neurons: exact domain match, e.g. "proyectos-web".
neuronNoview=neuron only, required there: neuron id (e.g. "project_octochat") or name (e.g. "OctoChat").
offsetNoItems to skip. view=neuron: facts (newest first); view=neurons: rows after the heat sort. Default 0.
min_heatNoview=neurons: minimum heat, 0.0-1.0. Heat blends access frequency, recency and connectivity.
min_strengthNoview=neuron: drop connections weaker than this (0.0-1.0). Omit or 0 = all.
include_supersededNoview=neuron: also return superseded and retracted facts (default false). Retired decisions, patterns, errors and debts are always returned, with entry_status saying which are retired.

Output Schema

ParametersJSON Schema
NameRequiredDescription
viewYes
neuronNo
statusNo
neuronsNo
sessionsNo
global_mapNo

TDQS

A4.7/5.0
Behavior5/5

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

The annotations already declare readOnly, idempotent, and non-destructive, and the description reinforces this with an explicit guarantee that every read leaves the brain untouched. It also adds non-obvious behavior: global_map is computed live, superseded facts are hidden by default, and params of non-selected views are silently ignored.

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

Conciseness5/5

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

The description is dense but deliberately organized per view, with the read-only safety statement and sibling alternative front-loaded. Each sentence carries a distinct fact; the only small redundancy is the repeated read-only idea, which is acceptable given the tool's breadth.

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 tool with five modes, nine params, and many siblings, the description covers all view semantics, param defaults, ignored params, and output shape sufficiently. An output schema exists, so the description does not need to restate return values, and nothing an agent needs to invoke the tool correctly is missing.

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?

Input schema coverage is 100%, so the baseline is 3, and the description goes further by tying each parameter to its view context (e.g., hottest-first ordering for offset, min_strength filtering connections, include_superseded overriding hidden facts). Much of it paraphrases schema descriptions, but it adds integrated view-specific behavior rather than merely repeating field names.

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 precise verb and resource: read-only views of the brain, and immediately differentiates itself from crbro_recall (search by content). The five view modes are enumerated with their exact outputs, so an agent can tell what crbro_inspect does without opening the schema.

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 an explicit alternative for content search (crbro_recall), marks view=sessions as the only place session summaries are read, and states that unrelated params are ignored. It does not enumerate exclusions against the other siblings, but for the main choice between inspect and recall the guidance is clear.

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

crbro_learnLearn somethingA

Write: store a fact, decision, pattern, preference, error or debt on a topic; the neuron is created if missing (or pass neuron_id). Stage 1 of the lifecycle: a new truth that REPLACES an old one → crbro_learn with supersedes (one call does both); to retire with no replacement use crbro_revise; to delete from disk use crbro_forget. crbro_recall first — it may already exist. The same fact text again is not duplicated: keywords merge (or keywords_replace) and a changed confidence applies (updated_in_place); text matching a retired fact or entry is refused with skipped_retired. Decisions always append; preferences never leave this machine. Credentials are replaced with a marker and listed in redacted — crbro_secret them, record only the name. Returns neuron_id, action, superseded count, near_duplicates (stored anyway; retire the old telling), supersedes_unmatched (still live) and totals.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeYeserror = a mistake plus its correction, in one entry. debt = a deliberate deferral: what was NOT done on purpose, its ceiling, and the revisit condition, e.g. "DEFERRED: protecting the PDFs. CEILING: anyone can download them without signing up. REVISIT WHEN: the signup flow works."
topicYesTopic name, e.g. "OctoChat", "Firebase", "SEO Strategy".
domainNoDomain, e.g. "proyectos-web". Applied when the neuron is created; on an existing neuron it only replaces the default "general" (crbro_revise domain replaces it unconditionally).
contentYesThe knowledge itself. Dense and self-contained: it is recalled without this conversation as context.
keywordsNoFacts only. 2-5 words a future question may use that the text does not contain: synonyms, the other language, the generic name of the product named. Indexed with the fact, never shown. The same text again with new keywords merges them.
neuron_idNoExact neuron id from crbro_recall, e.g. "project_octochat". Skips name matching entirely.
rationaleNoWhy the decision was taken. Stored and indexed with it; ignored for other types.
confidenceNo0.0-1.0, default 1.0. Facts only. On an exact-duplicate active fact the stored confidence is updated to this value (updated_in_place:true).
supersedesNoFacts this one replaces: their ids or exact text. They leave recall but stay in the file. Unmatched targets are reported and stay live.
keywords_replaceNoWhen the exact fact text already exists, replace its stored keywords with `keywords` instead of merging (default false). Teammates in a shared space only ever receive the union.

TDQS

A4.9/5.0
Behavior5/5

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

The description discloses many non-obvious behaviors beyond the annotations, such as deduplication on identical fact text, keyword merging versus replacement, updated_in_place confidence changes, refusal of text matching retired facts, decisions always appending, preferences never leaving the machine, and redaction of credentials. The annotations only indicate read/write/idempotency hints, so this behavioral detail is valuable and non-redundant.

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

Conciseness5/5

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

The description is dense but every clause earns its place: it front-loads the core action, then covers lifecycle, deduplication, security handling, and return values without repeating the schema. Given the tool's complexity and 10 parameters, the length is justified and the structure remains scannable.

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?

Despite having no output schema, the description enumerates return values (neuron_id, action, superseded count, near_duplicates, supersedes_unmatched, totals) and covers edge cases like retired text refusal, unmatched supersedes, and credential redaction. For a complex write tool with many siblings, this is a complete and self-sufficient description.

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 workflow-level meaning beyond individual parameter descriptions, such as how neuron_id skips name matching, how supersedes performs a combined replace operation, and how keywords/confidence behave on exact duplicates. It does not list every parameter, but it clarifies the interactions between them.

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 uses a specific verb ('store') with a clear resource: a fact, decision, pattern, preference, error, or debt on a topic. It explicitly differentiates from siblings by naming crbro_revise and crbro_forget for related but different lifecycle actions, so an agent can distinguish this tool from them immediately.

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?

The description explicitly tells the agent when to use this tool versus alternatives: use crbro_learn with supersedes to replace an old truth, use crbro_revise to retire without replacement, use crbro_forget to delete from disk, use crbro_secret for credentials, and call crbro_recall first because the neuron may already exist. This is clear, actionable routing guidance.

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

crbro_maintenanceBrain maintenanceA
DestructiveIdempotent

Write: brain housekeeping — recalculate heat, prune weak synapses, check integrity, rebuild the search index. Returns a report (counts, integrity_issues, repairable, notes) and flags debts without a revisit trigger. dry_run:true writes nothing at all (the global map is computed live, never cached). Extras are OFF unless asked: archive cold neurons (on a mature brain most look cold, and archived ones stop being searchable), unarchive them back, purge_boilerplate left by early miners, repair what the integrity check found. For session close use crbro_consolidate; to only read the brain use crbro_inspect.

ParametersJSON Schema
NameRequiredDescriptionDefault
repairNoFix what the integrity check found: dangling connection ids, synapse files pointing at missing neurons, entry_dates/entry_status keys with no live entry, manifest counters. Off in dry_run; the report lists repairs[] one line each.
archiveNoAlso move cold neurons (heat < 0.05, untouched 90+ days) out of the cortex into archives/. Off by default; run dry_run first and read archivable_neurons. Undo with unarchive.
dry_runNotrue = report only: no heat recalc, archiving, unarchiving, purge, repair, lock sweep, pruning or index rebuild, and no file written. Counts, debts and integrity checks still run.
unarchiveNoMove these neuron ids (or "all") from archives/ back into the cortex and reindex them. Off in dry_run; the report says archives_count and unarchived_neurons; unknown ids are listed in notes.
purge_boilerplateNoAlso delete contentless facts left by early miner versions ("Referenced in: file.md"). Off by default; every run reports how many there are. Neurons left empty are kept.

TDQS

A4.9/5.0
Behavior5/5

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

The description adds behavioral context beyond the annotations: dry_run writes nothing and the global map is computed live never cached, archiving stops cold neurons from being searchable, and destructive operations (prune, purge, repair) are listed. It also warns that on a mature brain most neurons look cold, so archive should be used with care. No contradiction with annotations.

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

Conciseness5/5

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

Three dense sentences carry all essential information: core action, dry_run safety, extras, and sibling routing. The description is front-loaded with the purpose and returns report first, and every sentence adds distinct value.

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?

With no output schema, the description covers the return report fields (counts, integrity_issues, repairable, notes) and per-parameter report elements. It also documents the no-op behavior of dry_run and the side effects of each optional flag, making the tool callable without external documentation.

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 description coverage is 100%, so the baseline is met; the description supplements the schema with practical consequences, such as archived neurons becoming unsearchable and dry_run never touching disk. It also groups parameters into 'extras' that are OFF unless asked, which helps an agent decide when to set them. This adds modest meaning beyond the already rich schema.

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 concrete action verb and resource ('Write: brain housekeeping') and enumerates specific operations: recalculate heat, prune weak synapses, check integrity, rebuild search index. It also distinguishes itself from siblings by directing session-close to crbro_consolidate and read-only to crbro_inspect.

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?

It explicitly names alternatives and the conditions for choosing them: 'For session close use crbro_consolidate; to only read the brain use crbro_inspect.' It also advises running dry_run first ('run dry_run first and read archivable_neurons') and notes that extras are OFF unless asked, clarifying the default invocation.

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

crbro_mapSystem mapA
DestructiveIdempotent

Read or replace a neuron's system map: ONE living document — where the system lives, what serves what, which pieces talk to each other, the traps that cost hours. crbro_inspect view=neuron already returns the map; use crbro_map to read it alone, or to rewrite it. Omit content to read (map:null if none); content replaces the previous version entirely (append-only maps rot); an empty string clears it. Read it before working on a system touched in past sessions; after changing the system rewrite the whole map. Reading never creates a neuron, writing does. Credentials are redacted on write. Atomic facts belong in crbro_learn — the map is the prose around them.

ParametersJSON Schema
NameRequiredDescriptionDefault
domainNoDomain if the neuron has to be created, e.g. "proyectos-web". Ignored when it exists.
neuronYesNeuron id or name, e.g. "project_octochat" or "OctoChat".
contentNoThe new map, replacing the old one whole; omit to read. Write the reference you will need next time: paths, ids, what-serves-what, gotchas. An empty string clears the map.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already signal mutating and destructive behavior, and the description adds valuable context: content replaces the entire previous version, empty string clears, append-only maps rot, reading never creates a neuron while writing does, and credentials are redacted on write. No contradiction with annotations.

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

Conciseness5/5

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

Dense but efficient: every sentence earns its place, covering function, alternatives, behavior, and usage timing. Key information is front-loaded in the first sentence.

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?

Complete for a read/write tool: read semantics, write semantics, deletion via empty string, creation side effects, credential redaction, relationship to siblings, and when to use are all covered. No output schema exists, but the description adequately states what a read returns.

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 100%, and the field descriptions already explain omit-to-read, replace-whole, and empty-clears. The description mostly reinforces these, adding only slight nuance like 'map:null if none'. Useful, but not substantial beyond the schema.

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 clear verb-resource pair: 'Read or replace a neuron's system map'. It also differentiates from crbro_inspect by explaining that crbro_inspect view=neuron already returns the map and crbro_map is for reading it alone or rewriting it.

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 explicit when-to-use guidance: read the map before working on a system touched in past sessions, rewrite it after changing the system, and keep atomic facts in crbro_learn instead. It also names crbro_inspect as the alternative for map access within a broader inspection.

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

crbro_recallRecallA
Read-onlyIdempotent

Read-only search of everything saved in earlier sessions — the full text of facts, decisions, patterns, preferences, errors, debts and maps, not just topic names; to read one neuron by id or name use crbro_inspect view=neuron. One result per neuron: its best matching chunk with matched_kind and matched_added, a confidence label (weak = little of the question covered; verify first), plus also_matched. Retired facts and entries never surface. Call it before asking the user what they may already have told you, and before crbro_learn. If nothing matches, retry with 2-4 phrasings in queries or fewer, distinctive words. has_map:true: read the system map with crbro_map before touching that system.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax neurons returned (default 10).
queryYesWhat to look for, e.g. "Firebase authentication setup". Fewer, distinctive terms beat full sentences.
domainNoOnly neurons in this domain (exact match, e.g. "proyectos-web").
queriesNoAlternative phrasings of the same question, searched together with query and fused by rank. Use synonyms, the other language and the concrete product name; 2-4 is plenty.

Output Schema

ParametersJSON Schema
NameRequiredDescription
hintYes
queryYes
resultsYes
total_resultsYes

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint, the description adds meaningful behavioral detail: one result per neuron, best matching chunk with matched_kind/matched_added, confidence label semantics, the 'retired facts never surface' rule, and what 'weak' confidence implies. These are not captured by annotations alone and significantly improve agent expectations.

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

Conciseness5/5

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

The description is dense but every sentence adds value: core scope, result format, confidence interpretation, exclusion behavior, usage timing, retry strategy, and conditional map guidance. It is front-loaded with the key purpose and then organizes supporting detail in a logical flow without redundancy.

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 four parameters, an output schema, and a large sibling family, the description is complete: it explains the return format, confidence label, exclusion behavior, when to call versus crbro_inspect/crbro_map/crbro_learn, and how to handle no matches. Nothing an agent needs to invoke it correctly is missing.

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 valuable semantic guidance beyond the schema, such as 'fewer, distinctive terms beat full sentences' and using synonyms, the other language, or the concrete product name for queries. This meaningfully improves parameter usage.

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 specific verb ('search') and resource ('everything saved in earlier sessions'), and explicitly contrasts with crbro_inspect view=neuron, distinguishing this tool's scope from the inspect sibling. The detail that it searches full text of facts/decisions/patterns rather than topic names adds precision.

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?

The description gives explicit when-to-use guidance: call it before asking the user what they may already have told you, and before crbro_learn. It also provides actionable retry guidance for empty results and instructs to use crbro_map when has_map:true, making alternatives clear.

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

crbro_reviseRevise a neuronA
Idempotent

Write: change what a neuron says without deleting anything. Stage 2 of the lifecycle: something stopped being true, or was never true, and nothing replaces it → crbro_revise (kept in the file, gone from recall, reversible with status active). If a replacement exists, crbro_learn with supersedes does both; for what must not exist on disk use crbro_forget. facts retires facts by id or exact text; entries retires decisions, patterns, errors and debts by exact text; status active reactivates either (local only on a shared neuron: the next sync re-applies the retirement, shared_warning says so). summary, domain, tags and name edit metadata in the same call (tags replaces the whole list; the id never changes). Anything in unmatched is STILL LIVE — fix and re-run.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNoRename the neuron. Its id, file, synapses and shared state stay the same.
noteNoWhy. Stored as revision_note on facts and entry_status.note on entries. The next reader will wonder.
tagsNoReplace the WHOLE tag list (trimmed, deduplicated). On protocol neurons re-send the priority: and source: tags or they are gone.
factsNoFacts to move to `status`: their ids (from crbro_recall) or exact text (trimmed, case-insensitive). For superseded/retracted only active facts match; for active only retired ones do.
domainNoReplace the neuron domain unconditionally, e.g. "proyectos-web".
neuronYesNeuron id or name holding what to revise, e.g. "project_octochat".
statusNosuperseded = a newer truth exists (default); retracted = it was never true; active = reactivate a retired fact or entry. Reactivation is local: on a shared neuron the next sync re-applies the retirement (the response carries shared_warning).
entriesNoExact texts of decisions, patterns, errors or debts to move to `status`. Retired entries stay in the file (entry_status) but leave recall like a superseded fact.
summaryNoReplace the neuron summary. Credentials are redacted and listed in redacted.

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint false, destructiveHint false, and idempotentHint true, and the description adds meaningful context beyond those: 'without deleting anything,' 'kept in the file, gone from recall, reversible with status active,' the local-only reactivation caveat on shared neurons, 'tags replaces the whole list,' and 'Anything in unmatched is STILL LIVE — fix and re-run.' This fully discloses side effects and non-destructive behavior.

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

Conciseness5/5

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

The description is dense but every clause earns its place; it front-loads the one-line purpose and then packs lifecycle context, sibling differentiation, parameter behavior, metadata editing, and warnings into a compact form. There is no filler or repetition.

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 9 parameters and no output schema, the description covers the lifecycle stage, alternatives, matching semantics, status meanings, shared-neuron caveats, metadata edits, and the unmatched-live warning. Even the response's shared_warning is anticipated. Nothing essential for selecting or invoking the tool correctly is missing.

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 is 3, but the description meaningfully enriches the parameters: it explains facts vs entries matching by id or exact text, default status 'superseded', active-only vs retired-only matching, the local reactivation limitation, and that tags replaces the whole list. This goes well beyond the schema's per-field descriptions.

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 concrete verb and resource: 'Write: change what a neuron says without deleting anything,' followed by its lifecycle stage. It clearly distinguishes crbro_revise from siblings by naming crbro_learn with supersedes and crbro_forget as alternatives, so an agent can tell them apart.

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?

The description gives explicit when-to-use guidance: 'something stopped being true, or was never true, and nothing replaces it → crbro_revise.' It also gives when-not-to-use and alternatives: 'If a replacement exists, crbro_learn with supersedes does both; for what must not exist on disk use crbro_forget.' This is exactly the routing information an agent needs.

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

crbro_secretKeychain secretA
DestructiveIdempotent

Read or write credentials in the operating system's keychain (macOS Keychain, Linux Secret Service, Windows DPAPI): CRBRO keeps no copy, invents no crypto, and no sync or team space can reach the store. When the user hands you a credential, set it here, then record only the NAME with crbro_learn. get returns the value for the task at hand — an environment variable of the same name wins; a missing secret returns found:false, not an error — never print it back unless the user asked. list returns names only; remove deletes one; status says which store this machine has (none is a normal answer; env vars still work). Names are SCREAMING_SNAKE_CASE; set updates in place and rejects empty values.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNoSCREAMING_SNAKE_CASE, e.g. WORDPRESS_APP_PASSWORD. Required for get, set and remove.
valueNoThe credential itself, non-empty. Only for set.
actionYesget = read one, set = store or update one, list = names only, remove = delete one, status = which keychain this machine offers, or why none.
descriptionNoWhat it is for, e.g. "WordPress example.com - REST API". Only for set.

TDQS

A4.8/5.0
Behavior5/5

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

While annotations already mark destructiveHint and idempotentHint, the description goes further by disclosing privacy properties (CRBRO keeps no copy, invents no crypto, no sync or team space can reach the store), special return behavior (missing secret returns found:false, not an error), and operational rules (never print the value back unless asked; set rejects empty values; status with no store is normal). No contradiction with 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 dense and front-loaded with the core resource and action, and every sentence contributes either an action behavior, a boundary condition, or a security rule. It is slightly long and semicolon-heavy, but it earns its length given the multi-action nature of the tool, so it is not padded.

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 multi-action secret-store tool with no output schema and a destructive remove action, the description covers all operational requirements: what each action does, what inputs are needed, edge cases, environment-variable precedence, naming conventions, and privacy constraints. It is complete enough for an agent to invoke any of the five actions 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, but the description adds meaning beyond the schema: it imposes a naming convention (SCREAMING_SNAKE_CASE), explains that set updates in place and rejects empty values, and clarifies behavior of each action such as list returning names only and status indicating which store exists. It doesn't fully expand every parameter, but the schema already handles that, so this is above baseline.

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: 'Read or write credentials in the operating system's keychain,' then enumerates each action (get, set, list, remove, status). It also differentiates from sibling crbro_learn by directing that only the NAME be recorded there, so an agent can tell which tool holds the credential value versus which holds a learned name.

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?

The description gives concrete when-to-use instructions: 'When the user hands you a credential, set it here, then record only the NAME with crbro_learn.' It specifies action semantics for every branch, clarifies that a missing secret returns found:false rather than an error, and notes that env vars of the same name win. This is explicit enough for an agent to select the correct action and companion workflow.

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

crbro_shareShare a projectA

Write: put one neuron into a team space, or take it out with unshare. Call it without confirm first: the dry run reports what would be sent — ops_to_emit, skipped_preferences (preferences never leave this machine) — and refuses outright if it finds a credential (crbro_forget it and rotate it). Show the user, get agreement, call again with the confirm token; a stale token is refused. Entries go out on the next crbro_space action=sync or consolidate, and from then on everything learned about that project flows to the team. unshare stops future notes; what was already sent stays in the remote and in teammates' brains. Spaces are managed with crbro_space.

ParametersJSON Schema
NameRequiredDescriptionDefault
spaceNoSpace name, as created or joined with crbro_space. Required unless unshare:true.
neuronYesNeuron id or name to share or unshare.
confirmNoThe confirm_token from the dry run — returned only when no credential was found. Omit the first time. Ignored with unshare.
unshareNoStop following `neuron` in its space: no more notes go out, the next sync ignores it, and the neuron can then be forgotten. Already-sent notes stay in the remote and in teammates' brains. space and confirm are ignored in this mode.

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false), it discloses the dry-run behavior, that preferences never leave the machine, that credentials cause refusal, that stale confirm tokens are refused, and that entries only go out on the next sync/consolidate. It also states unshare keeps already-sent content in the remote, which is a meaningful side effect. No contradiction with 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 dense but each sentence carries operational value: the dry-run protocol, refusal conditions, sync timing, and unshare semantics. It is not as compact as it could be, and the credential-rotation aside slightly interrupts the flow, but it remains well-structured and front-loaded with the core action.

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?

With no output schema, the description compensates by telling the agent what a dry run returns (ops_to_emit, skipped_preferences, confirm token), what can go wrong (credential, stale token), and when effects are visible (next sync or consolidate). The tool is fully callable from this description alone.

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 meaning beyond field names by explaining confirm is a token from the dry run and is omitted the first time, and by clarifying that space and confirm are ignored in unshare mode. This pushes it above baseline.

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 clear verb and resource: 'put one neuron into a team space, or take it out with unshare.' It distinguishes the share and unshare behaviors and contrasts with sibling crbro_space ('Spaces are managed with crbro_space'), so an agent knows exactly what this tool does and what it does 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?

The description gives an explicit two-phase protocol: call without confirm first, show the user the dry-run report, get agreement, then call again with the confirm token. It also names alternatives for related cases: crbro_forget for credential handling and crbro_space for space management.

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

crbro_spaceTeam spaceA

Read or write team spaces — shared memory with teammates: a private git repository holding notes about the projects you choose to share; nothing else from your brain goes near it. create starts one (name, remote, author); join clones one a teammate created; status reads your identity and spaces; sync exchanges notes now — the manual form of what crbro_boot and crbro_consolidate do alone, useful right after crbro_share (offline is a normal answer, not a failure); leave pushes pending notes, deletes the local copy and stops following its neurons (neurons untouched). Joining shares nothing: put each project in with crbro_share. create and join reply ok:false with the reason on failure.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNoShort name, e.g. "equipo" — the same on everyone's machine. Required for create, join and leave; optional for sync (omit = every space); ignored for status.
actionYescreate = start a new space and push it; join = clone one a teammate created; status = your identity and spaces; sync = exchange notes now; leave = sync, then forget the space locally.
authorNoHow your notes are signed, e.g. "ana". Lowercase, no spaces. Required for create and join.
branchNoBranch to use (default "main"). create and join only.
remoteNoGit URL of a private repository — EMPTY for create, the same URL the creator used for join. E.g. git@github.com:acme/team-memory.git.

TDQS

A4.6/5.0
Behavior5/5

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

The description goes well beyond the annotations by explaining the privacy boundary ('nothing else from your brain goes near it'), the side effects of leave ('pushes pending notes, deletes the local copy... neurons untouched'), and the offline behavior ('offline is a normal answer, not a failure'). These are behavioral facts an agent could not derive from structured fields.

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 dense and front-loaded, with each clause earning its place and no filler. It is long, but the tool has five subcommands and multiple cross-tool relationships to cover.

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 no output schema, it still conveys failure shape ('create and join reply ok:false with the reason'), sync semantics, and side effects. Combined with the comprehensive input schema, an agent has enough context to invoke every action correctly.

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 coverage is 100% and each parameter already has action-specific descriptions. The description reinforces that name, remote, and author matter for create/join, but it adds little new meaning beyond what the schema provides.

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 names a concrete resource ('team spaces' as shared git repositories) and enumerates five discrete actions with their effects: create, join, status, sync, leave. This makes it immediately distinguishable from siblings such as crbro_share, which is referenced for a different purpose.

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?

It gives explicit routing: sync is 'the manual form of what crbro_boot and crbro_consolidate do alone, useful right after crbro_share', and 'Joining shares nothing: put each project in with crbro_share'. This tells an agent when to reach for this tool versus named alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev2.0.1
    • Changedcrbro_inspect1 field changed
      • changedInput schema / properties / neuron / description
        Previous value: -"view=neuron only, required there: neuron id (e.g. \"project_octochat\") or name (e.g. \"OctoChat\"). Reading bumps access_count and last_accessed."New value: +"view=neuron only, required there: neuron id (e.g. \"project_octochat\") or name (e.g. \"OctoChat\")."
  2. 20 tool updatesv2.0.0
    • Changedcrbro_audit2 fields changed
      • addedOutput schema / properties / session_findings
        Added value: +{
+  "items": {
+    "additionalProperties": {},
+    "properties": {
+      "date": {
+        "type": "string"
+      },
+      "kinds": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "session_id": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "session_id",
+      "date",
+      "kinds"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
      • addedOutput schema / properties / sessions_affected
        Added value: +{
+  "type": "number"
+}
    • Changedcrbro_connect6 fields changed
      • addedInput schema / properties / action
        Added value: +{
+  "description": "connect = create or strengthen (default); disconnect = delete the synapse and unlink both neurons. An absent synapse returns action:absent, removed:false, not an error.",
+  "enum": [
+    "connect",
+    "disconnect"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / from / description
        Previous value: -"Source neuron id, e.g. \"project_octochat\". Not validated: use an exact id from crbro_recall or crbro_neurons, or the synapse points at nothing."New value: +"Exact neuron id, e.g. \"project_octochat\". Validated: an unknown id is an error."
      • addedInput schema / properties / strength
        Added value: +{
+  "description": "Absolute strength 0.0-1.0 to set, on create or on an existing synapse, instead of the 0.5 / +0.1 rule.",
+  "maximum": 1,
+  "minimum": 0,
+  "type": "number"
+}
      • changedInput schema / properties / to / description
        Previous value: -"Target neuron id. Order does not matter — (a,b) and (b,a) are the same synapse."New value: +"Exact neuron id. Order does not matter — (a,b) and (b,a) are the same synapse."
      • changedInput schema / properties / type / description
        Previous value: -"Relationship kind. Used only on creation; a strengthening call keeps the existing type."New value: +"Relationship kind, used only when the synapse is created (default conceptual). Ignored on strengthen and on disconnect."
      • changedInput schema / required
        Previous value: -[
-  "from",
-  "to",
-  "type"
-]New value: +[
+  "from",
+  "to"
+]
    • Removedcrbro_connections
    • Changedcrbro_consolidate2 fields changed
      • 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"
+}
    • Changedcrbro_context3 fields changed
      • 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."
    • Changedcrbro_forget8 fields changed
      • addedInput schema / properties / confirm_token
        Added value: +{
+  "description": "Only with entire:true — the token from the dry run. Derived from the neuron's counts, so it goes stale (and is refused) when the neuron changed in between.",
+  "type": "string"
+}
      • addedInput schema / properties / entire
        Added value: +{
+  "description": "Mode entire: delete the whole neuron and its synapses. Without confirm_token it is a dry run — { neuron_id, dry_run:true, counts, shared_in, confirm_token }. Refused (no token) while the neuron is shared: crbro_share unshare first.",
+  "type": "boolean"
+}
      • changedInput schema / properties / facts / description
        Previous value: -"Fact ids, or the exact text of a fact, decision, pattern, preference, error or debt. The exact full text of the map removes the map."New value: +"Mode facts: fact ids, or the exact text of a fact, decision, pattern, preference, error or debt; the exact full text of the map removes the map. Deleted for good after a quarantine copy; decision/pattern removals travel to shared spaces like errors and debts."
      • addedInput schema / properties / merge_into
        Added value: +{
+  "description": "Mode merge_into: target neuron id or name. Everything of `neuron` is unioned into it, synapses rewired, then `neuron` is deleted (quarantined first). Refused while `neuron` is shared.",
+  "type": "string"
+}
      • changedInput schema / properties / neuron / description
        Previous value: -"Neuron id or name holding the entries."New value: +"Neuron id or name the mode acts on. Required for every mode except session. restore needs the exact neuron id."
      • addedInput schema / properties / restore
        Added value: +{
+  "description": "Mode restore: bring back the newest quarantine copy of `neuron` (exact id). If the neuron exists again, the copy is merged into it (merged_into_existing:true, moved counts). The quarantine file stays, so restore is repeatable.",
+  "type": "boolean"
+}
      • addedInput schema / properties / session
        Added value: +{
+  "description": "Mode session: session id (\"session_2026-09-03\" or \"2026-09-03\") whose log is deleted after a quarantine copy. `neuron` is not needed.",
+  "type": "string"
+}
      • removedInput schema / required
        Removed value: -[
-  "neuron",
-  "facts"
-]
    • Removedcrbro_global_map
    • Removedcrbro_hot_topics
    • Addedcrbro_inspect
    • Changedcrbro_learn3 fields changed
      • changedInput schema / properties / confidence / description
        Previous value: -"0.0-1.0, default 1.0. Facts only."New value: +"0.0-1.0, default 1.0. Facts only. On an exact-duplicate active fact the stored confidence is updated to this value (updated_in_place:true)."
      • changedInput schema / properties / domain / description
        Previous value: -"Domain, e.g. \"proyectos-web\". Applied when the neuron is created; on an existing neuron it only replaces the default \"general\"."New value: +"Domain, e.g. \"proyectos-web\". Applied when the neuron is created; on an existing neuron it only replaces the default \"general\" (crbro_revise domain replaces it unconditionally)."
      • addedInput schema / properties / keywords_replace
        Added value: +{
+  "description": "When the exact fact text already exists, replace its stored keywords with `keywords` instead of merging (default false). Teammates in a shared space only ever receive the union.",
+  "type": "boolean"
+}
    • Changedcrbro_maintenance4 fields changed
      • changedInput schema / properties / archive / description
        Previous value: -"Also move cold neurons (heat < 0.05, untouched 90+ days) out of the cortex. Off by default; run dry_run first and read archivable_neurons. Restore by moving the file from archives/ back into cortex/."New value: +"Also move cold neurons (heat < 0.05, untouched 90+ days) out of the cortex into archives/. Off by default; run dry_run first and read archivable_neurons. Undo with unarchive."
      • changedInput schema / properties / dry_run / description
        Previous value: -"true = report only: no heat recalc, archiving, purge, lock sweep, pruning or index rebuild. Counts, debts and integrity checks still run."New value: +"true = report only: no heat recalc, archiving, unarchiving, purge, repair, lock sweep, pruning or index rebuild, and no file written. Counts, debts and integrity checks still run."
      • addedInput schema / properties / repair
        Added value: +{
+  "description": "Fix what the integrity check found: dangling connection ids, synapse files pointing at missing neurons, entry_dates/entry_status keys with no live entry, manifest counters. Off in dry_run; the report lists repairs[] one line each.",
+  "type": "boolean"
+}
      • addedInput schema / properties / unarchive
        Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "const": "all",
+      "type": "string"
+    }
+  ],
+  "description": "Move these neuron ids (or \"all\") from archives/ back into the cortex and reindex them. Off in dry_run; the report says archives_count and unarchived_neurons; unknown ids are listed in notes."
+}
    • Removedcrbro_neuron
    • Removedcrbro_neurons
    • Changedcrbro_revise11 fields changed
      • addedInput schema / properties / domain
        Added value: +{
+  "description": "Replace the neuron domain unconditionally, e.g. \"proyectos-web\".",
+  "type": "string"
+}
      • addedInput schema / properties / entries
        Added value: +{
+  "description": "Exact texts of decisions, patterns, errors or debts to move to `status`. Retired entries stay in the file (entry_status) but leave recall like a superseded fact.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • changedInput schema / properties / facts / description
        Previous value: -"Facts to retire: their ids (from crbro_recall) or exact text (trimmed, case-insensitive). Already-retired facts never match."New value: +"Facts to move to `status`: their ids (from crbro_recall) or exact text (trimmed, case-insensitive). For superseded/retracted only active facts match; for active only retired ones do."
      • addedInput schema / properties / name
        Added value: +{
+  "description": "Rename the neuron. Its id, file, synapses and shared state stay the same.",
+  "type": "string"
+}
      • changedInput schema / properties / neuron / description
        Previous value: -"Neuron id or name holding the facts, e.g. \"project_octochat\"."New value: +"Neuron id or name holding what to revise, e.g. \"project_octochat\"."
      • changedInput schema / properties / note / description
        Previous value: -"Why it stopped being true. The next reader will wonder."New value: +"Why. Stored as revision_note on facts and entry_status.note on entries. The next reader will wonder."
      • changedInput schema / properties / status / description
        Previous value: -"superseded = there is a newer truth (default); retracted = it was never true."New value: +"superseded = a newer truth exists (default); retracted = it was never true; active = reactivate a retired fact or entry. Reactivation is local: on a shared neuron the next sync re-applies the retirement (the response carries shared_warning)."
      • changedInput schema / properties / status / enum
        Previous value: -[
-  "superseded",
-  "retracted"
-]New value: +[
+  "superseded",
+  "retracted",
+  "active"
+]
      • addedInput schema / properties / summary
        Added value: +{
+  "description": "Replace the neuron summary. Credentials are redacted and listed in redacted.",
+  "type": "string"
+}
      • addedInput schema / properties / tags
        Added value: +{
+  "description": "Replace the WHOLE tag list (trimmed, deduplicated). On protocol neurons re-send the priority: and source: tags or they are gone.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • changedInput schema / required
        Previous value: -[
-  "neuron",
-  "facts"
-]New value: +[
+  "neuron"
+]
    • Removedcrbro_session_log
    • Removedcrbro_sessions
    • Changedcrbro_share5 fields changed
      • changedInput schema / properties / confirm / description
        Previous value: -"The confirm_token from the dry run — returned only when no credential was found. Omit the first time."New value: +"The confirm_token from the dry run — returned only when no credential was found. Omit the first time. Ignored with unshare."
      • changedInput schema / properties / neuron / description
        Previous value: -"Neuron id or name to share."New value: +"Neuron id or name to share or unshare."
      • changedInput schema / properties / space / description
        Previous value: -"Space name, as created or joined with crbro_space."New value: +"Space name, as created or joined with crbro_space. Required unless unshare:true."
      • addedInput schema / properties / unshare
        Added value: +{
+  "description": "Stop following `neuron` in its space: no more notes go out, the next sync ignores it, and the neuron can then be forgotten. Already-sent notes stay in the remote and in teammates' brains. space and confirm are ignored in this mode.",
+  "type": "boolean"
+}
      • changedInput schema / required
        Previous value: -[
-  "neuron",
-  "space"
-]New value: +[
+  "neuron"
+]
    • Changedcrbro_space4 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"create = start a new space and push it, join = clone one a teammate created, status = your identity and the spaces you are in."New value: +"create = start a new space and push it; join = clone one a teammate created; status = your identity and spaces; sync = exchange notes now; leave = sync, then forget the space locally."
      • changedInput schema / properties / action / enum
        Previous value: -[
-  "create",
-  "join",
-  "status"
-]New value: +[
+  "create",
+  "join",
+  "status",
+  "sync",
+  "leave"
+]
      • changedInput schema / properties / branch / description
        Previous value: -"Branch to use (default \"main\")."New value: +"Branch to use (default \"main\"). create and join only."
      • changedInput schema / properties / name / description
        Previous value: -"Short name, e.g. \"equipo\" — the same on everyone's machine. Required for create and join."New value: +"Short name, e.g. \"equipo\" — the same on everyone's machine. Required for create, join and leave; optional for sync (omit = every space); ignored for status."
    • Removedcrbro_status
    • Removedcrbro_sync
  3. 1 tool updatev1.16.0
    • Changedcrbro_status4 fields changed
      • addedOutput schema / properties / last_boot / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / last_boot / type
        Removed value: -[
-  "string",
-  "null"
-]
      • addedOutput schema / properties / last_consolidation / anyOf
        Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
      • removedOutput schema / properties / last_consolidation / type
        Removed value: -[
-  "string",
-  "null"
-]
  4. 3 tool updates
    • Changedcrbro_learn1 field changed
      • addedInput schema / properties / keywords
        Added value: +{
+  "description": "Facts only. 2-5 words a future question may use that the text does not contain: synonyms, the other language, the generic name of the product named. Indexed with the fact, never shown. The same text again with new keywords merges them.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • Changedcrbro_recall1 field changed
      • addedInput schema / properties / queries
        Added value: +{
+  "description": "Alternative phrasings of the same question, searched together with query and fused by rank. Use synonyms, the other language and the concrete product name; 2-4 is plenty.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • Changedcrbro_status1 field changed
      • addedOutput schema / properties / semantic
        Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "enabled": {
+      "type": "boolean"
+    },
+    "home": {
+      "type": "string"
+    },
+    "installed": {
+      "type": "boolean"
+    },
+    "mode": {
+      "type": "string"
+    },
+    "model": {
+      "type": "string"
+    },
+    "model_downloaded": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "installed",
+    "enabled",
+    "mode",
+    "model_downloaded",
+    "home",
+    "model"
+  ],
+  "type": "object"
+}
  5. 22 tool updatesv1.14.0
    • Addedcrbro_audit
    • Changedcrbro_connect4 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"Description of the relationship"New value: +"One line on the relationship. On strengthen it replaces the stored text; omit to keep it."
      • changedInput schema / properties / from / description
        Previous value: -"Source neuron ID"New value: +"Source neuron id, e.g. \"project_octochat\". Not validated: use an exact id from crbro_recall or crbro_neurons, or the synapse points at nothing."
      • changedInput schema / properties / to / description
        Previous value: -"Target neuron ID"New value: +"Target neuron id. Order does not matter — (a,b) and (b,a) are the same synapse."
      • changedInput schema / properties / type / description
        Previous value: -"Connection type"New value: +"Relationship kind. Used only on creation; a strengthening call keeps the existing type."
    • Changedcrbro_connections3 fields changed
      • changedInput schema / properties / min_strength / description
        Previous value: -"Minimum synapse strength (0.0-1.0)"New value: +"Drop connections weaker than this (0.0-1.0). Omit for all; 0 is no filter."
      • changedInput schema / properties / neuron_id / description
        Previous value: -"Neuron ID to get connections for"New value: +"Exact neuron id, e.g. \"project_octochat\". Names are not resolved here — get the id from crbro_recall or crbro_neurons."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "connections": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "context": {
+            "type": "string"
+          },
+          "strength": {
+            "type": "number"
+          },
+          "target_id": {
+            "type": "string"
+          },
+          "target_name": {
+            "type": "string"
+          },
+          "type": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "target_id",
+          "target_name",
+          "type",
+          "strength",
+          "context"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "neuron_id": {
+      "type": "string"
+    },
+    "total_connections": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "neuron_id",
+    "total_connections",
+    "connections"
+  ],
+  "type": "object"
+}
    • Changedcrbro_consolidate1 field changed
      • 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."
    • Changedcrbro_context3 fields changed
      • 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."
    • Addedcrbro_forget
    • Changedcrbro_global_map1 field changed
      • changedInput schema / properties / rebuild / description
        Previous value: -"Force rebuild the map (default: use cached)"New value: +"true = rescan every neuron and rewrite the cached map (slower on big brains). Default: serve the cache, building it only if missing — it can lag recent learning; crbro_maintenance also rebuilds it."
    • Changedcrbro_hot_topics2 fields changed
      • changedInput schema / properties / limit / description
        Previous value: -"Number of topics to return (default 15)"New value: +"Topics to return (default 15; the cache never holds more than 20)."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "last_recalculated": {
+      "type": "string"
+    },
+    "topics": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "domain": {
+            "type": "string"
+          },
+          "heat": {
+            "type": "number"
+          },
+          "id": {
+            "type": "string"
+          },
+          "last_access": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "heat",
+          "last_access",
+          "domain"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "topics"
+  ],
+  "type": "object"
+}
    • Changedcrbro_learn9 fields changed
      • changedInput schema / properties / confidence / description
        Previous value: -"Confidence level 0.0-1.0 (default 1.0)"New value: +"0.0-1.0, default 1.0. Facts only."
      • changedInput schema / properties / content / description
        Previous value: -"The knowledge content to remember"New value: +"The knowledge itself. Dense and self-contained: it is recalled without this conversation as context."
      • changedInput schema / properties / domain / description
        Previous value: -"Domain category (e.g., \"proyectos-web\", \"infraestructura\")"New value: +"Domain, e.g. \"proyectos-web\". Applied when the neuron is created; on an existing neuron it only replaces the default \"general\"."
      • addedInput schema / properties / neuron_id
        Added value: +{
+  "description": "Exact neuron id from crbro_recall, e.g. \"project_octochat\". Skips name matching entirely.",
+  "type": "string"
+}
      • changedInput schema / properties / rationale / description
        Previous value: -"Rationale for decisions"New value: +"Why the decision was taken. Stored and indexed with it; ignored for other types."
      • addedInput schema / properties / supersedes
        Added value: +{
+  "description": "Facts this one replaces: their ids or exact text. They leave recall but stay in the file. Unmatched targets are reported and stay live.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • changedInput schema / properties / topic / description
        Previous value: -"The topic name (e.g., \"OctoChat\", \"Firebase\", \"SEO Strategy\")"New value: +"Topic name, e.g. \"OctoChat\", \"Firebase\", \"SEO Strategy\"."
      • changedInput schema / properties / type / description
        Previous value: -"Type of knowledge to store"New value: +"error = a mistake plus its correction, in one entry. debt = a deliberate deferral: what was NOT done on purpose, its ceiling, and the revisit condition, e.g. \"DEFERRED: protecting the PDFs. CEILING: anyone can download them without signing up. REVISIT WHEN: the signup flow works.\""
      • changedInput schema / properties / type / enum
        Previous value: -[
-  "fact",
-  "decision",
-  "pattern",
-  "preference"
-]New value: +[
+  "fact",
+  "decision",
+  "pattern",
+  "preference",
+  "error",
+  "debt"
+]
    • Changedcrbro_maintenance3 fields changed
      • addedInput schema / properties / archive
        Added value: +{
+  "description": "Also move cold neurons (heat < 0.05, untouched 90+ days) out of the cortex. Off by default; run dry_run first and read archivable_neurons. Restore by moving the file from archives/ back into cortex/.",
+  "type": "boolean"
+}
      • changedInput schema / properties / dry_run / description
        Previous value: -"If true, only report what would happen without acting"New value: +"true = report only: no heat recalc, archiving, purge, lock sweep, pruning or index rebuild. Counts, debts and integrity checks still run."
      • addedInput schema / properties / purge_boilerplate
        Added value: +{
+  "description": "Also delete contentless facts left by early miner versions (\"Referenced in: file.md\"). Off by default; every run reports how many there are. Neurons left empty are kept.",
+  "type": "boolean"
+}
    • Addedcrbro_map
    • Changedcrbro_neuron4 fields changed
      • changedInput schema / properties / id / description
        Previous value: -"Neuron ID (e.g., \"project_octochat\") or name (e.g., \"OctoChat\")"New value: +"Neuron id (e.g. \"project_octochat\") or name (e.g. \"OctoChat\")."
      • addedInput schema / properties / include_superseded
        Added value: +{
+  "description": "Also return superseded and retracted facts (default false).",
+  "type": "boolean"
+}
      • addedInput schema / properties / limit
        Added value: +{
+  "description": "Facts to return: default 40, max 200.",
+  "type": "number"
+}
      • addedInput schema / properties / offset
        Added value: +{
+  "description": "Facts to skip. Facts come newest first.",
+  "type": "number"
+}
    • Changedcrbro_neurons5 fields changed
      • changedInput schema / properties / domain / description
        Previous value: -"Filter by domain (e.g., \"proyectos-web\")"New value: +"Only this domain, e.g. \"proyectos-web\"."
      • changedInput schema / properties / limit / description
        Previous value: -"Max results (default 50)"New value: +"Max rows (default 50)."
      • changedInput schema / properties / min_heat / description
        Previous value: -"Minimum heat score (0.0-1.0)"New value: +"Minimum heat, 0.0-1.0. Heat blends access frequency, recency and connectivity."
      • changedInput schema / properties / type / description
        Previous value: -"Filter by neuron type"New value: +"Only this neuron type."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "neurons": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "domain": {
+            "type": "string"
+          },
+          "facts_count": {
+            "type": "number"
+          },
+          "heat": {
+            "type": "number"
+          },
+          "id": {
+            "type": "string"
+          },
+          "last_accessed": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "type": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "domain",
+          "type",
+          "heat",
+          "last_accessed",
+          "facts_count"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "total",
+    "neurons"
+  ],
+  "type": "object"
+}
    • Changedcrbro_recall4 fields changed
      • changedInput schema / properties / domain / description
        Previous value: -"Filter by domain"New value: +"Only neurons in this domain (exact match, e.g. \"proyectos-web\")."
      • changedInput schema / properties / limit / description
        Previous value: -"Max results (default 10)"New value: +"Max neurons returned (default 10)."
      • changedInput schema / properties / query / description
        Previous value: -"What to search for (e.g., \"Firebase authentication setup\")"New value: +"What to look for, e.g. \"Firebase authentication setup\". Fewer, distinctive terms beat full sentences."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "hint": {
+      "type": "string"
+    },
+    "query": {
+      "type": "string"
+    },
+    "results": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "also_matched": {
+            "items": {
+              "additionalProperties": false,
+              "properties": {
+                "added": {
+                  "type": "string"
+                },
+                "kind": {
+                  "type": "string"
+                },
+                "text": {
+                  "type": "string"
+                }
+              },
+              "required": [
+                "text",
+                "kind",
+                "added"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "confidence": {
+            "enum": [
+              "strong",
+              "weak"
+            ],
+            "type": "string"
+          },
+          "domain": {
+            "type": "string"
+          },
+          "has_map": {
+            "type": "boolean"
+          },
+          "heat": {
+            "type": "number"
+          },
+          "matched_added": {
+            "type": "string"
+          },
+          "matched_kind": {
+            "type": "string"
+          },
+          "matched_terms": {
+            "type": "number"
+          },
+          "matching_content": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "neuron_id": {
+            "type": "string"
+          },
+          "query_terms": {
+            "type": "number"
+          },
+          "relevance_score": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "neuron_id",
+          "name",
+          "domain",
+          "relevance_score",
+          "matching_content",
+          "heat"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total_results": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "query",
+    "total_results",
+    "results",
+    "hint"
+  ],
+  "type": "object"
+}
    • Addedcrbro_revise
    • Addedcrbro_secret
    • Changedcrbro_session_log4 fields changed
      • changedInput schema / properties / decisions_made / description
        Previous value: -"Number of decisions recorded"New value: +"Decisions recorded. Summed into the day total on same-day calls."
      • changedInput schema / properties / key_facts_added / description
        Previous value: -"Number of new facts stored"New value: +"New facts stored. Summed into the day total on same-day calls."
      • changedInput schema / properties / summary / description
        Previous value: -"Summary of what happened in this session"New value: +"What happened in this session. Appended if today already has an entry."
      • changedInput schema / properties / topics_touched / description
        Previous value: -"List of neuron IDs that were relevant"New value: +"Relevant neuron ids. Merged (deduplicated) into the day entry; becomes the active-topics list."
    • Changedcrbro_sessions2 fields changed
      • changedInput schema / properties / limit / description
        Previous value: -"Number of sessions to return (default 10)"New value: +"Day logs to return, newest first (default 10)."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "sessions": {
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "date": {
+            "type": "string"
+          },
+          "decisions_made": {
+            "type": "number"
+          },
+          "key_facts_added": {
+            "type": "number"
+          },
+          "session_id": {
+            "type": "string"
+          },
+          "summary": {
+            "type": "string"
+          },
+          "topics_touched": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "total",
+    "sessions"
+  ],
+  "type": "object"
+}
    • Addedcrbro_share
    • Addedcrbro_space
    • Changedcrbro_status1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "brain_format": {
+      "type": "string"
+    },
+    "brain_path": {
+      "type": "string"
+    },
+    "crbro_version": {
+      "type": "string"
+    },
+    "last_boot": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "last_consolidation": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "total_neurons": {
+      "type": "number"
+    },
+    "total_sessions": {
+      "type": "number"
+    },
+    "total_synapses": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "crbro_version",
+    "total_neurons",
+    "total_synapses",
+    "total_sessions"
+  ],
+  "type": "object"
+}
    • Addedcrbro_sync
  6. 15 tool updatesv1.4.0
    • First observedcrbro_boot
    • First observedcrbro_connect
    • First observedcrbro_connections
    • First observedcrbro_consolidate
    • First observedcrbro_context
    • First observedcrbro_global_map
    • First observedcrbro_hot_topics
    • First observedcrbro_learn
    • First observedcrbro_maintenance
    • First observedcrbro_neuron
    • First observedcrbro_neurons
    • First observedcrbro_recall
    • First observedcrbro_session_log
    • First observedcrbro_sessions
    • First observedcrbro_status
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly separated responsibility: boot/inspect/recall for reading at different levels, learn/revise/forget for lifecycle, context/map/connect for different memory structures, and consolidate/maintenance/audit/secret/space/share for session, housekeeping, security, and team concerns. Apparent overlaps like recall vs. inspect or revise vs. forget are explicitly delineated in the descriptions.

Naming Consistency4/5

All tools share the crbro_ prefix and use lowercase snake_case, which makes the set feel uniform. However, the suffix mixes action verbs (learn, recall, forget, connect, consolidate, share) with nouns (context, map, maintenance, secret, space), so it is not a fully consistent verb_noun convention.

Tool Count5/5

At 15 tools, this sits at the upper boundary of the well-scoped range, but each tool addresses a distinct and necessary facet of the memory system: knowledge lifecycle, session handling, context, maps, connections, maintenance, secret storage, audit, and team sharing. There is no apparent redundancy.

Completeness5/5

The set covers the full knowledge lifecycle (create/read/update/delete/retire), session boundaries, working context, system maps, synaptic connections, maintenance, credential handling, auditing, and team sharing. Destructive operations include dry runs, confirm tokens, and restore paths, so there are no obvious dead ends or missing critical operations.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • iai-personal-memory-engine

    CodeAbra
    A
    license
    A
    quality
    A
    maintenance
    A local MCP server that gives AI assistants a long-term memory by capturing sessions verbatim and surfacing relevant context automatically.
    15
    855
    MIT

  • cell-mem

    Aether-liusiqi
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that provides AI agents with persistent, multi-layered memory inspired by the human brain, including consolidation, self-reflection, and generative replay.
    1
    MIT

  • mem-context

    turbyho
    A
    license
    A
    quality
    A
    maintenance
    Multi-modal RAG engine for AI assistants. Stores conversation history, conclusions, diffs, error traces, and other development artifacts in LanceDB with vector search, multi-factor scoring, and an LLM-driven consolidation pipeline.
    10
    MIT

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