Skip to main content
Glama
Turbo Quant Memory MCP Server

Turbo Quant Memory MCP Server

remember_note

Store typed project notes with kind, tags, source references, and provenance to persist decisions, lessons, patterns, and handoffs for later semantic search and knowledge-graph linking.

Instructions

Store a typed project note. kind must be exactly one of: lesson, decision, pattern, handoff.

tags: 2-3 lowercase tags are strongly recommended — tags are the only way to FILTER notes; an untagged note is reachable by semantic_search alone. source_refs: the files / notes / issues this note is about. Pass them as entity URIs (note://, file://<relative/path>, issue://KEY, https://...) and they are auto-linked into the knowledge graph as references relations, so get_related_entities can later surface them. provenance: who originated the note. Use "human-explicit" when the USER asked to remember something ("remember this", "save that"); "agent" for your own observations (the default); "external-tool" for API/tool data; "system" for automatic processes. tier: normally derived from kind (handoff -> episodic, every other kind -> durable). Override e.g. tier="durable" to keep a handoff in the default-searchable set, or tier="episodic" to keep a noisy lesson out of regular search.

After storing, connect the note with link_entities(source_uri="note://", ...) when it relates to a file, issue, or prior note — the response echoes the note's uri and hints this when the note still has no relations.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title": "<title>",
      "content": "<content>",
      "kind": "<kind>"
    },
    "name": "remember_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYes
tagsNo
tierNo
scopeNoproject
titleYes
contentYes
provenanceNoagent
source_refsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.36.1

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does unusually well: it discloses the side effect that source_refs are auto-linked into the knowledge graph as `references` relations, that tier defaults are derived from kind, and that the response echoes the note uri with a hint. It does not cover failure modes (invalid kind, duplicate/near-duplicate notes) or whether the call is idempotent, which are the remaining behavioral gaps for a write tool.

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?

Front-loaded with the core action and the hard constraint on kind, then organized as per-parameter blocks that are easy to scan. Every line carries actionable content, though the provenance and tier glossaries are dense enough that the block runs slightly long relative to the single-sentence core.

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 an 8-parameter write tool with no annotations, the description supplies most of what an agent needs: value vocabularies, side effects, follow-up wiring, and default derivation logic. The output schema exists, so return-value explanation is not required, and the one real gap is the undocumented `scope` parameter and its interaction with the multi-scope siblings.

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 0%, so the description must compensate, and it largely does: kind's enum is spelled out in exact strings, tags gets a count and lowercase convention, source_refs gets four URI format templates plus downstream effect, provenance and tier get value glossaries with defaults implied. It leaves `scope` (default "project") and `title`/`content` undefined, and scope is the meaningful omission given list_scopes is a sibling.

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?

Opens with a specific verb and resource ("Store a typed project note") and immediately constrains the type domain to four exact values. It distinguishes itself from retrieval siblings by naming semantic_search and link_entities, so an agent knows this is the write/ingest side of the note lifecycle.

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 rules for nearly every optional parameter: provenance is mapped to concrete situations (user said "remember this" vs agent observation vs tool data), and tier overrides are explained with the two concrete cases worth overriding. It also names the follow-up action (link_entities) and the condition that triggers it, plus the consequence of omitting tags (only reachable via semantic_search).

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