Click on "Deploy 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., "@cortex-memory What did we learn about the memory leak in the worker service?"
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.
Bi-Temporal, 4-Tier Hybrid Cognitive Memory Engine for Autonomous Coding Agents
CortexMemory provides external cognitive memory for AI coding assistants via the Model Context Protocol (MCP). By decoupling active working context from long-term memory, it maintains a lean, stationary context window ($O(1)$) that cuts token consumption by ~82%, eliminates compaction amnesia, and prevents repetitive debugging loops.
The engine runs 100% locally on your machine using Docker (PostgreSQL 16 + Neo4j 5.26) and local vector embeddings.
CortexMemory separates memory into 4 distinct tiers coordinated across two asynchronous pathways:
The Hot Path (Sub-Second Interaction):
Every tool call, error, and diff is logged non-blockingly to PostgreSQL (Tier 2) in < 5ms.
When the agent queries memory, the Cognitive Memory Router blends active scratchpad state (Tier 1), dense vector retrieval (Tier 3), and bi-temporal graph traversals (Tier 4) via Reciprocal Rank Fusion (RRF): $$RRF(d) = \sum_{m \in {\text{vector}, \text{graph}, \text{episodic}}} \frac{w_m}{k + \text{rank}_m(d)}$$
A Token Budgeter packs the top ranked facts into a lean Markdown injection capped at 2,500 tokens.
The Sleep-Cycle Consolidation Path (Background Reflection):
An AFTER INSERT trigger on PostgreSQL fires pg_notify('new_episode_channel').
The background daemon wakes reactively (no polling) and claims unconsolidated batches using SELECT ... FOR UPDATE SKIP LOCKED.
It distills raw events through a lightweight reflection model (Claude 3.5 Haiku, Gemini Flash, or local Ollama) into 4 atomic operations:
ADD: Inserts a new entity or dependency edge (valid_from = now(), valid_to = null).
UPDATE: Refreshes properties or bumps confidence scores.
DELETE: Sets valid_to = now() on superseded relationships (soft invalidation).
NOOP: Discards transient noise (e.g. ls, exploratory file reads).
Updates are committed to Neo4j, and episodes are marked consolidated = true.
Related MCP server: Agent Memory Bridge
Approach | How It Operates | Core Failure Mode |
Flat Context Accumulation | Piles raw turns and tool outputs into a single prompt window. | Linear context growth ($O(N)$) triggers lossy compaction at ~160k tokens, causing compaction amnesia and repetitive error spirals. |
Naive Vector RAG | Indexes code snippets into a flat vector database (Pinecone, Chroma). | Temporal Blindness: Outdated code often matches queries with high similarity, causing hallucinations. Cannot resolve multi-hop graph dependencies or detect error loops. |
CortexMemory maps cognitive memory to computer storage tiers (Registers $\rightarrow$ SSD WAL $\rightarrow$ Inverted Index $\rightarrow$ Relational Topology):
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā Tier 1: Working Memory (RAM / L1 Cache) ā
ā - Engine: In-Memory / Python dictionary (Strict 4,000 token ceiling) ā
ā - Role: Active goal, current debugging hypothesis, transient scratchpad ā
ā - Benefit: Sub-millisecond prompt focus; prevents task drift ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¬āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā (Async Log & Action Stream)
ā¼
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā Tier 2: Episodic Store (Write-Ahead Log / SSD) ā
ā - Engine: PostgreSQL 16 (JSONB, GIN Indexing, SHA-256 Hashes) ā
ā - Role: Append-only audit trail of every tool execution, diff, and output ā
ā - Benefit: Lossless auditability; instant repetitive error detection via ā
ā SHA-256 hash match; zero-polling pg_notify triggers ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¬āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā (Background Sleep-Cycle Consolidation)
ā¼
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā Tier 3: Semantic Store (Fast Inverted Search Index) ā
ā - Engine: Neo4j Native Lucene Vector Index (1536-dim Cosine Similarity) ā
ā - Role: Dense vector embeddings of entities, patterns, and decisions ā
ā - Benefit: Conceptual discovery when exact symbol names are unknown ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā¬āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā (Unified in Neo4j)
ā¼
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā Tier 4: Knowledge Graph (Bi-Temporal Relational Topology) ā
ā - Engine: Neo4j Bi-Temporal Property Graph ā
ā - Role: Code entities and edges with [valid_from, valid_to] intervals ā
ā - Benefit: Multi-hop dependency traversal; deterministic temporal ā
ā disambiguation (valid_to IS NULL = active, non-null = obsolete) ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāMeasured over a 50-turn refactoring task:
Metric | Flat Context (Native Agent) | CortexMemory Engine | Difference / Advantage |
Cumulative Tokens | ~3,380,000 tokens | ~600,000 tokens | -82.2% token reduction |
Prompt Latency (p95) | 3.8s ā 7.2s (huge KV-cache) | 0.8s ā 1.4s (lean 10k prompt) | ~75% faster responses |
Amnesia Events | Multiple auto-compactions | 0 amnesia events | 100% deterministic recall |
Temporal Accuracy | None (confuses old & new code) | Strict ( | Zero temporal hallucinations |
Error Loop Recovery | Prone to repeating failed fixes | Instant SHA-256 hash alert | Loops halted after 1 repeat |
Dependency Resolution | Heuristic regex/grep searching | Exact Cypher graph traversal | True structural awareness |
Scenario: An agent encounters an environment or test error, attempts a fix that fails, and later repeats the exact same attempt because previous command outputs rolled off context.
Cortex Action: Every error is indexed with a canonical SHA-256 hash in Tier 2. When the same failure repeats, Cortex flags repetitive_loop_detected: true with the occurrence count, instructing the agent to change approach immediately.
Scenario: A project migrates from REST to tRPC. An agent reading older commits or documentation attempts to generate obsolete REST endpoints.
Cortex Action: Consolidation marks obsolete relationships with valid_to = datetime(). Cypher queries filter WHERE valid_to IS NULL, ensuring only currently active architecture conventions are supplied to the prompt.
Starts PostgreSQL 16 and Neo4j 5.26 with pre-configured schemas and APOC plugins:
docker compose -f docker/docker-compose.yml up -dPostgreSQL: localhost:5432 (user: cortex, db: cortex_memory)
Neo4j Browser: http://localhost:7474 (user: neo4j, pass: cortex_secure_password)
uv sync
uv run pytest(Runs the 42 unit and integration tests across storage tiers, hashing, RRF, and FastMCP tools).
CortexMemory implements the Model Context Protocol (MCP), connecting directly to Claude Code, Cursor, Windsurf, and Antigravity.
~/.claude.json or cursor.json){
"mcpServers": {
"cortex-memory": {
"command": "uv",
"args": [
"--directory",
"/Users/supreme/Dev/cortex-memory",
"run",
"python",
"-m",
"cortex.mcp.server"
]
}
}
}Tool Name | Description | Key Parameters |
| Ingests a tool run, prompt, git commit, or error into Tier 2. |
|
| Hybrid RRF retrieval returning synthesized, token-budgeted context. |
|
| Checks if a stack trace or error has occurred previously. |
|
| Sets active goal and hypothesis in Tier 1 Working Memory. |
|
| Traverses active dependencies for a file or function in Neo4j. |
|
| Triggers background sleep-cycle distillation on demand. |
|
# Agent logs a test failure
response = await cortex_record_event(
session_id="session_01",
turn_index=12,
event_type="test_failure",
payload={"stderr": "AssertionError: 401 != 200 at auth.test.ts:45"},
outcome_status="FAILED",
target_entity="src/auth/jwt.ts"
)
# Output:
# {
# "event_id": "c71a39...",
# "content_hash": "8ea6c75...",
# "repetitive_loop_detected": true,
# "occurrence_count": 2
# }# Agent queries relevant architectural facts before editing
context = await cortex_query_memory(
query="How is authentication validated in API routes?",
target_entity="src/api/routes.ts",
max_tokens=1500
)
# Injected Context:
# ### Active Working Scratchpad
# **Active Goal:** Migrate from REST to tRPC
#
# ### Graph Dependencies
# - src/auth/session.ts (depth 1) [USES_PROTOCOL: tRPC]
# - src/models/user.ts (depth 2)Apache 2.0
Checks if identical error stack trace has occurred previously.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| error_output | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It states the action but does not mention side effects (e.g., read-only nature), required context (e.g., session boundaries), performance implications, or what the check actually returns. This is insufficient for a tool with no annotation support.
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 a single, clean sentence with no wasted words, honoring conciseness. However, it is under-specified given the lack of annotations, making it more of a stub than a well-structured definition. It is front-loaded but lacks necessary detail.
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 purpose (error-loop detection) and its two required parameters, the description fails to convey critical information such as return type, error handling, or relationship to other cortex tools. The presence of an output schema is not explained, leaving agents without knowledge of what the check returns. It is not complete enough for reliable 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 0%, so the description must explain parameter meaning, but it does not. The parameter names 'session_id' and 'error_output' are relatively self-explanatory from their titles, yet no format, constraints, or usage details are provided. This adds minimal 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 uses a specific verb ('Checks') and identifies a concrete condition ('identical error stack trace has occurred previously'), making the tool's purpose clear. It distinctly differs from siblings like cortex_query_memory or cortex_inspect_graph, which focus on other operations, though it does not name them explicitly.
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 provides no guidance on when to use this tool versus alternatives, nor does it state prerequisites or exclusions. An agent must infer from the tool name and context that it is for error-loop detection, but no explicit routing information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually forces background sleep-cycle consolidation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining side effects and operational impact, but it only says 'forces background sleep-cycle consolidation' without specifying consequences, safety concerns, idempotence, or whether this is a mutating action. 'Forces' hints at forcefulness, but important behavioral context is missing.
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 a single sentence and avoids filler and is appropriately front-loaded with the central action. However, the wording is somewhat terse and relies on domain jargon, so conciseness is achieved at the expense of clarity.
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 has one optional parameter and an output schema, the description covers only the bare action and leaves out why, when, and what 'limit' means. An agent can understand the high-level purpose but cannot correctly invoke or reason about the side effects.
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, 'limit', has no schema description and 0% schema description coverage, and the description does not explain what 'limit' controls (e.g., how many items are consolidated or how many records are affected). The description adds no semantic meaning to the single parameter, so the description fails to compensate for the schema gap.
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 uses a clear verb and target ('forces ... consolidation') and clearly refers to the sleep-cycle consolidation operation, which separates it from siblings like cortex_inspect_graph or cortex_record_event. It is understandable at a high level, though the term 'consolidation' is somewhat domain-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 gives no guidance on when to invoke this tool manually versus manual alternatives or sibling tools. It implies a manual override over automatic behavior, but it never states the conditions under which an agent should choose this over another cortex_* tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queries bi-temporal knowledge graph dependencies for a code entity.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Queries' implies read-only behavior, but it does not explain temporal semantics, whether dependencies are direct or transitive, required permissions, side effects, or failure modes.
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, directly front-loaded with the action and object, with no wasted words. It is appropriately concise for the information it conveys.
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 is too sparse for a specialized tool with no annotations and a complex concept like 'bi-temporal knowledge graph dependencies.' It lacks selection context, behavioral detail, and interpretation of the output, leaving the agent to guess important usage details.
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 0%, so the description must compensate. It adds that entity_id refers to 'a code entity', which provides some meaning beyond the schema alone, but it gives no format, provenance, or expected identifier style.
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 ('Queries'), a specific resource ('knowledge graph dependencies'), and a scope ('for a code entity'). This clearly distinguishes it from siblings like cortex_update_scratchpad and cortex_record_event.
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 when-to-use guidance, exclusions, or alternative tool routing is provided. The agent must infer usage entirely from the tool name and the brief description, and it is not told when to choose this over cortex_query_memory or cortex_check_error_loop.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hybrid 4-tier retrieval returning synthesized, lean context.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_tokens | No | ||
| session_id | No | ||
| target_entity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. The phrase 'returning synthesized, lean context' does disclose that results are not raw and are intentionally summarized, which is useful. However, the '4-tier retrieval' behavior is unexplained, and no constraints such as freshness, fallback behavior, or side effects are disclosed.
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 a single sentence and easy to scan, but it is not optimally concise because the phrase 'Hybrid 3-tier retrieval returning synthesized, lean context' contains unexplained jargon. It is small but not every piece of phrasing 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?
This is a minimal one-liner for a tool with four parameters, no annotations, and no parameter semantics. It lacks usage guidance, alternative routing, and parameter clarification, making it substantially incomplete for an agent to invoke it correctly in varied contexts. The presence of an output schema helps only with return-shape expectations, not with selecting parameters or understanding behavior.
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 0%, and the description does not compensate at all. It never mentions query, max_tokens, session_id, or target_entity, leaving the agent without any semantic guidance for four parameters beyond their raw names and types.
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 that the tool performs retrieval over memory and returns synthesized context. It is not a tautology and identifies the primary operation and resource, though the 'Hybrid 4-tier' phrasing adds jargon without explanation and does not explicitly distinguish it from sibling retrieval tools like cortex_inspect_graph.
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?
There is no guidance about when to use this tool versus alternatives such as cortex_inspect_graph or cortex_check_error_loop. The description implies the tool is for querying memory, but it never states when to prefer it over siblings, what kinds of queries are appropriate, or when a different tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hot-path non-blocking episodic event logging.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | ||
| event_type | Yes | ||
| session_id | Yes | ||
| turn_index | Yes | ||
| target_entity | No | ||
| outcome_status | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two important behavioral traits: 'hot-path' (performance-sensitive) and 'non-blocking' (asynchronous or fire-and-forget). These are valuable beyond what annotations provide (none exist). However, it doesn't disclose what happens on failure (e.g., is the event silently dropped?), whether events are persisted or volatile, or any ordering guarantees. For a logging tool, these behavioral details matter significantly for an agent deciding whether to rely on it.
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 extremely concise at 5 words, which is appropriate for a hot-path logging tool. It front-loads the most critical information (hot-path, non-blocking) and doesn't waste words. However, it's almost too terse ā a bit more context about what 'episodic event' means in this system would be valuable without sacrificing conciseness.
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 has 6 parameters, 5 required, no schema descriptions, no annotations, and no output schema details, the description is insufficient. The agent needs to know what event types are valid, what outcome_status values are expected, and what the payload structure should be. The output schema exists but its contents aren't shown, so the description should compensate. The 'hot-path non-blocking' context helps but doesn't address the core question of how to properly construct an event record.
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 0%, so the description must compensate for the lack of parameter documentation. The description mentions 'episodic event logging' but doesn't explain what each parameter means (e.g., what constitutes an 'event_type', what 'outcome_status' values are expected, what 'payload' should contain). With 6 parameters and 5 required, the agent has no guidance on how to construct valid calls. The parameter names are somewhat self-explanatory, but the description adds no semantic value beyond the schema itself.
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 'Hot-path non-blocking episodic event logging' clearly identifies the tool as an event logging mechanism with specific performance characteristics (hot-path, non-blocking). It distinguishes itself from sibling tools like cortex_query_memory or cortex_inspect_graph, which are read-oriented, and cortex_force_consolidation, which is a maintenance operation. However, it doesn't explicitly state what 'record_event' does with the event data or how it relates to the episodic memory system, leaving some ambiguity about the exact resource being acted upon.
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 in hot-path scenarios where non-blocking behavior is required, which gives some context for when to use this tool. However, it doesn't explicitly state when NOT to use it or mention alternatives like cortex_update_scratchpad for state updates or cortex_query_memory for retrieval. The 'hot-path' qualifier suggests performance-critical contexts, but there's no explicit guidance on choosing between this and other logging/recording tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates Tier 1 transient working memory scratchpad.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| session_id | Yes | ||
| active_goal | No | ||
| current_hypothesis | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Updates' without explaining whether this is a partial update, a full replacement, whether the session must already exist, or what side effects occur.
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 brief and front-loaded, but it is under-specified for a tool with four parameters and no annotation context. It is concise without waste, yet the brevity comes at the cost of necessary guidance.
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?
Despite having an output schema, the description does not explain the required session_id, the meaning of the optional fields, or the update semantics. With no annotations and zero schema coverage, the tool is incompletely described for reliable 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 0%, and the description does not compensate by mentioning session_id, notes, active_goal, or current_hypothesis. The agent gets no semantic help beyond raw parameter names, which is inadequate for correctly populating the call.
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 clear action ('Updates') and a specific resource ('Tier 1 transient working memory scratchpad'), which is enough to distinguish this tool from the sibling list. It lacks explicit differentiation language, but the verb-resource pairing is unambiguous.
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 no guidance on when to use this tool versus alternatives such as cortex_record_event or cortex_query_memory. There are no prerequisites, exclusions, or context about when updating the scratchpad is appropriate.
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.
v0.1.0cortex_check_error_loopcortex_force_consolidationcortex_inspect_graphcortex_query_memorycortex_record_eventcortex_update_scratchpadScored across 6 tools
Each tool targets a distinct memory operation: error-loop checking, scratchpad updates, hybrid retrieval, graph inspection, consolidation, and event recording. There is minimal overlap between querying, inspecting, and recording.
All tools share the cortex_ prefix and follow a consistent snake_case verb_noun pattern. The naming clearly communicates action and target.
Six tools is a well-scoped set for a memory server, covering retrieval, recording, updates, inspection, and maintenance without redundancy.
Core memory workflows are covered, but there is no explicit delete/forget or scratchpad reset operation, which could be a minor gap depending on expected memory lifecycle management.
Hosted MCP memory for coding agents: persistent across sessions, editable markdown, team sharing.
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
