Skip to main content
Glama

Working context

crbro_context
DestructiveIdempotent

Read and update working context by tracking active topics, open items, and recently closed tasks. Resolve or discard pending items to prevent old tasks from resurfacing in later sessions.

Instructions

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

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

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

TDQS

A4.9/5.0
Behavior5/5

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

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

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

Conciseness5/5

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

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

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

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

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

Parameters4/5

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

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

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource pair: 'Read or write the working context', and enumerates the concrete contents (active topics, open items, recently closed, last session). It also distinguishes itself from crbro_consolidate by explicitly stating that session logging belongs there, not here.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

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

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Octonove/crbro-memory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server