crbro-memory

by Octonove

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.4.0
Disambiguation4/5
Most tools have clearly distinct purposes: boot/consolidate handle lifecycle, learn/neuron/neurons/recall cover knowledge CRUD, connect/connections manage relationships, and status/context/hot_topics/global_map provide different views. Minor overlap exists between maintenance and consolidate (both recalculate heat) and between hot_topics and global_map (both provide overviews), but descriptions and usage warnings mitigate confusion.
Naming Consistency4/5
All tools use a consistent `crbro_` prefix and snake_case, but the pattern mixes imperative verbs (boot, learn, recall, connect, consolidate) with resource nouns (status, neuron, neurons, connections, sessions, context). This is readable and predictable, though not as uniform as a strict verb_noun convention.
Tool Count5/5
15 tools is well within the ideal range for a memory system. Each tool serves a distinct function—from core operations (learn, recall, consolidate) to auxiliary utilities (status, hot_topics, global_map)—and none feel redundant or unnecessary.
Completeness4/5
The toolkit covers the full memory lifecycle: initialization (boot), knowledge creation (learn), retrieval (neuron, neurons, recall, connections, sessions, context, hot_topics, global_map), relationship management (connect), maintenance (maintenance), and persistence (consolidate). A notable gap is the lack of an explicit delete or update tool for neurons/connections, though maintenance partially addresses this via pruning and archiving.
Average 3.8/5 across 15 of 15 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List', which implies a read operation, but it does not explicitly state that it is non-destructive or mention any side effects, permissions, or the meaning of 'hippocampus'. This lacks adequate transparency for a tool without annotation support.
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 a single, clear sentence with no redundant words. It is concise and front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter, the description is adequate but lacks details such as ordering of results, output format, or what 'hippocampus' refers to. It is minimally viable but could benefit from additional context.
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 `limit` parameter is fully documented in the schema. The description adds no additional parameter context, but the baseline of 3 is appropriate when the schema already covers all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent session logs with a specific verb and resource, but it does not explicitly differentiate from the sibling tool `crbro_session_log` (singular), which likely provides single-log details. The scope is clear enough for basic selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like `crbro_session_log` or other tools. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It states 'Read or update' but doesn't explain how reading is triggered (e.g., calling with no parameters) or what the update semantics are (e.g., replacement vs merge for set_topics). The schema only shows update params, leaving read behavior ambiguous.
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 one sentence that front-loads the core purpose ('Read or update the active working context') followed by a compact list of tracked items. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only three optional update parameters and no output schema or annotations, the description should clarify how to invoke read vs update and what the return value is. The current description leaves this ambiguous, making it incomplete for an agent to confidently use the tool.
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 parameter descriptions already explain each field. The description adds a high-level mapping by mentioning 'current topics, pending tasks,' which aligns with set_topics, add_pending, and resolve_pending, but it doesn't go beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads or updates the active working context, mentioning the tracked elements (current topics, pending tasks, last session). It doesn't explicitly differentiate from sibling tools like crbro_status or crbro_session_log, but the resource is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for managing the active working context by mentioning what it tracks, but it doesn't provide explicit when-to-use guidance or name alternatives. Sibling tools exist for related but distinct purposes, yet no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description names the actions (prune, archive, rebuild) which imply mutation of internal state, but it does not explicitly warn about destructive consequences or mention that dry_run can preview changes. Without annotations, the description carries the burden, and it partially discloses behavior but omits safety context.
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 a single sentence that is front-loaded with the core action and uses a dash to efficiently enumerate the specific maintenance subtasks. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description effectively covers what the tool does, it lacks information about the expected output (e.g., what does a successful run return?) and does not explain the implications of running without dry_run. Given the tool's potentially destructive nature, this incompleteness is notable.
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?
The schema already fully describes the 'dry_run' parameter with clear semantics ('only report what would happen without acting'). The description itself adds no additional meaning about the parameter, so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly lists specific maintenance actions (recalculate heat, prune weak synapses, archive cold neurons, rebuild search index), which makes the tool's purpose concrete. However, the term 'brain maintenance' is somewhat generic, and with a sibling named 'consolidate', the differentiation isn't explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to run maintenance versus using related tools like 'crbro_consolidate' or 'crbro_status'. There are no context cues, preconditions, or alternative recommendations, leaving the agent to guess the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state that the operation is read-only, nor does it mention the caching behavior implied by the 'rebuild' parameter (i.e., that the result may be cached and rebuilding is a forced refresh). This is a significant gap for a tool that appears to have a side-effectful option.
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 a single, front-loaded sentence with zero wasted words. It efficiently communicates the tool's purpose and scope without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional boolean, no output schema, no annotations), and the purpose is clear. However, the description omits any mention of the return format or the caching/rebuild behavior, which are useful contextual details given the absence of an output schema and annotations. It is adequate but not fully complete.
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?
The schema fully describes the only parameter ('rebuild' with its explanation), so schema coverage is 100%. The tool description adds nothing about the parameter, but the baseline of 3 applies because the schema already does the heavy lifting.
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 ('View') and identifies a distinct resource ('global neural map'), with meaningful detail about its content ('clusters of related topics and bridges between domains'). This clearly distinguishes it from sibling tools like crbro_neurons (individual neurons) or crbro_connections (individual connections), which likely focus on lower-level data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for getting a high-level overview, but it provides no explicit guidance on when to choose this over alternatives, nor any exclusions (e.g., 'for detailed neuron listings, use crbro_neurons'). It also doesn't mention when to use the 'rebuild' option versus relying on cache, which would be relevant usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses the non-destructive strengthening mechanism (repeated co-access) and indicates that the tool either creates or updates a synapse. However, it omits critical details such as whether neurons must pre-exist, what the return value is, or error handling, leaving significant behavioral gaps.
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 two concise sentences, front-loaded with the core action and resource, and every word adds value. It is neither verbose nor under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with four parameters and no annotations or output schema. The description provides a solid overview of purpose and the strengthening behavior, but it does not cover return values, prerequisites, or failure scenarios. It is functional but not fully comprehensive.
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?
The input schema already provides 100% coverage with descriptions for all four parameters. The description adds no extra parameter-level detail beyond identifying the two neuron IDs and the synaptic concept, so the baseline of 3 is appropriate.
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 action (create or strengthen) and the resource (a connection/synapse between two neurons), with enough specificity to distinguish it from sibling tools like crbro_connections which likely list connections. The verb and resource are concrete and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when a relationship between two neurons needs to be established or reinforced—but it does not explicitly name alternatives or provide exclusions. The mention of strengthening with repeated co-access offers contextual guidance, but there is no direct comparison to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that the search is hybrid and results are ranked by relevance, but it does not mention read-only behavior, no-match behavior, or any prerequisites (e.g., whether boot is required). The statement adds some context but leaves important behavioral details unaddressed.
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 two short sentences that are front-loaded with the action ('Search the brain'). Every word earns its place: it states purpose, method, and result type without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 3 parameters, no output schema, and no annotations, so complexity is low. The description explains the purpose and result, but it does not explain what a 'neuron' result looks like or how limit/domain affect results beyond schema. It is adequate but could be more complete by clarifying the return format or search behavior.
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% for all three parameters (query, limit, domain), so the baseline is 3. The description adds general context about search and ranking but does not add specific parameter semantics beyond what the schema already provides (e.g., limit default, domain filter).
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 ('Search'), identifies the resource ('the brain'), and describes the mechanism ('hybrid text search') and output ('matching neurons ranked by relevance'). This clearly distinguishes it from sibling write tools like crbro_learn or listing tools like crbro_neurons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving relevant knowledge when a query is provided, but it does not explicitly state when to use it over alternatives like crbro_hot_topics or crbro_global_map. No exclusions or alternative tool references are given, so usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It reveals that the tool returns connections with strength and type, which is useful. However, it does not explicitly state that this is a read-only operation, nor does it mention side effects, permissions, or limitations beyond what the verb 'Get' implies.
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 two concise sentences, front-loaded with the core purpose. Every word earns its place, with no unnecessary detail or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read tool, the description covers the essential purpose and output type. It lacks explicit sibling differentiation and return format details, but given the simplicity, it is largely complete. No output schema exists, so the description adequately fills the gap by describing the returned connection data.
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% with descriptions for both neuron_id and min_strength. The description adds marginal reinforcement by referencing 'connection strength and type', which aligns with min_strength, but does not provide additional parameter semantics 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 description uses a specific verb 'Get' with resource 'connections (synapses) for a specific neuron', making the purpose immediately clear. It distinguishes itself from siblings like crbro_connect (likely create) and crbro_neurons (list neurons) by focusing on retrieving connections for a specific neuron.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need related topics for a neuron, but it does not explicitly state when to use this tool versus alternatives like crbro_neurons or crbro_connect. No when-not scenarios or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral transparency. It indicates this is a read operation and lists returned elements (facts, decisions, patterns, connections, heat score). However, it does not explicitly confirm non-mutating behavior, error cases, or authorization requirements, though the low risk of a read operation makes this a minor gap.
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?
A single, front-loaded sentence that states the action, target, and return content with no fluff or repetition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description adequately explains what the tool returns (all facts, decisions, patterns, connections, heat score). The lack of an output schema is compensated by listing the return fields. Minor missing context is the precise format or meaning of 'heat score', but this is not critical.
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?
The schema already provides 100% coverage with a clear description and examples for the 'id' parameter. The tool description echoes 'ID or name' but does not add meaning beyond the schema, so the baseline 3 is appropriate.
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 action ('Read'), the target resource ('a specific neuron'), and the method of identification ('by ID or name'). This distinguishes it from sibling tools like crbro_neurons (presumably listing all neurons) and crbro_recall (recall).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'a specific neuron' implies use when you need details of one entity by ID/name, but it does not explicitly mention alternatives or when not to use it. Sibling tools are not referenced, so guidance is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While "Get" suggests a read-only operation, the description does not explicitly confirm that it is non-destructive, require no special permissions, or describe any side effects. This lack of safety/behavioral context is a significant gap for a tool with no annotation support.
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 a single, tightly constructed sentence with no redundant words. It front-loads the action and lists the key data elements efficiently, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description provides enough context by listing what the status includes. It does not cover error cases or expected output format, but for a straightforward status query, it is reasonably complete.
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 parameters, and the description correctly reflects that by not mentioning any arguments. Per the baseline for 0 parameters, the description does not need to compensate for missing parameter documentation, and it adds no misleading parameter information.
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 the specific verb "Get" and clearly identifies the resource as the current status of the CRBRO brain. It enumerates the exact contents (total neurons, synapses, sessions, and brain path), which distinguishes it from sibling tools like crbro_learn or crbro_recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for retrieving overall status, but it does not explicitly state when to use it over alternatives or provide any exclusions. For example, it doesn't say 'use this for a quick overview' or 'for detailed neuron info, use crbro_neuron'. Usage is inferred from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the side effects: persists all new knowledge, logs the session summary, recalculates topic heat scores, and updates the manifest. It also discloses the severe consequence of not calling it: 'this entire session's knowledge is permanently lost.' This is strong behavioral transparency, though it doesn't mention return values or reversible/irreversible nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is more verbose than necessary. It repeats the same urgency multiple times ('CALL BEFORE SESSION ENDS', 'before the conversation ends', 'Failing to consolidate means...') and uses a warning emoji plus ALL CAPS. While the information is valuable, it could be tightened to two or three sentences without losing impact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, no output schema, no annotations), the description covers the essential context: when to call it, what it accomplishes, why it is mandatory, and what to provide. It is sufficient for an agent to invoke the tool correctly in the intended scenario, though it doesn't discuss edge cases like repeated calls or partial failures.
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?
The input schema already documents the single parameter 'summary' as 'Summary of the session being consolidated' (100% schema coverage). The description adds minor guidance by saying 'Always provide a meaningful summary of what was accomplished,' which reinforces content quality but does not significantly expand beyond the schema. Baseline 3 is appropriate.
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 purpose: 'Consolidate the brain at end of session.' It identifies the specific action (consolidate), the resource (the brain), and the timing (end of session). It also enumerates what consolidation does (persists knowledge, logs session summary, recalcs heat scores, updates manifest), distinguishing it from sibling tools that handle individual pieces (e.g., crbro_learn, crbro_session_log).
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?
The description gives explicit when-to-use guidance: 'CALL BEFORE SESSION ENDS' and 'if ANY significant work was done (code changes, decisions made, new information learned).' It also instructs the agent to always provide a meaningful summary. However, it does not explicitly state when not to use it or name alternative tools for different scenarios, so it stops short of full 5-level guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the heat-score basis, which adds useful behavioral context. However, it does not explicitly state read-only behavior, output format, or any prerequisites (e.g., whether the system must be booted). This is an average level of transparency for a simple query tool.
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 a single, concise sentence that is front-loaded with the action and resource. Every word earns its place, with no unnecessary detail or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no output schema, no nested objects), the description is largely complete. It explains the core purpose and scoring logic. It could be improved by mentioning that the result is a list of neurons and noting any preconditions, but it is adequate for straightforward use.
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?
The schema covers 100% of the parameter (limit) with a clear description and default value. The tool description adds no additional meaning beyond this, so the baseline of 3 is appropriate.
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 a specific action ('Get the hottest topics') and resource (neurons with highest heat scores), and explains the scoring criteria (frequency, recency, connectivity). This differentiates it from siblings like crbro_neurons (likely all neurons) and crbro_neuron (single neuron).
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?
The context is clear: use this tool when you need trending or popular topics. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5. The phrase 'hottest topics' provides sufficient context for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool lists neurons and returns specific fields (ID, name, domain, heat, facts count), indicating a read-only operation. It does not mention pagination or performance, but the behavior is sufficiently transparent for a list tool.
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 a single, front-loaded sentence that immediately states the action and resource, then lists return fields. Every part is functional and there is no unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple list tool, given the schema covers parameters and there is no output schema. It mentions return fields, which is helpful. However, it omits details like sorting or how filters combine, but these are not critical for basic usage.
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?
The input schema already provides detailed descriptions for all four parameters (100% coverage), so the description does not need to repeat them. It adds minimal value by mentioning 'optional filters' but does not clarify semantics beyond the schema, so a baseline score of 3 is appropriate.
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 ('List') and resource ('all neurons in the brain'), clearly distinguishing it from sibling tools like crbro_neuron (singular) and crbro_connections. It also specifies optional filters and return fields, making the tool's scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing neurons with filters but does not explicitly state when to use this over alternatives, such as crbro_neuron for a single neuron. There is no exclusion guidance, but the context is reasonably clear from the verb and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full behavioral transparency burden. It clearly indicates a write operation ('Log') and its purpose ('record what was done'), which is sufficient for a simple logging tool. However, it does not disclose whether entries are append-only, overwrite existing logs, require prior session initialization, or what response is returned. These details, while not critical for a log tool, are absent.
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 two short sentences, front-loaded with the action and purpose. The second sentence adds a critical timing instruction. There is no redundancy or wasted words, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple logging tool with full schema coverage and no output schema, the description is nearly complete. It specifies when to call it (end of session) and what it does. It does not elaborate on session context or relationships to sibling tools, but these are not required, and the description is adequate for an AI agent to select and invoke 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 description coverage is 100%, with each parameter already having a helpful description (e.g., summary, topics_touched, decisions_made, key_facts_added). The tool description adds no additional parameter details beyond referring to a 'session summary.' Since the schema handles parameter semantics, the baseline score of 3 applies.
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 purpose: 'Log a session summary to the hippocampus.' It specifies the exact action (log) and resource (session summary to hippocampus), and it distinguishes from siblings like crbro_sessions (which likely lists sessions) by adding 'Call at the end of a work session to record what was done.'
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?
The description provides explicit guidance on when to use the tool: 'Call at the end of a work session to record what was done.' It does not explicitly mention when not to use it or alternatives, but the timing instruction is clear and actionable. Given sibling tools include crbro_sessions (reading) and crbro_learn (learning), the context is adequately established.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It discloses a key side effect: 'If the neuron (topic) does not exist, it will be created automatically.' This is valuable context beyond the parameter schema. It also mentions persistence across sessions. It does not disclose details like overwrite behavior or auth requirements, but for this simple storage operation, it is reasonably transparent.
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 two sentences, front-loaded with the primary action, then adds one key behavioral detail and a usage statement. Every sentence contributes to understanding without redundancy. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, 3 required, no output schema) and the lack of annotations, the description covers the essential context: what it does, when to use it, and a critical auto-creation behavior. It does not explain the return value, but no output schema makes that less critical. A minor gap is the behavior when a neuron already exists (update vs. append), which could be specified but is not a major omission.
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?
The input schema already has 100% description coverage for all six parameters, so the baseline is 3. The description adds some semantic value by linking 'topic' to the concept of a neuron and enumerating the 'type' values in the first sentence. However, it does not add significant extra meaning for fields like domain, rationale, or confidence beyond what the schema already 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 clearly states the tool's function with a specific verb ('Teach') and resource ('the brain'), and enumerates the types of knowledge it stores (fact, decision, pattern, preference). It also distinguishes itself from retrieval siblings by emphasizing persistence and storage. The phrase 'store knowledge that should persist across sessions' reinforces the purpose.
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?
The description provides a clear usage directive: 'Use this to store knowledge that should persist across sessions.' This tells when to use the tool, implying that if persistence is needed, this is the tool. However, it does not explicitly mention alternatives like crbro_recall for retrieval or crbro_connect for relationships, so it lacks the explicit exclusion present in top-quality descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full behavioral disclosure. It states what happens on first use (initializes), what happens on subsequent uses (loads memory), and the consequence of skipping (context loss). This goes beyond a simple 'boot' verb and gives the agent a clear mental model of the tool's 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 front-loaded with the mandatory warning, then explains the tool's function, then explains the first-use vs subsequent-use behavior, and ends with a consequence. Every sentence contributes unique value 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 the tool has no parameters and no output schema, all necessary information is covered: what it does, when to call it, what to expect on first vs later calls, and why it matters. The description fully prepares an agent to invoke this tool 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. The description appropriately does not dwell on parameters, and the absence of parameters means the baseline of 4 is appropriate.
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 identifies the tool as a mandatory boot action that loads persistent memory from previous sessions, distinguishing it from sibling tools like crbro_status or crbro_recall which serve different purposes. The verb 'boot' plus the explicit consequence of skipping ('losing all accumulated context') makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this as the very first action in every new conversation and before any other work, providing strong when-to-use guidance. It also clarifies that on first use it initializes the brain structure, and on subsequent uses it loads hot topics and context, giving a complete usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![crbro-memory MCP server](https://glama.ai/mcp/servers/Octonove/crbro-memory/badges/card.svg)](https://glama.ai/mcp/servers/Octonove/crbro-memory)

Score Badge

Copy to your README.md:

[![crbro-memory MCP server](https://glama.ai/mcp/servers/Octonove/crbro-memory/badges/score.svg)](https://glama.ai/mcp/servers/Octonove/crbro-memory)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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