Skip to main content
Glama
contextq

@contextq/mcp

Official
by contextq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ctx_remember

Extract and save durable memories from multi-turn conversations as deduped atomic contexts, scoped by subject or workspace. Preview with dryRun; poll async jobs for long chats.

Instructions

Extract durable memories from a raw multi-turn conversation and save them as deduped atomic contexts. Turn-aware sibling of ctx_ingest: the server builds a speaker-attributed transcript, extracts only durable facts/preferences via LLM (skipping chit-chat), and runs the claims through the SAME kNN-dedup + diff + create/update/archive pipeline ctx_ingest uses. Pass subjectId to scope memories to a single end-user of your application (Mem0-parity user_id) — dedup then only considers that subject's own prior memories, and every created context is tagged with that subjectId so ctx_search (subjectId param) and GET /api/memory can retrieve it later. Set dryRun=true to preview without persisting.

Long conversations run async — the response is { jobId, statusUrl } and you must poll ctx_ingest_status (or GET /api/ingest-jobs/:id) until status='succeeded' or 'failed'. Short conversations return the full result inline. Pass async=true/false to force a path explicitly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asyncNoForce the async path (true) or sync path (false). Omit to let the server auto-pick — conversations longer than MEMORY_ASYNC_THRESHOLD messages (default 8) run async.
dryRunNoWhen true, run the full extract + diff pipeline but skip every DB write. Default false.
projectNoOptional project identifier within the workspace.
messagesYesConversation turns in chronological order.
agentSlugNoOptional identifier of the agent that produced/consumed this conversation. Recorded as metadata only.
maxClaimsNoCap on claims extracted from the conversation. Default 10, hard max 25.
sessionIdNoOptional conversation/session identifier. Recorded as metadata and on the audit row only.
subjectIdNoEnd-user identity this conversation belongs to (Mem0-parity user_id). Scopes dedup and tags every created context so it can be retrieved later via ctx_search subjectId or GET /api/memory.
workspaceNoWorkspace identifier the extracted memories belong to. Falls back to the request's active scope when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.1

TDQS

A4.4/5.0
Behavior5/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 so well: it discloses the LLM extraction step (durable facts only, skipping chit-chat), the shared kNN-dedup + diff + create/update/archive pipeline, the async threshold behavior, the { jobId, statusUrl } response and the need to poll ctx_ingest_status, plus dryRun's non-persisting semantics. This is rich operational context well beyond the schema.

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?

Purpose and sibling relationship are front-loaded, and the three short paragraphs are dense with useful detail rather than filler. There is mild redundancy in the async explanation, which repeats what the 'async' parameter description already states.

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 describing both response shapes (inline full result for short conversations, { jobId, statusUrl } for async) and the polling requirement. Nothing an agent needs to call it correctly appears to be missing.

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 schema already documents all nine parameters; the description's explanations of subjectId scoping, dryRun, and async largely restate the schema descriptions rather than adding new syntax or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

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 compound verb (extract and save durable memories) and its input resource (a raw multi-turn conversation), and explicitly frames itself as the 'turn-aware sibling of ctx_ingest', letting an agent separate it from the ingestion tool without opening either schema. Scope and output (deduped atomic contexts) are both named.

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 usage conditions: use subjectId to scope memories to a single end-user, use dryRun to preview, and how async selection works. It clearly explains the relationship to ctx_ingest but does not state when NOT to use this tool versus that sibling, so it falls short of full routing guidance.

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

Deploy Server

Other Tools