qcdoc-mem

Memory Remember Conversation

memory_remember_conversation

Save conversation insights automatically by sending the transcript to an LLM backend for fact extraction. Avoid manual selection, deduplicate with thread IDs, and store durable memories.

Instructions

Hand a conversation to the backend to extract facts from automatically.

This is the hands-off write path: instead of deciding fact-by-fact what to save, send the turns and let the backend's LLM extraction decide. Requires an LLM to be configured on the server; without one this returns an error rather than silently storing nothing.

Input Schema

TableJSON Schema

Name	Required	Description
`user_id`	No	Whose memory to write to.
`messages`	Yes	The turns, oldest first, each `{"role": "user"\|"assistant"\|"system", "content": "..."}`. Only user turns and the final assistant reply are considered.
`immediate`	No	Skip the debounce window when the conversation is known to be over.
`thread_id`	Yes	Conversation identifier. It keys the de-duplication watermark, so reusing the same id with a growing transcript will not re-extract what was already processed.
`agent_name`	No	Optional per-agent bucket.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 21, 2026

TDQS

A4.2/5.0

Behavior4/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 discloses that this is a write path, that extraction is delegated to a backend LLM, and that a missing LLM config causes an error rather than silently storing nothing. This is meaningful behavioral context 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.

Conciseness5/5

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

Three short sentences with no wasted words. The core action is front-loaded, the second sentence clarifies the design intent, and the third covers the prerequisite and failure mode. It avoids restating schema fields.

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?

Given no annotations and an output schema, the description covers the essential context: what the tool does, when to use it, and what happens if the server lacks an LLM. Minor gaps like the exact write effect or return shape are acceptable because the schema already documents parameters and output.

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 description coverage is 100%, so the structured schema already documents all parameters thoroughly. The description adds no per-parameter meaning beyond the schema, but it doesn't need to given the high coverage.

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 and resource: handing a conversation to the backend for automatic fact extraction. It also distinguishes itself from the fact-by-fact manual path, which clearly separates it from the sibling memory_remember tool.

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?

It clearly explains when to use this tool: when you want a hands-off, automatic extraction path rather than deciding fact-by-fact what to save. It also flags the LLM prerequisite and the resulting error behavior, though it does not explicitly name the alternative tool or list cases where manual saving is preferable.

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

Deploy Server