Skip to main content
Glama

kb_write

Record or correct codebase notes after real work: file notes, flow notes, and confirmed absence lessons, with duplicate detection and batch writing. Fix or retract notes that proved wrong.

Instructions

Save or correct NOTEBOOK notes after finishing real work here — you have the files in context, so no future agent is better placed to record what you learned. Write a file note (what a file is for), a flow note (how a task spans files), or an absence lesson (a confirmed "there is no X"). Pass specs (an ARRAY of specs) to write ALL your notes in ONE call — malformed notes are reported together instead of one hiding the rest, and the result ends with a coverage line naming any worked files still without a note; pass spec (a single object) for a one-off. Also the tool to FIX or RETRACT a note you used that proved wrong: op: "put" replaces; op: "retract" with target: {kind: "note"} removes the whole note (or target: {kind: "anchor"|"alias"|"facet"|"invariant"|"behavior"|"feature", key: "<value>"} removes one part).

TWO-PHASE reuse gate: a flow/lesson spec sent WITHOUT an id first searches the notebook for the same concept. If plausible matches exist, kb_write returns {status:"candidates", candidates:[...]} INSTEAD of writing — re-call with into: "<id>" to merge into an existing note, or is_new: true to declare a genuinely new one. This makes note identity reliable (matching, not guessing an exact title). File notes skip the gate (id derives from the path).

The spec shape: type ("file"|"flow"|"lesson", or sugar "file-hub"/"file-single"), title, summary, anchors ([{path, symbols?}] — the addresses the note is about, which drive freshness), plus type-specific fields (file: facets/character; flow: steps/verified; lesson: kind:"absence"/scope/body). Call with NO arguments to get the full spec guide.

REQUIRED for the note to be findable at all — file-single: identityAliases + anchors[].symbols; file-hub: identityAliases + facets[].symbol; flow: identityAliases + steps + verified; lesson: scope.terms. A note missing these is written but unreachable: identityAliases are the only STABLE search surface besides the exact title (incidentAliases are optional — symptom words for a write that describes one, replaced by the next such write, never required), and anchor symbols are the only channel that answers a query typed as an identifier.

This tool WRITES to the repo notebook; it never commits to git — publishing notes is a human-only step (coldstart kb commit).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
intoNoPhase-2 answer: merge this write into the existing note with this id (from a prior `candidates` response).
specNoA single note spec (JSON object). Fields: type, title, summary, identityAliases (stable — unions forever), incidentAliases (this write's symptom words — replaced by the next write that changes summary/body, omit if this write isn't about an incident), anchors:[{path,symbols?}], and type-specific fields (facets/character for file; steps/verified for flow; kind/scope/body for lesson). REQUIRED for the note to be findable at all — file-single: identityAliases + anchors[].symbols; file-hub: identityAliases + facets[].symbol; flow: identityAliases + steps + verified; lesson: scope.terms. A note missing these is written but unreachable: identityAliases are the only STABLE search surface besides the exact title (incidentAliases are optional — symptom words for a write that describes one, replaced by the next such write, never required), and anchor symbols are the only channel that answers a query typed as an identifier. Omit `id` on a new flow/lesson to trigger the reuse gate. Use `specs` instead to write several notes at once.
agentNoOptional agent id (given in a capture prompt, alongside session). Selects THIS agent stream's durable worklist for the coverage line so a subagent does not clear the main agent's list. Defaults to "main".
specsNoThe capture path: an ARRAY of note specs (each the same shape as `spec`), written in ONE call. Order flows before the file notes that reference them. Well-formed notes are written; malformed ones are reported together (not atomic — a bad note never silences a good one); the result ends with a coverage line naming any worked file still without a note. Prefer this over many single-`spec` calls.
is_newNoPhase-2 answer: declare this a genuinely new concept, bypassing the candidate matches from a prior `candidates` response.
sessionNoOptional session id (given in a capture prompt). Enables the flow-evidence check: a flow whose step files this session never actually read gets a warning.
Behavior5/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. It thoroughly discloses key behaviors: the two-phase reuse gate returning `{status:"candidates"}` instead of writing, non-atomic multi-spec writes (malformed notes reported together but good ones written), a coverage line at the end, flow-evidence checks with session, and the git/publishing boundary. It also explains the consequences of missing required fields ('written but unreachable') and the stability/replacement semantics of identityAliases vs incidentAliases.

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 well-structured with clear paragraphs for purpose, reuse gate, spec shape, required fields, and git behavior. It is front-loaded with the core purpose. However, there is redundancy: the 'REQUIRED for the note to be findable' paragraph is nearly duplicated in the spec parameter description, and incidentAliases semantics appear twice. This prevents a perfect score while still being appropriately detailed for the tool's complexity.

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 must explain return behavior and does so thoroughly: candidate responses, coverage lines, malformed note handling, and the flow-evidence warning. It covers the two distinct call modes (`spec` vs `specs`), the reuse gate interaction, required fields for findability, and non-commit behavior. This is comprehensive for a tool with six parameters and nested object inputs.

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?

Though schema coverage is 100%, the description adds substantial semantic context beyond the schema. It explains the relationship between `spec`/`specs`, the phase-2 meanings of `into` and `is_new` (merging vs declaring new), the purpose of `session` for flow-evidence checks, and `agent` for the coverage line. It also details the `spec` shape and required fields per type, enriching the bare schema definitions significantly.

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 'Save or correct NOTEBOOK notes after finishing real work here', using a specific verb (save/correct) and resource (NOTEBOOK notes), and clearly distinguishes this write tool from read/search/repair siblings like kb_search, kb_lookup, and kb_repair. It also explicitly states it handles fixes and retractions in addition to initial writes.

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: 'after finishing real work here — you have the files in context, so no future agent is better placed to record what you learned.' It also explains when to use `specs` vs `spec`, describes the two-phase reuse gate process, and clearly states what the tool does NOT do ('never commits to git — publishing notes is a human-only step'), providing sufficient context and exclusions.

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

Install Server

Other Tools

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/AkashGoenka/coldstart'

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