Uses local Ollama models to distill raw input into anonymous, factual knowledge before any data leaves the device.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Distill Save: the team uses gRPC not REST"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives Claude Code a shared team knowledge base — a local LLM transforms your raw input into anonymous, factual knowledge before anything leaves your device.
No author. No frustration. No names. Just a clean, reusable fact.
pip install distill-mcp
ollama pull gemma3:4b && ollama pull nomic-embed-text
claude mcp add distill -- python -m distill_mcpThen in Claude Code:
You: "No, we don't use REST here. We switched to gRPC last month."
Claude: [saves to distill]
Got it. I've noted that the team uses gRPC, not REST.
... next session, different repo ...
You: "Set up the API for this new service."
Claude: [searches distill → finds gRPC decision]
Based on your team's knowledge, I'll set up a gRPC
service since the team switched from REST last month.Distill saves when you correct a mistake or make a decision, and searches before proposing architecture — no prompting needed.
Related MCP server: myBrAIn
Every "memory MCP" stores your raw text in a database. Distill doesn't. The local LLM is a mandatory privacy gateway that transforms personal thoughts into impersonal team knowledge.
Raw stays local | LLM distills | Team sync | Platform agnostic | |
Claude-Mem | Partial ( | Cloud API compresses | Single-user | Claude Code only |
Cipher | No | No | Yes | No |
Supermemory | No | No | Yes | No |
Mem0 | Yes | No | No | Yes |
Memctl | Yes | No | Yes | Yes |
Distill | Yes | Yes | Yes | Yes |
Based on public documentation as of March 2026.
Getting Started — full tutorial
Installation — all setup options
GCP Backend — team-shared database
MCP Tools — all 8 tools
Configuration — environment variables
Architecture — Clean Architecture design
Privacy Model — how your data stays private
git clone https://github.com/5queezer/distill.git
cd distill
uv sync
uv run pytest tests/ -x -vSoft-delete a memory. It will no longer appear in search results.
If agent_id is provided, the memory is only deleted when it belongs to that agent. Returns 'forbidden' if the memory belongs to a different agent.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| agent_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by clarifying 'soft-delete' (implies reversibility) and the ownership check behavior with agent_id. Annotations indicate destructiveHint=true, which is consistent, and description elaborates on the specific behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, and every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's straightforward behavior, the description covers all necessary aspects: action, visibility change, conditional behavior, and error case. It is complete for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description explains the semantic of agent_id (optional, owner check) and implies id identifies the memory. This compensates for missing schema descriptions, though id's role is obvious.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'soft-delete' and the resource 'memory', and the effect of no longer appearing in search results. This distinguishes it from sibling tools like update_memory and get_memory, which are not destructive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the condition for using agent_id and the error response when ownership mismatch, providing clear context for invocation. However, it does not explicitly state when not to use this tool versus alternatives, though the tool is unique in its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trace the supersedes chain for a memory in both directions.
Returns the full history: predecessors (what this memory replaced) and successors (what replaced this memory), ordered oldest to newest. Useful for understanding how a decision evolved over time.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive. The description adds that it returns both predecessors and successors ordered oldest to newest, which is useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with the main purpose front-loaded. No wasted words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with one parameter, annotations, and an output schema, the description covers purpose, output structure, and use case adequately. Could elaborate slightly on response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'id', and the description does not elaborate on its meaning beyond implying it's a memory ID. With 0% schema description coverage, the description could add more details about the ID format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool traces the supersedes chain for a memory in both directions, distinguishing it from sibling tools like get_memory or get_memories. The verb 'trace' and resource 'supersedes chain' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use: to understand how a decision evolved over time. It does not explicitly state when not to use or mention alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full memory details by IDs. Batch multiple IDs in one call.
Use after search_memory to get content for relevant results only.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds batching behavior info, which is useful. No contradictions. Could mention response format but output schema covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, direct sentences with no extraneous words. Purpose and usage guidance front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required param, output schema exists), description covers all necessary aspects: what it does, how to use it, and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for 'ids'. Description explains it accepts multiple IDs for batching and fetches full memory details, fully compensating for lacking schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Fetch full memory details by IDs' and distinguishes from siblings by noting batching. Clearly indicates it retrieves content for specific IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use after search_memory to get content for relevant results only', providing clear when-to-use and relationship with a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific memory by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description correctly reflects read-only behavior. However, no additional behavioral details are provided beyond what's in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, efficiently communicates the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description is minimally sufficient for a simple retrieval tool. But it lacks context relative to siblings like get_lineage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single parameter 'id', and the description only adds 'by its ID' without specifying format or constraints. More detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Retrieve' and resource 'memory' with a specific method 'by its ID'. It distinguishes from sibling tools like search_memory and list_recent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like search_memory or list_recent. Missing explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent memories as compact index. Use get_memories for full content.
Optionally filter by repo, tag, type, or agent_id.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| tag | No | ||
| type | No | ||
| limit | No | ||
| agent_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds behavioral detail: returns a compact index, not full content, and focuses on recent entries. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and key alternative; second lists optional filters. Every word is necessary; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), description needn't detail return values. Covers purpose, filters, and a sibling distinction. Could mention ordering or recency definition, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description lists optional filters (repo, tag, type, agent_id) by name, providing semantic hints beyond the schema. However, no explanation of the limit parameter or effects of filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists recent memories as a compact index, distinguishing from get_memories which provides full content. The verb 'list' and resource 'recent memories' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions alternative get_memories for full content, but lacks guidance on when to use list_recent vs siblings like list_stale or search_memory. Optional filters are stated but no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List memories that are likely stale based on age and access patterns.
Stale memories have low Weibull survival scores and few accesses. Review the list and use forget() to clean up outdated knowledge.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds context about Weibull survival scores and access patterns, enhancing understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs. The first sentence states the purpose, and the second adds details and recommended action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering safety, the description is mostly adequate but misses parameter explanations. The core purpose and usage context are conveyed, but the omission of parameter details reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the repo or limit parameters, leaving the agent to infer their meaning from the schema alone. While parameters are intuitive, the description should ideally clarify them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists stale memories based on age and access patterns. It distinguishes from siblings like list_recent and search_memory by focusing on staleness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to list stale memories) and suggests next action (use forget()). It lacks explicit contrast with alternatives but provides a clear workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search team knowledge before proposing architecture, creating files, refactoring, or answering "how should we..." questions.
Also search when the user says: "we decided", "last time", "previously", "remember when", "what's our pattern for".
Returns compact index (~30 tokens/result). Use get_memories to fetch full content for relevant IDs only (not all results). Optionally filter by repo name, agent_id, and/or date range (after/before as ISO 8601 strings, e.g. "2025-01-01").
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| repo | No | ||
| agent_id | No | ||
| after | No | ||
| before | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive. Description adds that it returns compact index (~30 tokens/result) and recommends get_memories for full content, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with primary use case and well-structured, though slightly verbose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given presence of output schema, description covers when to use, what it returns, and optional filters. Sibling tools are listed. Complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains optional parameters (repo, agent_id, after, before) with format example. query and top_k are not described, but top_k has default in schema. Overall compensates well for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches team knowledge and specifies use cases like before proposing architecture or when user says 'we decided'. It distinguishes from siblings by recommending get_memories for full content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (before creating files, refactoring, etc.) and when not to (use get_memories for full content). Also provides optional filter guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-distill new content and supersede an existing memory.
The old memory is soft-deleted. A new memory is created with the distilled version of the provided content.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| content | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readonly and non-destructive. The description adds that the old memory is soft-deleted (consistent with non-destructive) and a new memory is created with distilled content. This provides behavioral context beyond annotations, though the term 'distilled' is somewhat vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains no extraneous information. Every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main process, but lacks details on edge cases (e.g., invalid id, empty content), prerequisites, or what 'distilled' means. Given low complexity and presence of output schema, it is adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It mentions 'the provided content' (mapping to 'content' parameter) and 'existing memory' (mapping to 'id'), but does not explicitly describe the parameters' semantics. This is insufficient for an agent to understand the parameters without schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool re-distills and supersedes an existing memory, with explicit mention of soft-deleting the old memory and creating a new one. This differentiates it from sibling tools like 'forget' (plain deletion) and get/retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating an existing memory with new content, but does not specify when to use versus alternatives (e.g., 'forget' vs 'update_memory') or any prerequisites. The guidance is implicit, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.4.0forgetget_lineageget_memoriesget_memorylist_recentlist_stalesearch_memoryupdate_memoryEach tool targets a distinct aspect of memory management: search, retrieval by ID or batch, listing recent or stale, forgetting, updating with lineage, and tracing lineage. There is no ambiguity between tools.
Tool names follow a consistent verb_noun pattern in snake_case (search_memory, get_memories, list_recent, update_memory, etc.), with 'list_' and 'get_' prefixes clearly indicating the action.
Eight tools cover the core memory operations without being excessive or insufficient. Each tool serves a clear purpose in the memory lifecycle.
The surface covers most operations (search, retrieve, list, forget, update, lineage). The only noticeable gap is the lack of a dedicated create_memory tool, though update_memory might double as creation in some contexts.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shared memory for all your AI agents, your whole team and every MCP client — save, search, recall.
shared AI-context layer for teams — persistent memory your agents search and update over MCP
An MCP memory server. One memory your agents share — across models, devices and apps.
Your product team's shared strategic memory — an MCP server your AI tools reason over.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/5queezer/distill'
If you have feedback or need assistance with the MCP directory API, please join our Discord server