Server Quality Checklist

Tool Scores

• crbro_consolidateA
  4.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_spaceA
  4.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.

• crbro_inspectA
  4.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_mapA
  4.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_bootA
  4.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_secretA
  4.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_shareA
  4.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_auditA
  4.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_connectA
  4.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_contextA
  4.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_forgetA
  4.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_learnA
  4.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_maintenanceA
  4.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_recallA
  4.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_reviseA
  5/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.