Skip to main content
Glama

vectr_remember

Save key code findings, file paths, gotchas, and task progress, then recall them in under 50ms—even after context compaction or in a new session. Avoid re-reading files and losing context.

Instructions

Save a working note and recall it on demand in <50ms — whether later this session, through context compaction, or in a future session. Use the moment you discover something non-obvious: a key file path, a call pattern, a gotcha, a partial stub, task progress. Store the actual code or finding — vectr returns it in <50ms; re-reading the file costs tokens and turns. Do NOT store obvious or easily re-derivable facts (e.g. 'the main file is main.py'). For a body over ~2KB, especially code-heavy with quotes/escapes, write it to a file and pass content_file instead of content — long escape-dense strings can be corrupted mid-stream as a tool-call argument. Retrieve with vectr_recall(query='what you need') — any time, same session or later.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pinNoOptional: pin this note into Tier 0 at write time — injected on EVERY future vectr_recall(query=...) call regardless of the query, same effect as a separate vectr_pin call right after this write. Bounded, so pin sparingly. Default false.
kindNoMemory kind, controlling how the note is injected (default 'finding'): 'directive' = a must-never-miss rule, injected unconditionally every session; 'task' = current-work context (save checkpoints with priority="high" — session-start/resume surfaces show only high-priority task notes); 'gotcha' = a file/path-anchored caveat; 'finding' = a relevance-ranked learning; 'reference' = a pointer (URL/ticket); 'decision' = an architectural/design decision plus its why — not auto-injected, recall the group chronologically with vectr_recall(kind="decision", sort_by="chronological") for an ADR-style decision history; 'operational' = a build/env/process fact (a build quirk, a CI gotcha, feedback-loop knowledge — e.g. 'tests must run via ./.venv/bin/python'), not anchored to a single code file the way 'gotcha' is. By default surfaces via prompt-time semantic recall (equivalent to declaring triggers=[{'event': 'prompt-submit', 'semantic': True}]). An explicit triggers=[...] REPLACES that default rather than adding to it — declaring triggers=[{'command': '<verb-glob>'}] alone means the note fires ONLY right before a matching shell command and stops firing on prompt-submit. To keep both surfaces, declare both entries: triggers=[{'event': 'prompt-submit', 'semantic': True}, {'command': '<verb-glob>'}]. When a new kind='task' note replaces an earlier checkpoint (the work moved on, the old note is no longer the current state), pass supersedes=<old note_id> so the stale checkpoint stops firing at every future session-start instead of piling up alongside the new one.finding
tagsNoTopic tags for later recall (e.g. ['segment-targeting', 'wip'])
agentNoOptional: your identifier when called by a subagent or orchestrator in a multi-agent workflow (e.g. 'coder-2'). Never inferred — set it explicitly if you want attribution. Shown in vectr_recall() index output as a tag, e.g. '[#12] task/high (coder-2) · title'. A subagent should call vectr_remember with its findings BEFORE finishing so the orchestrator can recall them instead of re-reading the subagent's full transcript.
scopeNoAdvanced: visibility scope, enforced at recall/trigger time. Omit for the kind's own default ('task'→'branch', 'gotcha'→'repo', else 'workspace'); pass explicitly to override — 'branch' (git branch at write time), 'path-subtree' (paths under an anchored dir), 'session' (writing session only), 'repo' (same as 'workspace' today).
titleNoShort label for index-tier display (optional, max ~80 chars). If omitted, the first non-empty line of content is used as the title. Shown in vectr_recall() index output so you can identify notes without reading their bodies.
anchorsNoOptional: file paths this note is about, content-hashed at write time so a later change surfaces as a staleness caveat instead of silently going stale.
contentNoThe note to store. Store whatever you would need to avoid re-reading the file later. If you found a function you'll call or modify — paste its signature and body. If you found a pattern you'll need to replicate — paste the pattern. If you found a location — include the file:line AND the relevant excerpt, not just the pointer. Prose descriptions send the next conversation back to the file; actual code does not. Mutually exclusive with content_file (see below); pass exactly one.
priorityNoNote priority: 'high' | 'medium' (default) | 'low'. Session-start boot injection and the resume surface show only priority='high' kind='task' notes, so a checkpoint you want picked up at resume needs priority='high'.medium
triggersNoAdvanced: explicit overrides for WHEN this note resurfaces (path glob, event, symbol, semantic-similarity, timing/cooldown fields — AND within an entry, OR across entries; see docs for the full field DSL). Omit this entirely (recommended) — each kind already gets a sensible default, e.g. 'directive' fires at session-start and after compaction, 'gotcha' fires when its anchored file is about to be edited.
provenanceNoHow much to trust this note when it resurfaces (default 'agent'): 'agent' = self-recorded, framed as memory to verify; 'auto' = no reviewing judgment, weakest framing, incompatible with kind='directive'. 'human' is only reached via explicit promotion, not settable here.agent
supersedesNoOptional: the note_id this new note replaces — the old note is retired (excluded from recall/firing) but kept for audit, unlike vectr_forget. Especially important for kind='task': pass the prior checkpoint's id so it stops firing at every session-start once superseded.
user_quoteNoOptional: when this note transcribes something the USER said, the user's own words, verbatim. Bound only if that exact text also appears inside `content` (whitespace-insensitive substring check); a bound quote stores the note as provenance='user-stated' so it resurfaces as the user's statement rather than your own recollection. Paraphrase, or words the user did not actually write, will not bind — the note is stored as an ordinary 'agent' note and the reason is returned. Never fails the write.
contradictsNoOptional: the note_id this new note proves WRONG — distinct from supersedes (a normal replacement). The target note is revoked: it stays visible on every future recall/fire but rendered as a deterrent ('previously believed... do not re-derive without verification') instead of its raw content, until vectr_reinstate reverses it.
content_fileNoPath to a UTF-8 file containing the note body — use instead of content for a body over ~2KB, especially code-heavy with quotes/escapes, so it never has to stream as a long JSON string argument. Absolute, or relative to the workspace root; rejected if it resolves outside the workspace. Mutually exclusive with content; pass exactly one.
distilled_fromNoOptional: arc ids (from vectr_distill() or GET /v1/arcs) this note distills. After this note is stored, each named arc is marked distilled into it. Unknown/already-resolved ids, and any entry that is not itself an integer, are reported back in the confirmation, never an error and never silently dropped.

Schema Changelog

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

  1. Changed2 schema fields changedv1.10.1
    • changedInput schema / properties / kind / description
      Previous value: -"Memory kind, controlling how the note is injected (default 'finding'): 'directive' = a must-never-miss rule, injected unconditionally every session; 'task' = current-work context; 'gotcha' = a file/path-anchored caveat; 'finding' = a relevance-ranked learning; 'reference' = a pointer (URL/ticket); 'decision' = an architectural/design decision plus its why — not auto-injected, recall the group chronologically with vectr_recall(kind=\"decision\", sort_by=\"chronological\") for an ADR-style decision history; 'operational' = a build/env/process fact (a build quirk, a CI gotcha, feedback-loop knowledge — e.g. 'tests must run via ./.venv/bin/python'), not anchored to a single code file the way 'gotcha' is. By default surfaces via prompt-time semantic recall (equivalent to declaring triggers=[{'event': 'prompt-submit', 'semantic': True}]). An explicit triggers=[...] REPLACES that default rather than adding to it — declaring triggers=[{'command': '<verb-glob>'}] alone means the note fires ONLY right before a matching shell command and stops firing on prompt-submit. To keep both surfaces, declare both entries: triggers=[{'event': 'prompt-submit', 'semantic': True}, {'command': '<verb-glob>'}]. When a new kind='task' note replaces an earlier checkpoint (the work moved on, the old note is no longer the current state), pass supersedes=<old note_id> so the stale checkpoint stops firing at every future session-start instead of piling up alongside the new one."New value: +"Memory kind, controlling how the note is injected (default 'finding'): 'directive' = a must-never-miss rule, injected unconditionally every session; 'task' = current-work context (save checkpoints with priority=\"high\" — session-start/resume surfaces show only high-priority task notes); 'gotcha' = a file/path-anchored caveat; 'finding' = a relevance-ranked learning; 'reference' = a pointer (URL/ticket); 'decision' = an architectural/design decision plus its why — not auto-injected, recall the group chronologically with vectr_recall(kind=\"decision\", sort_by=\"chronological\") for an ADR-style decision history; 'operational' = a build/env/process fact (a build quirk, a CI gotcha, feedback-loop knowledge — e.g. 'tests must run via ./.venv/bin/python'), not anchored to a single code file the way 'gotcha' is. By default surfaces via prompt-time semantic recall (equivalent to declaring triggers=[{'event': 'prompt-submit', 'semantic': True}]). An explicit triggers=[...] REPLACES that default rather than adding to it — declaring triggers=[{'command': '<verb-glob>'}] alone means the note fires ONLY right before a matching shell command and stops firing on prompt-submit. To keep both surfaces, declare both entries: triggers=[{'event': 'prompt-submit', 'semantic': True}, {'command': '<verb-glob>'}]. When a new kind='task' note replaces an earlier checkpoint (the work moved on, the old note is no longer the current state), pass supersedes=<old note_id> so the stale checkpoint stops firing at every future session-start instead of piling up alongside the new one."
    • changedInput schema / properties / priority / description
      Previous value: -"Note priority: 'high' | 'medium' (default) | 'low'"New value: +"Note priority: 'high' | 'medium' (default) | 'low'. Session-start boot injection and the resume surface show only priority='high' kind='task' notes, so a checkpoint you want picked up at resume needs priority='high'."
  2. Changed5 schema fields changedv1.10.0
    • changedInput schema / properties / content / description
      Previous value: -"The note to store. Store whatever you would need to avoid re-reading the file later. If you found a function you'll call or modify — paste its signature and body. If you found a pattern you'll need to replicate — paste the pattern. If you found a location — include the file:line AND the relevant excerpt, not just the pointer. Prose descriptions send the next conversation back to the file; actual code does not."New value: +"The note to store. Store whatever you would need to avoid re-reading the file later. If you found a function you'll call or modify — paste its signature and body. If you found a pattern you'll need to replicate — paste the pattern. If you found a location — include the file:line AND the relevant excerpt, not just the pointer. Prose descriptions send the next conversation back to the file; actual code does not. Mutually exclusive with content_file (see below); pass exactly one."
    • addedInput schema / properties / content_file
      Added value: +{
      +  "description": "Path to a UTF-8 file containing the note body — use instead of content for a body over ~2KB, especially code-heavy with quotes/escapes, so it never has to stream as a long JSON string argument. Absolute, or relative to the workspace root; rejected if it resolves outside the workspace. Mutually exclusive with content; pass exactly one.",
      +  "type": "string"
      +}
    • addedInput schema / properties / pin
      Added value: +{
      +  "default": false,
      +  "description": "Optional: pin this note into Tier 0 at write time — injected on EVERY future vectr_recall(query=...) call regardless of the query, same effect as a separate vectr_pin call right after this write. Bounded, so pin sparingly. Default false.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / user_quote
      Added value: +{
      +  "description": "Optional: when this note transcribes something the USER said, the user's own words, verbatim. Bound only if that exact text also appears inside `content` (whitespace-insensitive substring check); a bound quote stores the note as provenance='user-stated' so it resurfaces as the user's statement rather than your own recollection. Paraphrase, or words the user did not actually write, will not bind — the note is stored as an ordinary 'agent' note and the reason is returned. Never fails the write.",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "content"
      -]New value: +[]
  3. Addedv1.7.0
  4. Removedv1.3.0
  5. First observedv1.2.0

TDQS

A4.5/5.0
Behavior5/5

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

Adds meaningful behavioral context beyond annotations: persistence across context compaction and future sessions, <50ms retrieval performance, the token/turn cost of re-reading files, and a concrete corruption risk for long escape-dense strings passed as tool-call arguments. The content_file guidance further exposes an important operational behavior. No contradiction with readOnlyHint=false or destructiveHint=false.

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?

Dense and front-loaded, with the core purpose in the first sentence and concrete usage guidance immediately after. It is long, and the '<50ms' point is repeated somewhat redundantly, but most sentences earn their place by giving actionable guidance or rationale.

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 write tool with no output schema and 16 parameters, the description covers the common path well: what to store, what not to store, how to handle large code-heavy bodies, and how to retrieve later. Advanced fields are delegated to the schema's rich parameter descriptions, which is acceptable; the only notable omission is describing what the tool returns (e.g. the new note_id), which would help with supersedes/contradicts chaining.

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 genuine parameter-level guidance for content vs content_file, including the ~2KB threshold and mutual exclusivity, and connects content quality to future recall value. It does not systematically cover all 16 parameters, but the schema already documents those thoroughly and the description adds value where it matters most.

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 specific action ('Save a working note and recall it on demand'), names the resource (vectr memory), and explicitly names the retrieval counterpart vectr_recall. It is clearly distinguishable from the read-side sibling and is not tautological or vague.

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?

Gives concrete when-to-use triggers: 'Use the moment you discover something non-obvious' with examples (file path, call pattern, gotcha, stub, progress), and explicitly says what NOT to store ('Do NOT store obvious or easily re-derivable facts'). It does not enumerate exclusions against related write tools such as vectr_pin or vectr_forget, but the timing and anti-pattern advice is strong enough to guide tool selection.

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/swapnanil/vectr'

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