One external brain, model-agnostic, in production. Connect it to Claude in two minutes โ free trial, no credit card.
Cortex is a patent-pending semantic memory infrastructure developed by SKYNETLAB (Bergamo, Italy). Connected to your AI assistant as a remote MCP connector, it lets your conversations save decisions, context and sources โ and find them again in every later session. Your AI remembers, and can show why it remembers.
๐ Website: skynetlab-cortex.com ยท ๐ Patent ยท ๐ Benchmark ยท ๐ Paper ยท ๐ถ Pricing
๐ฎ๐น Versione italiana: README.it.md
Most memory tools for AI agents record what the agent did and retrieve similar text later. Cortex models what is true and how reliable it is:
Capability | What it means |
Quality Gate on write | Every memory passes a novelty/redundancy check before being stored. No junk accumulation. |
Typed claims & conflict tracking | Facts are extracted as claims; contradictions between memories are detected and tracked, not silently overwritten. |
Knowledge graph | Memories are linked by entities and typed relations, not just vector similarity. |
Coherence metric (ฮจ_C) | Each memory carries a native coherence score โ the system knows how well a memory fits what it already knows. |
Memory consolidation ("REM") | A continuous background cycle consolidates episodic memories into long-term knowledge. |
Transparent evidence | Answers can cite the memories and sources they come from. |
Cortex runs on globally distributed edge infrastructure operated in the European Union. The memory engine is covered by Italian patent application UIBM 102026000014026 (filed 15 May 2026).
Related MCP server: memory-mcp
Requirements: a Claude plan that supports custom connectors (the "Connectors" entry appears in Settings). No Cortex account needed beforehand โ it is created on first sign-in.
In Claude open Settings โ Connectors โ Add custom connector
Paste this URL and confirm:
https://skynetlab-cortex-saas-mcp.cortex-320.workers.dev/mcpAuthorize access on the Cortex consent page (Google or email sign-in). Your personal memory space is created automatically, isolated from every other user.
That's it. Talk to Claude as usual: "Remember that we chose supplier X", "what did we decide about the budget?", "show me the sources for this claim". Claude picks the right tool on its own.
claude mcp add --transport http cortex https://skynetlab-cortex-saas-mcp.cortex-320.workers.dev/mcpThen authenticate when prompted (/mcp shows connection status).
For MCP clients that don't support remote connectors natively, use the mcp-remote bridge. Example configuration (see examples/):
{
"mcpServers": {
"cortex": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://skynetlab-cortex-saas-mcp.cortex-320.workers.dev/mcp"]
}
}
}This repository also ships a small stdio MCP server (server/) that exposes the Cortex tools locally and forwards every call to the hosted service. It is meant for MCP clients, registries and evaluators that need a local process: it starts, lists its seven tools and answers introspection with no configuration at all; tool calls are forwarded when an access token is set.
git clone https://github.com/FilippoPilo/cortex-connector.git
cd cortex-connector
npm install
CORTEX_ACCESS_TOKEN=<your token> node server/index.jsOr with Docker:
docker build -t cortex-connector .
docker run -i --rm -e CORTEX_ACCESS_TOKEN=<your token> cortex-connectorVariable | Meaning |
| Bearer token for the hosted connector (the OAuth access token issued at sign-in, for example the one |
| Remote endpoint, defaults to the hosted Cortex connector. |
npm test runs a self test (initialize, tools/list, one call without token).
Tool | Type | Description |
Search memories | read | Semantic search across your memories |
Fetch memory | read | Full detail of one memory, with its sources |
Recall & synthesize | read | Narrative synthesis of what Cortex knows about a topic |
Show conflicts | read | Tracked contradictions between memories |
Save memory | write | Stores a memory โ after a quality check against duplicates and redundancy |
Write status | read | Outcome of a queued save: quality-gate verdict and any open conflicts |
Forget memory | destructive | Deletes a memory โ always with explicit confirmation |
Memories are personal: each user only sees their own. They are exportable and deletable on request, and the infrastructure operates in the European Union. Details: Privacy Policy.
To disconnect, simply remove the connector from your client's settings; your memories remain in your Cortex account until you request their deletion.
The Cortex memory engine is a hosted, patent-pending service โ its source code is not published. This repository contains the public documentation, the client-side configuration examples and a small stdio bridge (server/) for connecting to it. Everything in this repository is released under the MIT License.
๐ง info@skynetlab.net ยท Contact page
Cortex is a SKYNETLAB product โ independent research lab & deeptech studio, Bergamo, Italy. Founder: Filippo Pilotta (ORCID 0009-0000-5002-4199).
Some content and product outputs are generated or assisted by artificial intelligence, pursuant to Art. 50 of Reg. (EU) 2024/1689. AI transparency.
Show the contradictions detected between memories, with their open or resolved state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds useful output context ('open or resolved state') but does not disclose other behavioral traits such as pagination, ordering, or whether all conflicts are returned. With annotations carrying the safety profile, this is adequate.
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?
A single concise sentence, front-loaded with the action verb, with no filler or redundant wording. Every word contributes 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?
For a parameterless, read-only list tool, the description covers what it does and the state field. It does not describe the return format or ordering, but with no output schema and no parameters, this is largely sufficient. A minor gap is no mention of whether it returns all conflicts or requires prior setup.
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 input schema is empty (0 parameters), so the description has no parameter burden. The baseline of 4 applies, and the description does not need to explain any parameters.
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 states a specific verb ('Show') and a specific resource ('contradictions detected between memories'), and adds the state detail ('open or resolved'). This clearly distinguishes it from sibling tools like search or cortex_recall, which are broader memory retrieval operations.
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 is given on when to use this tool versus alternatives. It does not mention that this is the dedicated tool for conflict inspection, nor does it contrast with search or cortex_recall. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a memory given its id. Ask the user for explicit confirmation first.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | id of the memory to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, and the description reinforces this with 'Delete'. It adds a valuable behavioral ruleโ'Ask the user for explicit confirmation first'โwhich is not present in annotations or schema and is essential for safe invocation.
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 short, purposeful sentences. It front-loads the primary action and immediately follows with the critical safety instruction. There is no redundant or filler content.
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?
For a one-parameter destructive tool, the description covers the essential call conditions: the target id and the mandatory user confirmation. It omits return values or error behavior, but given the absence of an output schema and the simple nature of the operation, this is acceptable.
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 input schema already fully describes the single parameter ('id of the memory to delete') with 100% coverage. The description merely echoes 'given its id' without adding format, source, or additional lifecycle details, so it meets the baseline but no more.
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 states a concrete action ('Delete') and a specific resource ('a memory given its id'), making it clear what the tool does. This clearly distinguishes it from sibling read/write tools like cortex_recall, cortex_write, search, and fetch.
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?
It identifies a clear precondition: the agent must ask the user for explicit confirmation before calling. It also implies usage context by specifying that an id is required. However, it does not explicitly name alternatives or state when-not-to-use, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Narrative synthesis of what the user's memory knows about a topic, with the current state and what was superseded. Use it for questions like 'what do you know about X' or 'what is the current state of X'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Topic or question |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral detail: it synthesizes memory narratively, includes both current and superseded states. This goes beyond the annotations by revealing what kind of output to expect.
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 tight sentences with no filler. The first sentence defines the tool's core behavior, and the second provides concrete invocation examples. Everything earns its place.
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?
For a single-parameter, annotation-rich tool, the description covers what it does, what it returns conceptually, and when to use it. It could add a note about what happens when the memory has no knowledge of the topic, but this is a minor gap given the openWorldHint annotation.
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 100% for the single 'query' parameter, which already documents it as 'Topic or question'. The description reinforces this with example questions but does not add substantial new parameter-level meaning, so the baseline of 3 applies.
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 a specific verb ('Recall') and resource ('what the user's memory knows about a topic'), and further clarifies the output is a 'narrative synthesis' that includes current state and superseded information. This differentiates it from siblings like cortex_forget or cortex_write, even without naming them.
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 gives explicit usage triggers: questions like 'what do you know about X' or 'what is the current state of X'. It does not explicitly contrast with alternatives such as search or fetch, so it stops short of a full when-not-to-use guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save to the user's persistent memory (Cortex), on your own initiative while the conversation goes on: decisions and the reason behind them, stable facts about the person and their work, preferences and constraints they state, conclusions reached after effort, mistakes made and what they cost. Every write passes a quality gate: duplicates are rejected by the server and a refused write is not an error. Never save passwords, tokens, keys or card numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| basis | No | 'observed' if read from a concrete source (document, tool output, real data), 'inferred' if it is a deduction or an estimate. | |
| title | Yes | Short title | |
| claims | No | Optional. Atomic facts already structured, one per decision or statement; if given, conflict detection uses them directly. Example: {subject: 'Project Vega', predicate: 'adopts', object: 'Redis'}. | |
| content | Yes | Text to remember, in the user's language |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses valuable behavior: writes are proactive, every write passes a server-side quality gate, duplicate writes are rejected, and a refused write is not an error. It also imposes a hard security constraint on content. These are precisely the behavioral traits an agent needs to interpret outcomes correctly. No contradiction with annotations exists.
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, each earning its place: the first defines purpose and content scope, the second explains the quality-gate behavior, the third states the security prohibition. The core action is front-loaded. Despite being longer than average, the density is justified given the judgment-heavy nature of deciding what to write.
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?
For a moderately complex tool (5 params, no output schema, no nested objects), the description covers when to invoke, what to write, what to avoid, and edge-case behavior (refused writes). The single notable gap is that no output schema exists and the description does not state what a successful write returns. Given the richness of the annotations and schema, this is a minor omission rather than a functional gap.
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 description coverage is 80%, so the schema already documents title, content, claims, and basis in detail (including an example for claims). The description adds marginal semantic value by enumerating the kinds of content worth composing, which indirectly informs the content parameter, but it does not explain the undocumented 'tags' parameter. Since the schema carries most of the load, the baseline of 3 is appropriate.
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 opens with a specific verb+resource pair ('Save to the user's persistent memory (Cortex)') and immediately clarifies what counts as worth saving: decisions, stable facts, preferences, constraints, conclusions, and mistakes. It also states what must never be saved (passwords, tokens, keys, card numbers), making the tool's scope unambiguous. This clearly distinguishes it from siblings like cortex_recall, cortex_forget, and cortex_write_status.
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?
'on your own initiative while the conversation goes on' gives explicit when-to-use direction: the agent should write proactively, not only when asked. The description also gives a when-not boundary ('Never save passwords, tokens, keys or card numbers') and implies that duplicate-checking is unnecessary because the server rejects duplicates. However, it never names sibling alternatives (e.g., cortex_recall for retrieving, cortex_forget for deleting), so the differentiation is contextual rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Outcome of a save that cortex_write returned as queued: verdict of the quality gate and any open conflicts.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | job_id returned by cortex_write |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the description doesn't need to repeat safety. It describes the returned data (verdict and conflicts) but doesn't mention potential edge cases like job not found or whether it's a one-time check vs. pollable. The openWorldHint annotation adds some context but isn't elaborated.
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?
One sentence with no filler. It efficiently conveys the tool's purpose, input, and output in a compact form.
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 there is no output schema, the description specifies what is returned (quality gate verdict and open conflicts), which is sufficient. It could mention error handling or whether the status is immediate, but these are not critical gaps given the simple nature of the tool.
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, job_id, is clearly described as 'job_id returned by cortex_write', explaining its provenance and usage. Schema coverage is 100%, and no additional clarification 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?
The description clearly states the tool reports the outcome of a queued write, specifically the quality gate verdict and open conflicts. It distinguishes itself from cortex_write by referencing that cortex_write returned a queued status, though it doesn't explicitly name a sibling tool for differentiation.
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?
It implies usage after cortex_write returns a queued job, but doesn't explicitly state 'use this when you have a job_id from cortex_write' or contrast with alternatives like cortex_conflicts. The context is present but not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full text of a memory by its id (from search), with its history and sources. Cite its url when you use it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Memory id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds useful behavioral context: it returns full text, history, and sources, and instructs the agent to cite the URL. This goes beyond the annotations without contradicting them.
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 concise sentences, front-loaded with the core function and complemented by a usage instruction. There is no redundant or filler content.
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?
For a simple single-parameter read tool, the description is complete: it names the return contents (full text, history, sources), gives the sourcing instruction, and annotations cover safety. No additional context seems necessary for correct invocation.
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 description coverage is 100%, with the single 'id' parameter already documented as 'Memory id'. The description only repeats that the id comes from search, adding minimal semantic value beyond the schema.
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 states a specific verb ('Fetch'), a specific resource ('a memory by its id'), and clarifies the scope ('full text... with its history and sources'). It is clearly distinguished from the sibling 'search' by referencing results from search.
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 explicitly indicates this tool is used on memory ids obtained from search, giving clear operational context. It does not explicitly name alternatives or exclusions, but the workflow dependency is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the user's persistent memory (Cortex). Call it at the start of every conversation and before any answer that depends on who the user is or on what you did together before: the user must not have to repeat themselves. Returns results with id, title and url to cite. If it returns nothing, the memory is new or empty: tell the user once that you are connected to Cortex and offer to save what you are working on with cortex_write.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return format ('Returns results with id, title and url') and the behavior when no results are found (tell the user and offer to save with cortex_write). This aligns with the readOnlyHint annotation and provides transparency beyond basic 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 well-structured and front-loaded. The first sentence states the core purpose, followed by usage guidance, then return behavior, and finally the empty-result fallback. Every sentence contributes 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 lack of an output schema, the description adequately covers what to expect (results with id, title, url) and how to handle the case of no results. It also mentions the related tool (cortex_write) for the follow-up action, making the context complete for an agent.
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 schema covers the single parameter 'query' with a description ('Natural language query'), and the tool description does not add significant extra meaning to the parameter itself. It mentions the purpose but not specific query formatting or examples, so it stays at the baseline for high schema 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's purpose: 'Search the user's persistent memory (Cortex)'. It uses a specific verb ('Search') and identifies the resource. The context about calling it at the start of conversations further clarifies its role.
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 explicitly states when to use the tool: 'Call it at the start of every conversation and before any answer that depends on who the user is or on what you did together before'. It also provides guidance on what to do when no results are returned, referencing cortex_write.
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.
v1.1.0cortex_conflictscortex_forgetcortex_recallcortex_writecortex_write_statusfetchsearchScored across 7 tools
Most tools have distinct purposes: conflicts, forget, write, status, and fetch are clear. However, search, fetch, and recall all involve retrieving memory content and could overlap in practice, requiring careful description reading to pick the right one.
Naming is inconsistent: some tools use the cortex_ prefix (cortex_conflicts, cortex_forget, cortex_recall, cortex_write, cortex_write_status) while others do not (search, fetch). The pattern is not uniform, and cortex_write_status breaks the simple verb_noun structure.
Seven tools is a reasonable, focused set for a persistent memory server. Each tool covers a needed operation without feeling bloated or sparse.
The toolset covers the core memory lifecycle: write, read via search/fetch/recall, delete via forget, plus conflict and status handling. An explicit update or list-all operation is missing, but write can likely serve as upsert and search covers listing, so the surface is largely complete.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
StremAI MCP: shared memory for AI coding agents. Connected agents can recall. OAuth + local stdio.
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
