What can you do with this server?

The LatentContext MCP Server is a local MCP server for managing structured working memory and session context for AI assistant conversations, backed by SQLite storage. * Session Management (session_start): Initialize a fresh, isolated memory session, automatically archiving any previously active session. * Store Memories (memory_store): Save structured notes of various types — core facts, fact (knowledge graph entries), preference (user likes/dislikes), event (session happenings), and summary (compressed overviews) — with optional confidence scores and entity tagging. * Retrieve Context (memory_retrieve): Search and retrieve relevant memories within a configurable token budget, with optional filters by time range, memory type, and confidence score. * Compress Memory (memory_compress): Condense accumulated memory at different scopes — working (current buffer), session (merge summaries), or epoch (long-term consolidation) — to optimize token usage. * Forget/Correct Memories (memory_forget): Deprecate, correct, or permanently delete a specific memory entry by ID. * Check Status (memory_status): View statistics on memory tiers, token estimates, knowledge graph size, vector store count, and current session ID. * Knowledge Graph: Automatically indexes fact-type memories into a local knowledge graph via entity tagging. * Optional Vector Embeddings: Supports local vector embeddings in SQLite for semantic search and retrieval. * Flexible Storage: Defaults to project-local storage, configurable via LATENTCONTEXT_DATA_DIR or a config file for shared access across projects.

How do I use LatentContext MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LatentContext MCP Server store a note that I decided to use React for the frontend" 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.

LatentContext MCP Server

by Master0fFate

Overview Schema Related Servers Score Discussions

TypeScript

Local

LatentContext MCP Server

LatentContext is a local Model Context Protocol server for keeping structured working notes during an assistant session. It stores memories, session summaries, a small knowledge graph, and optional local vector embeddings in SQLite.

Install

Node.js 18 or later is required. Add the published server to an MCP host:

{
  "mcpServers": {
    "latentcontext": {
      "command": "npx",
      "args": ["-y", "latentcontext-mcp@latest"]
    }
  }
}

Or install it globally and use the executable:

npm install -g latentcontext-mcp

{
  "mcpServers": {
    "latentcontext": {
      "command": "latentcontext-mcp",
      "args": []
    }
  }
}

Restart the MCP host after changing its configuration. The server uses stdin/stdout for MCP JSON-RPC, so diagnostic output is written to its log file rather than the terminal.

Related MCP server: DataDam Personal Data MCP Server

Storage

By default, runtime state is project-local:

<launched-project>/.latentcontext/
├── memory.db
└── server.log

<launched-project> is the MCP server process's current working directory. Configure the host to launch the server from the project root when project isolation is wanted. The repository ignores only its root .latentcontext/ directory, so this local state is not committed.

Storage is only shared when an explicit location is configured. Set LATENTCONTEXT_DATA_DIR in the MCP host environment to use one directory across projects:

{
  "mcpServers": {
    "latentcontext": {
      "command": "latentcontext-mcp",
      "args": [],
      "env": {
        "LATENTCONTEXT_DATA_DIR": "C:/shared/latentcontext"
      }
    }
  }
}

LATENTCONTEXT_DATA_DIR takes precedence over all configured storage locations. Alternatively, point LATENTCONTEXT_CONFIG at a configuration file:

{
  "storage": {
    "dataDir": "./shared-state",
    "sqliteFile": "memory.db"
  },
  "embedding": {
    "provider": "local"
  }
}

A relative storage.dataDir is resolved relative to that configuration file. The server also reads latentcontext.config.json from the default data directory or beside the installed package. A latentcontext.config.json in the launched project is ignored unless LATENTCONTEXT_ALLOW_PROJECT_CONFIG=1 is set. Use "provider": "none" to disable embeddings.

Tools

Tool	Use
`session_start`	Start a session; any active session is archived first.
`memory_store`	Record a note, decision, fact, or event for the active session.
`memory_retrieve`	Retrieve relevant session context within a token budget.
`memory_compress`	Compress working memory or summaries.
`memory_forget`	Deprecate, correct, or remove a memory.
`memory_status`	Report current storage and session statistics.

Stored notes need at least 10 words; 25 or more are recommended. Session working memory is isolated by session ID, and prior working memory is archived when a session changes or the server shuts down.

Run from source

git clone https://github.com/Master0fFate/LatentContext-MCP.git
cd LatentContext-MCP
npm install
npm run build
npm start

For a local MCP configuration, use the built entry point:

{
  "mcpServers": {
    "latentcontext": {
      "command": "node",
      "args": ["/absolute/path/to/LatentContext-MCP/dist/index.js"]
    }
  }
}

Development

npm run build             # Compile TypeScript and prepare the executable
npm test                  # Run the full test suite
npm run test:smoke        # Build and exercise the packaged server
npm run audit:production  # Audit production dependencies
npm run dev               # Run TypeScript source locally

License

MIT

Available Tools

6 tools

memory_compressA

Compress memory at a given scope to reduce token usage and consolidate information.

WHEN TO USE:

'working': When working memory is getting large during a long conversation. Compresses current session buffer into a summary.
'session': When there are many session summaries. Merges multiple session-level summaries into fewer entries.
'epoch': After many sessions have accumulated. Promotes session summaries into high-level long-term knowledge. Requires at least 10 session summaries.

EFFECTS:

All compression is lossy — details are condensed but key information is preserved.
Compressed data is re-embedded for semantic search.
Original entries are removed after compression.

ParametersJSON Schema

Name	Required	Description	Default
`scope`	Yes	Compression scope: 'working' (current session), 'session' (merge sessions), 'epoch' (long-term consolidation).

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description fully shoulders the transparency burden. It explicitly states that compression is lossy, original entries are removed, and data is re-embedded. This disclosure is comprehensive for a mutation tool.

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?

The description is well-structured with clear sections (WHEN TO USE, EFFECTS). Every sentence adds value, and there is no redundancy. It is appropriately sized for a single-parameter tool.

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?

Given the tool's simplicity (one param, no output schema), the description is complete. It covers purpose, usage conditions, and behavioral effects without any gaps. An agent can confidently select and invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter exists with 100% schema coverage. The description adds significant meaning beyond the schema by explaining each scope's effect and the requirement for epoch. This enriches the agent's understanding of how to select the appropriate scope.

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 clearly states the tool's purpose: compressing memory to reduce token usage and consolidate information. It identifies the specific resource ('memory') and action ('compress'), and distinguishes it from siblings like memory_forget or memory_retrieve.

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?

The description provides explicit guidance for when to use each scope (working, session, epoch), including a prerequisite for epoch (at least 10 session summaries). While it doesn't explicitly state when not to use the tool, the sibling context and clear scope usage cover most decision-making needs.

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

memory_forgetA

Mark a memory as outdated, incorrect, or to be deleted.

WHEN TO USE:

When the user corrects previously stored information.
When stored facts become outdated (e.g., user changed jobs, moved cities).
When duplicate or incorrect memories need cleanup.

ACTIONS:

'deprecate': Lowers confidence score so the memory is deprioritized but not removed. Use when unsure.
'correct': Replaces the memory content with new, correct information. Requires the 'correction' parameter.
'delete': Permanently removes the memory. Use for clearly wrong or duplicate entries.

You need the memory_id which is returned when you store a memory, or visible in memory_status output.

ParametersJSON Schema

Name	Required	Description
`memory_id`	Yes	ID of the memory to modify (UUID format, returned by memory_store).
`action`	Yes	Action to take: 'deprecate' (lower priority), 'correct' (replace content), 'delete' (remove permanently).
`correction`	No	New content to replace the memory with. Required when action is 'correct'.

TDQS

A4.6/5.0

Behavior5/5

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

No annotations provided, so the description fully explains behavioral traits: effects of each action (deprecate, correct, delete), prerequisites (memory_id), and conditional parameter requirements.

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?

The description is well-organized with sections, bullet points, and clear headings. Every sentence is informative and concise, no fluff.

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 modification tool with 3 parameters, conditional logic, and no output schema, the description is comprehensive. It could mention return values or effects on other operations, but current level is sufficient.

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%, baseline 3. The description adds value by explaining the action enum meanings and clarifying the conditional requirement for 'correction' parameter when action='correct'.

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 clearly states the tool's purpose: 'Mark a memory as outdated, incorrect, or to be deleted.' It distinguishes from siblings (memory_store, memory_retrieve) by focusing on modification/removal.

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?

Provides explicit 'WHEN TO USE' bullets covering common scenarios. Lacks explicit when NOT to use, but the context is clear. Siblings are listed externally.

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

memory_retrieveA

Retrieve memories stored in the CURRENT session. Returns only data from this conversation — no cross-session contamination.

MANDATORY — ALWAYS call this immediately after session_start. Also call before ANY task that could benefit from context stored earlier in this conversation.

WHEN TO USE:

IMMEDIATELY after session_start — to check if there is any context from earlier in this session.
When you need to recall what was discussed/decided/stored earlier in THIS conversation.
Before starting a new task step — retrieve context about what was done so far.

HOW TO USE THE RESULTS:

READ every section of the returned context carefully.
APPLY the information to your current task — this is why it was stored.
If you see stored decisions or notes, BUILD ON THEM.
Do NOT ignore retrieved context — it was stored specifically to help you.

SESSION ISOLATION:

Each session starts with ZERO entries — completely fresh.
Only returns data stored via memory_store during THIS session.
No data from past sessions, global knowledge graph, or vector store is included.

SECTIONS IN OUTPUT:

[Current Session]: What has been stored so far in this conversation.
[Current Session Notes]: Compressed notes from this session (if working memory was compressed).

TIP: Use a higher token_budget (5000-8000) for comprehensive context. Use lower (1000-2000) for focused lookups.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	What to search for. Be descriptive — include project names, tech stack, topic areas. Example: 'user website fate.rf.gd design preferences audio visualizer' rather than just 'website'.
`token_budget`	No	Max tokens to return. Default 3000. Use 5000-8000 for broad conversation-start context. Use 1000-2000 for focused lookups.
`filters`	No

TDQS

A4.5/5.0

Behavior5/5

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

Since no annotations are provided, the description fully discloses session isolation, cross-session contamination absence, and output sections. No contradictory statements.

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?

Well-structured with headings, front-loaded core purpose. Some repetition of session isolation, but overall efficient for the amount of guidance provided.

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?

With nested objects and no output schema, the description adequately covers what to expect (sections), usage scenarios, and tips. Could be more precise on return format, but sufficient for an agent.

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?

Adds usage tips for token_budget (e.g., 5000-8000 for broad context) and explains the query parameter with examples. Schema already covers 67% of parameters, so description adds meaningful but not essential extra value.

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 clearly states it retrieves memories from the current session, with emphasis on session isolation. This distinguishes it from siblings like memory_compress, memory_forget, etc., which are for different operations.

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?

Provides explicit when to use: immediately after session_start and before tasks that benefit from context. Lacks explicit when-not-to-use or direct alternatives, but the context is clear and actionable.

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

memory_statusA

Get storage statistics for all memory subsystems.

WHEN TO USE:

When debugging memory-related issues.
When the user asks "what do you remember?" or "how much is stored?".
To check if session_start was called (shows current session ID).
To monitor token budgets and plan compression.

SHOWS: Tier counts, token estimates, knowledge graph size, vector store count, and current session ID.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description fully carries the burden. It discloses output contents (tier counts, token estimates, etc.) and indicates it can show session status. No contradictions.

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?

Concise first sentence, followed by well-organized WHEN TO USE and SHOWS bullet lists. Every sentence serves a purpose; no redundancy.

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?

Completely adequate for a zero-parameter tool: describes purpose, usage guidance, and output. No gaps given the simplicity and no output schema needed.

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 has 0 parameters with 100% coverage, so description adds value by explaining what the tool returns (SHOWS list). Baseline for 0 params is 4.

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?

Clear verb and resource: 'Get storage statistics for all memory subsystems.' The SHOWS list specifies output, distinguishing it from sibling tools like memory_compress or memory_retrieve which have different purposes.

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?

Provides explicit WHEN TO USE bullet list covering debugging, user queries, session check, and budget monitoring. Does not explicitly state when not to use, but the context is clear and sufficient.

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

memory_storeA

Store information in long-term memory. Call this PROACTIVELY whenever you learn something new — do NOT wait to be asked.

CRITICAL — CONTENT QUALITY RULES: Your memory entries MUST be DETAILED, SELF-CONTAINED paragraphs that a future AI can read and FULLY understand WITHOUT needing to re-derive anything. Each entry should be 3-5 sentences minimum. Include WHO, WHAT, WHY, HOW, and WHERE relevant.

BAD (useless — too short, forces re-thinking): "Fixed audio issue" "User likes dark mode" "Website uses Vanta.js"

GOOD (detailed — saves tokens by preventing re-derivation): "Fixed a CORS audio playback issue on the user's website fate.rf.gd. The problem was that the audio element was trying to load files from a different origin. Solution: added crossorigin='anonymous' attribute to the element and configured the server to send Access-Control-Allow-Origin headers. The audio visualizer now works correctly with the Vanta.js background." "User strongly prefers dark mode designs with deep blue (#0a0e27) and purple (#6c63ff) accent colors. They want glassmorphism effects, smooth animations, and premium-feeling interfaces. They dislike plain/basic designs and have explicitly requested 'wow factor' aesthetics in multiple conversations." "The user's personal website at fate.rf.gd uses a multi-section single-page layout with: Vanta.js globe wireframe background animation, a music player with bass-reactive glow visualizer, glassmorphic card components, Google Fonts (Inter/Outfit), and is hosted on InfinityFree. The tech stack is vanilla HTML/CSS/JS with no framework."

REMEMBER: A memory that takes 20 tokens to store but saves a future LLM from spending 500 tokens re-analyzing is EXTREMELY valuable. Write entries as if briefing a colleague who has never seen this project before.

WHEN TO USE:

After the user tells you their name, preferences, project details, or any personal information.
After completing a task — store WHAT was done, WHY, HOW it was solved, and the OUTCOME.
When you discover important facts about the user's codebase, tech stack, architecture, or workflow.
When you make design decisions — store the decision AND the reasoning.
Whenever information might be useful in future conversations.

MEMORY TYPES (choose carefully):

'core': CRITICAL permanent facts (user identity, key project info, important preferences). Never evicted. Use sparingly — only for the 5-10 most important things.
'fact': Concrete knowledge with entities. Include full context, not just the fact. Automatically indexed in the knowledge graph.
'preference': User likes/dislikes/habits. Describe the preference with specifics (colors, styles, patterns), not just the category.
'event': What just happened in this session. Describe the task, approach, solution, and result in detail.
'summary': Compressed notes about a session or topic. Should be a dense briefing paragraph, not bullet points.

ENTITIES: Always provide relevant entity names in the 'entities' array for 'fact' type. The first entity is treated as the subject. Example: entities: ["User", "dark mode"] for "User prefers dark mode".

ParametersJSON Schema

Name	Required	Description
`content`	Yes	DETAILED, self-contained paragraph (3-5+ sentences). Must include full context so a future AI can understand without re-deriving. Include specifics: names, paths, colors, versions, decisions, reasoning. NEVER write single sentences — that defeats the purpose of memory.
`memory_type`	Yes	Category: 'core' for critical permanent info, 'fact' for knowledge, 'preference' for user likes/dislikes, 'event' for what just happened, 'summary' for compressed notes.
`confidence`	No	Confidence 0.0-1.0. Lower confidence = evicted first. Default 1.0. Use lower values for uncertain or temporary information.
`entities`	No	Key entities this memory relates to. REQUIRED for 'fact' type — first entity is the subject. Example: ['User', 'JavaScript'] for 'User knows JavaScript'.

TDQS

A4.6/5.0

Behavior5/5

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

No annotations provided, so the description carries full burden. It thoroughly explains behavior: proactive storing, content quality mandates, memory types with eviction rules, confidence levels, and entity indexing. This provides complete transparency.

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?

The description is long but well-structured with clear sections (CRITICAL RULES, WHEN TO USE, MEMORY TYPES). It front-loads the core purpose. Some verbosity from examples is justified for clarity, but could be slightly more concise.

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?

Given 4 parameters, 2 required, no output schema, the description is exceptionally complete. It covers content quality, memory types, entities, confidence, and usage contexts. An AI agent has all necessary information to use the tool correctly.

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%, baseline 3. The description adds significant value beyond schema: good/bad examples for content, detailed explanations of each memory_type, and entity requirements. It enhances understanding without contradicting schema.

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 clearly states the tool stores information in long-term memory and provides a specific verb and resource. It distinguishes itself from siblings like memory_retrieve by emphasizing proactive use and content quality rules.

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?

The description includes extensive when-to-use guidance (e.g., after learning user info, completing tasks, discovering facts) and content quality rules. However, it lacks explicit when-not-to-use or direct comparisons to sibling tools, though the proactive call to action is clear.

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

session_startA

Start a new memory session. Call this ONCE at the very beginning of each new conversation.

MANDATORY WORKFLOW — follow these steps IN ORDER every single time:

Call session_start (this tool) FIRST.
IMMEDIATELY after, call memory_retrieve to check for any context from this session.
Throughout the conversation, call memory_store to save DETAILED notes about everything important.

SESSION ISOLATION:

Each session starts with ZERO entries — completely fresh memory.
No data from past sessions, knowledge graph, or vector store leaks in.
Only data stored via memory_store during THIS session will be retrievable.
Session IDs are timestamp-prefixed UUIDs for guaranteed uniqueness.

WHAT IT DOES:

Creates a completely fresh, empty memory for the new conversation.
Returns the new session ID.

WARNING: Always call this first to ensure session isolation.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description comprehensively covers behavior: creates fresh empty session, ensures no data leakage, returns new session ID, and guarantees isolation. No contradictions.

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?

Well-structured with sections and steps, but somewhat verbose. Every part adds value, though could be slightly more concise.

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?

Given no output schema, description adequately explains what is returned (session ID with timestamp-prefixed UUID). It integrates with sibling tools and covers all necessary context for initialization.

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?

No parameters, but description adds meaning beyond schema by explaining the session concept and its role. According to guidelines, baseline is 4 for zero params, and this is appropriately descriptive.

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 clearly states 'Start a new memory session' with a specific verb and resource. It distinguishes from sibling tools by emphasizing this is the initialization step for a new conversation.

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?

Provides explicit workflow instructions: call first, then memory_retrieve, then memory_store. It also emphasizes one-time usage per conversation and warns against alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv1.1.1Jun 14, 2026
- First observedmemory_compress
- First observedmemory_forget
- First observedmemory_retrieve
- First observedmemory_status
- First observedmemory_store
- First observedsession_start

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Disambiguation5/5

Each tool targets a distinct operation: compress, forget, retrieve, status, store, and session start. There is no overlap in purpose, and agents can easily distinguish when to use each.

Naming Consistency4/5

Five of six tools follow the 'memory_verb' pattern (memory_compress, memory_forget, etc.), but 'session_start' breaks the pattern. This is a minor inconsistency, but the naming is otherwise predictable and readable.

Tool Count5/5

Six tools is well-scoped for a memory management server. Each tool serves a clear, essential function without redundancy, covering storage, retrieval, compression, forgetting, status, and session lifecycle.

Completeness4/5

Core CRUD-like operations are covered (store, retrieve, forget, compress), along with status and session management. A minor gap is the lack of a cross-session search tool, but this aligns with the design principle of session isolation.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

memoryOAuth
com.leapmemory
Long-term memory for AI assistants. Isolated per-user storage, recall across conversations.
Knowledge & Memory RAG Systems
1
mcpOAuth
ai.atlaso
AI memory layer — one shared, persistent memory across every AI tool you connect.
Knowledge & Memory RAG Systems
1
BrainsOAuth
io.github.brainsforai
Personal wiki and memory layer for AI assistants. Persistent, structured memory across sessions.
Knowledge & Memory Note Taking AI & Machine Learning
2
EngramOAuth
io.github.debragail
Persistent memory for AI agents — verbatim conversations, searchable by meaning.
Knowledge & Memory Search
211

Related MCP Servers

cursor-cortex
Knowledge & Memory Project Management Developer Tools
flores-ac
F
license
B
quality
A
maintenance
Provides structured external memory for AI assistants, enabling persistent context, branch notes, tacit knowledge, and checklists to overcome AI memory loss and context confusion.
Updated 22 days ago (2026-08-15 05:33 UTC)
38
4
-
DataDam Personal Data MCP
Knowledge & Memory Databases
KennethLeeJE8
A
license
Not graded
quality
D
maintenance
A persistent memory layer for AI tools that decouples personal data from AI's unstable memory, enabling you to mention information once and have it remembered forever across all conversations.
Updated 5 months ago (2026-03-31 02:55 UTC)
3
MIT
CONTINUITY
Knowledge & Memory Developer Tools
duke-of-beans
F
license
Not graded
quality
C
maintenance
Provides session persistence, crash recovery, decision tracking, and context compression for AI assistants, enabling seamless multi-session continuity.
Updated a month ago (2026-08-10 02:45 UTC)
-
hmem
Knowledge & Memory Agent Orchestration Autonomous Agents
Bumblebiber
A
license
Not graded
quality
F
maintenance
Enables persistent, portable memory for AI agents across sessions, devices, and providers with token-efficient 5-level lazy loading and automatic session capture.
Updated 9 days ago (2026-08-28 14:11 UTC)
78
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Master0fFate/LatentContext-MCP'

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

LatentContext MCP Server

Install

Storage

Share storage deliberately

Tools

Run from source

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API