Tried this, no joy. I created a CORE API key from my workspace->API page, configured MCP with Claude Desktop, I get this: "You didn't provide an API key...You can obtain an API key from https://platform.openai.com/account/api-keys"
Other memory MCP servers do not require access to OpenAI - and not even sure why I would want any of my data going there when I use a paid Claude subscription.
I like the idea here, but doesn't seem very usable.
hey thanks for the feedback, agreed there are a lot to get right
1. If you have self hosted it yes then we need OpenAI api key, we are also working to get things working with llama so should be available soon (but if from cloud you shouldn't have got this error)
2. We also have moved away from openAI embedding (BGE-M3) to our own hosted in the cloud.
In self host we already have claude code support happy to help there
You've identified a fundamental gap - that meta-cognitive "I could retrieve this" intuition that humans have but LLMs lack.
Our graph approach addresses this:
- Structure knowledge with visible relationship patterns before loading details
- Retrieval system "senses" related information without fetching everything
- Temporal tracking prioritizes recent/relevant information
- Planning recall frequency tracking for higher weightage on accessed facts
In SOL(personal assistant), we guide LLMs to use memory more effectively by providing structured knowledge boundaries. This creates that "I could know this if I looked" capability.
that's the exact problem we've been solving! Context bloat vs. memory depth is the core challenge.
our approach tackles this by being selective, not comprehensive. We don't dump everything into context - instead, we:
- use graph structure to identify truly relevant facts (not just keyword matches)
- leverage temporal tracking to prioritize current information and filter out outdated beliefs
- structure memories as discrete statements that can be included/excluded individually
the big advantage? Instead of retrieving entire conversations or documents, we can pull just the specific facts and relevant episodes needed for a given query.
it's like having a good assistant who knows when to remind you about something relevant without overwhelming you with every tangentially related memory.
the graph structure also gives users more transparency - they can see exactly which memories are influencing responses and why, rather than a black-box retrieval system.
This is helpful. Love to see a demo of how tight you got the context window injection against a query. Thats where theres always 70% bloat in my previous systems.
I solved this by building holonically, same structure as you have it seems roughly, so I actually, through a ui can grab a holon and inject it into context including its children ( holon ~ nested heirarchy ), And I usually use semantic search so Ill add that in as well.
I have not added agentic memory flows yet, like when a model asks itself if it has what it needs and allows itself to look deeper.. have you?
I have agentic flows with other things, about 15 cascading steps between user and ai response, but have not done so with memory yet.
One of the challenges I was facing with other memory MCP servers is to get the LLM clients to actually use it to recall relevant information when they need it. Implementing to MCP tools is one thing, getting LLM clients to invoke them at the right time is another.
We faced the same challenge while building SOL (https://github.com/RedPlanetHQ/sol) — a personal assistant that relies heavily on memory for context and continuity.
Getting LLMs to invoke memory tools at the right time is definitely trickier than just wiring up MCP correctly. We're still refining it, but we've made good progress by explicitly guiding the assistant within the system prompt on when and how to use memory.
Using something on similar lines as rules in claude/cursor etc has been working better. It’s not perfect yet, but this combination of prompt engineering and structured tool exposure has been moving us in the right direction.
Hey, another co-founder of CORE. Great question about triples vs. fact statements! Your house example actually highlights why we went with a reified graph:
With fact statements, you'd need to decide upfront: is this one "about my house" memory or separate facts? Our approach lets you do both:
Representation flexibility: For your house example, we can model (house, needs repair, attic bath) AND connect it to (attic bathroom, has fixture, bath). The LLM extraction helps maintain consistency, but the graph structure allows both high-level and detailed representations simultaneously.
Updating and deduplication:
- We identify potential duplicates/updates by matching subject-predicate patterns
- When new information contradicts old (e.g., repair completed), we don't delete - we mark the old statement invalid at timestamp X and create a new valid statement
- This maintains a complete history while still showing the current state
- The structured format makes conflicts explicit rather than buried in text
The schema isn't rigid - we have predefined types (Person, Place, etc.), but relationships form dynamically. This gives structure where helpful, but flexibility where needed.
In practice, we've found this approach more deterministic for tracking knowledge evolution while still preserving the context and nuance of natural language through provenance links.
https://github.com/RedPlanetHQ/core/blob/main/README.md You can check in our readme on how to use mcp server