This server provides persistent, long-term memory for AI agents via MCP tools, enabling storing, retrieving, and managing knowledge across sessions.
Memorize content: icx_remember stores documents, code, facts, or text into topological memory nodes with metadata (family, filename, space).
Semantic recall: icx_recall_scoped answers natural language questions by retrieving grounded facts and citations from stored memory.
Keyword search: icx_search_facts finds memory nodes by keyword or entity overlap for exploration.
Verbatim quoting: icx_quote_slot retrieves exact character-for-character quotes from stored document registers by family and index.
Inspect memory health: icx_inspect_space returns telemetry like active nodes, synapses, grounded facts, and contradiction alarms.
Reset conversation: icx_reset_session clears dialogue history while preserving all learned memory.
Provides Infinite Context integration for GitHub Copilot in VS Code, enabling persistent storage and recall of project context and decisions.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Infinite Context (ICX) MCP Server remember this code snippet about quicksort"
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.
Official Model Context Protocol (MCP) connector for Calera Labs Infinite Context (ICX). Connects AI agents (Claude Desktop, Cursor, VS Code, Zed, and custom autonomous swarms) directly to persistent, sub-quadratic topological memory on the Volumetric Lattice Network.
"Context Without Limits. Memory Without Loss."
Zero Attention Diffusion: Rather than stuffing millions of tokens into dense attention where models suffer Lost-in-the-Middle decay, ICX crystallizes knowledge into permanent $A_4$ simplicial lattice nodes (icx_remember).
Sub-1ms $A_4$ Simplicial Transitive Graph Walker: Traverses 5-hop causal authority and dependency paths ($A \to B \to C \to D$) in a single sub-millisecond CPU pass (icx_multihop_walk), resolving BABILong 500k-1M+ token chains with 100% precision.
Sub-100µs In-Process WASM & CodeAct Execution: Execute programmatic data analysis, aggregations, and deterministic Python/WASM calculations with 0.00% math hallucinations (icx_wasm_exec, icx_exec) achieving a $680\times$ token arbitrage moat.
Multi-Agent Shared REPL Swarms ($V_t$): Heterogeneous agent teams (Cursor, Claude, Cline, OpenDevin) share atomic variable state, distributed mutex leases, and AST structures without re-serializing context into text tokens (icx_swarm_state, icx_var_set, icx_var_get).
2026-07-28 Stateless Protocol Core: Fully compliant with the 2026-07-28 Stateless MCP Specification (SEP-2243, SEP-2575, SEP-2549) with sub-5ms zero-handshake direct tool calls and intelligent caching (ttlMs: 86400000).
100% Sweep on Major Public Benchmarks:
96.28% (466/484 exact) on RULER MRCR v2 at 128k–1M context (and 100.00% on 10M NIAH / BenchLM 1M single-needle).
100.00% on BABILong 500k 5-hop causal resolution in 882µs.
100.00% on $\tau$-bench multi-policy retention.
99.76% cost & token savings on Artificial Analysis evaluation.
1.0 Grounding Score on SWE-bench AST symbol fidelity.
Streamable Hosted Endpoint: Zero local model downloads required. Connect via streamable HTTP/SSE with your API key from dashboard.caleralabs.com.
Related MCP server: Mnemexa MCP
Add the following to your project's .cursor/mcp.json (or global Cursor Settings → Features → MCP):
{
"mcpServers": {
"infinite-context": {
"url": "https://icx.caleralabs.com/mcp",
"headers": {
"X-License-Key": "clabs_live_YOUR_KEY",
"X-Space-ID": "default"
}
}
}
}(Get your free API key at dashboard.caleralabs.com)
Add to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"infinite-context": {
"url": "https://icx.caleralabs.com/mcp",
"headers": {
"X-License-Key": "clabs_live_YOUR_KEY"
}
}
}
}Install automatically across Claude, Cursor, or VS Code using Smithery:
# For Claude Desktop
npx -y @smithery/cli install @calera-labs/icx-mcp --client claude
# For Cursor IDE
npx -y @smithery/cli install @calera-labs/icx-mcp --client cursor
# For VS Code
npx -y @smithery/cli install @calera-labs/icx-mcp --client vscodeAdd to .vscode/mcp.json:
{
"servers": {
"infinite-context": {
"url": "https://icx.caleralabs.com/mcp",
"headers": {
"X-License-Key": "clabs_live_YOUR_KEY"
}
}
}
}If your environment only supports local stdio sub-processes:
{
"mcpServers": {
"infinite-context": {
"command": "npx",
"args": ["-y", "@caleralabs/icx-mcp"],
"env": {
"ICX_LICENSE_KEY": "clabs_live_YOUR_KEY",
"ICX_SPACE_ID": "default"
}
}
}
}Tool | Purpose | Primary Inputs | Behavior |
| Stores text, code, decisions, and documentation into persistent long-term memory. |
| Additive & Non-destructive |
| Performs semantic search across memory to retrieve grounded facts and source citations for QA. |
| Read-only |
| Keyword and entity search across memory nodes for lexical exploration and token lookup. |
| Read-only |
| Retrieves exact character-for-character verbatim text and SHA-256 hashes from document registers. |
| Read-only |
| Returns diagnostic telemetry: active nodes, total synapses, grounded facts, and contradiction alarms. |
| Read-only |
| Clears conversational turn history while preserving all underlying persistent memory. |
| Mutates session only |
| Extracts fine-grained text/JSON deltas and crystallizes them into the lattice in sub-2ms on CPU. |
| Mutating Sync |
| Lists all active continuous changefeed connectors (GitHub, GitLab, Notion, Drive, Linear, Slack, SQL). | None | Read-only |
| Registers a new cloud webhook changefeed connector with AES-256-GCM secret vaulting. |
| Mutating Sync |
| Executes O(1) instant memory unlinking and revocation of all facts from a source without retraining. |
| Mutating Purge |
| Retrieves historical delta synchronization events, deltas processed, facts learned, and latency metrics. | None | Read-only |
| Executes programmatic Python code in a sandboxed runner with direct sub-5ms native |
| Programmatic CodeAct |
| Executes in-process WebAssembly / Native memory scripts with sub-100µs latency and 0.00% math error. |
| Fast-Path Kernel |
| Sub-1ms $A_4$ Simplicial Transitive Graph Walker for multi-hop causal chains and transitive deduction. |
| Causal Graph Traversal |
| Inspects or executes atomic multi-agent shared workspace variables ($V_t$) and distributed leases. |
| Swarm Coordination |
| Stores typed structured data (JSON, ASTs, schemas) into shared agent variable space with CAS support. |
| Atomic Mutation |
| Retrieves shared workspace variable with version metadata and lease validation. |
| Read-only |
| Lists all registered variable names and schema types in the multi-agent shared workspace. |
| Read-only |
To ensure your autonomous agents systematically store architecture decisions, traverse causal paths, and recall ground-truth context, add this block to your agent's system prompt:
1. Store project decisions, architectural constraints, and key invariants in ICX using `icx_remember`.
2. Before answering historical codebase questions or resolving complex dependencies, use `icx_recall_scoped` or `icx_multihop_walk` to retrieve exact grounded facts and transitive causal chains.
3. For multi-step data processing or mathematical aggregations, use `icx_exec` or `icx_wasm_exec` for 0.00% hallucination deterministic evaluation.
4. In multi-agent swarms, coordinate shared state and AST definitions using `icx_var_set` and `icx_var_get` without polluting LLM token context.Product Landing Page: https://icx.caleralabs.com
Interactive MCP Documentation: https://icx.caleralabs.com/mcp-docs
Scientific Research Paper: https://icx.caleralabs.com/paper
Universal Dashboard & Keys: https://dashboard.caleralabs.com
Calera FINSEC MCP: Certified SEC EDGAR financial memory for AI agents with 0.00% statistical hallucination and cryptographic filing provenance (Glama Hub · Smithery).
Apache License 2.0. See LICENSE for details. Built by Calera Labs.
Audits and retrieves real-time telemetry for a partitioned memory space (active node count, total synapses, grounded facts count, memory state, and contradiction alarms). Use this tool to monitor memory health, verify ingestion, or inspect space capacity. Read-only with no side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| space_id | No | Optional memory space partition to inspect. Defaults to caller default space. |
| Name | Required | Description |
|---|---|---|
| state | Yes | description=Memory space state (active | idle) |
| status | Yes | description=Space inspection status |
| space_id | Yes | description=Target memory space partition |
| active_nodes | Yes | description=Active topological simplicial nodes |
| total_synapses | Yes | description=Total learned neural synapses |
| grounded_facts_count | Yes | description=Total decoded grounded facts |
| contradictions_detected | Yes | description=Contradiction alarms in space |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true, and the description reinforces with 'Read-only with no side effects.' It adds value by declaring the tool performs an 'audit' with real-time telemetry, which signals a non-mutating inspection. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first lists the tool's outputs and actions, the second gives use cases and safety. No filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one optional parameter, has an output schema (so return values are already documented), and annotations cover read-only safety. Description covers health monitoring and verification cases, which is complete for this scope.
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 optional parameter. The description mentions 'defaults to caller default space' which echoes schema, but does not add new detail beyond that. Baseline 3 is appropriate since schema fully documents the param.
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 names a specific verb ('Audits and retrieves') on a specific resource ('partitioned memory space'), and lists specific telemetry items ('active node count, total synapses, grounded facts count, memory state, and contradiction alarms'). It clearly distinguishes from siblings which focus on recall, search, and session 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?
States when to use: 'monitor memory health, verify ingestion, or inspect space capacity.' Does not explicitly name alternatives or when not to use, but the use cases are clear given sibling tools have distinct functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves exact character-for-character verbatim text quotes from stored document registers by document family and ordinal slot index. Use this tool when exact contractual wording, legal clauses, or code revisions must be quoted without AI paraphrasing. Use icx_recall_scoped for semantic QA instead. Read-only with no side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | 1-based ordinal member index (e.g. 1 for first revision, 2 for second revision). | |
| family | Yes | Document family identifier (e.g. 'contract.indemnity', 'msa.pricing'). | |
| space_id | No | Optional memory space partition where the family was stored. Defaults to caller default space. |
| Name | Required | Description |
|---|---|---|
| index | Yes | description=Ordinal slot index (1-based) |
| family | Yes | description=Document family category |
| sha256 | Yes | description=Cryptographic content hash |
| status | Yes | description=Retrieval status (VERIFIED_VERBATIM_QUOTE | REGISTER_SLOT_EMPTY) |
| space_id | Yes | description=Target memory space partition |
| source_uri | Yes | description=Original document source URI |
| exact_quote | Yes | description=Verbatim character-exact text stored in register |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already establishes the read-only safety profile. The description adds context about exact character-for-character retrieval and 'no side effects,' but does not disclose edge-case behavior such as out-of-range index handling or access requirements. With annotations present, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the core function, the intended use case, and the alternative tool. It is front-loaded with the most important information and contains no filler.
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 moderate complexity, full schema coverage, readOnlyHint annotation, and presence of an output schema, the description is complete. It explains what the tool returns, when to use it, and how it differs from the closest sibling, without needing to restate schema details or output structure.
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%, so the schema fully documents family, index, and space_id. The description adds minimal semantic value beyond the schema, mostly reinforcing that index is an 'ordinal slot index.' This meets the baseline for schema-covered parameters but does not elevate it.
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 and resource: 'Retrieves exact character-for-character verbatim text quotes from stored document registers by document family and ordinal slot index.' This clearly distinguishes it from the semantic sibling tool icx_recall_scoped by emphasizing exactness over paraphrasing.
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?
Explicit usage guidance is provided: 'Use this tool when exact contractual wording, legal clauses, or code revisions must be quoted without AI paraphrasing.' It also names the alternative for semantic QA: 'Use icx_recall_scoped for semantic QA instead.' This fully addresses when to use and when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs associative semantic recall across long-term memory to retrieve grounded facts, citations, and source documents matching a natural language question. Use this tool when answering questions about previously saved documents or facts (e.g. 'What is the pricing tier?', 'Who is the lead architect?'). If you only need raw keyword matching across entity names, use icx_search_facts instead. For character-exact verbatim quotes of stored documents, use icx_quote_slot. Read-only with no side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language question, keyword, or concept to recall from persistent lattice memory. | |
| top_k | No | Maximum number of grounded facts to retrieve (default: 10, min: 1, max: 50). | |
| space_id | No | Optional memory space partition to restrict recall to. Defaults to caller default space. |
| Name | Required | Description |
|---|---|---|
| count | Yes | description=Number of grounded facts returned |
| facts | Yes | description=List of recalled grounded facts and citations |
| query | Yes | description=Natural language query submitted |
| status | Yes | description=Recall status (VERIFIED_RECALL | NO_GROUNDED_FACTS_FOUND) |
| space_id | Yes | description=Target memory space partition |
| total_in_space | Yes | description=Total nodes in active memory space |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include readOnlyHint: true and the description says 'Read-only and has no side effects,' but this is only a reinforced safeness; beyond that, it also adds what the annotation doesn't show: the action is 'semantic recall' over 'long-term storage', returning grounded facts, quotes, and source documents. It does not disclose rate limiting, token limits, or partial failures.
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?
Four crisp sentences. The first sentence packs the core capability; the second contains examples; the third shows the alternative; the fourth says read-only. No wasteful words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The data is a single high-level semantic retriever with a parameter count of 3 and a large number of sibling alternatives. The input schema and annotations are available; the output schema is presumably present (the signal indicates having an output schema). The description says facts/ citations, but there is no mention of 'no answer' style or edge cases. Existing output schema may resolve but is not shown.
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 has three properties overall with a 100% description coverage. The description words provide semantic context beyond schema: the user question is 'an input text, keyword, or concept'; top_k is 'the number of grounded facts to retrieve (default 10; min 1; max 50); space_id is 'optional partition area for restricting the memory. This does enough, and while the schema already reports defaults/min/max, its descriptions are not fully redundant with 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 opens with a specific action ('performs associative semantic recall across long-term memory'), a precise resource ('to retrieve grounded facts, citations, and source documents'), and an explicit showcase of how it is distinct from its siblings: it calls out icx_find_facts for raw keyword matches and icx_quote_slice for character-exact verbatim quotes.
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?
States clearly when to use it ('when answering questions about already saved documents or facts'), exemplars included; the explicit alternatives are stated: for raw keyword matching across all entity names, use icx_find_facts instead; for exact verbatim quotes, use icx_quote_slice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stores text, documents, code snippets, or conversational facts into long-term persistent memory for later retrieval across sessions. Ingests content into topological memory nodes with zero context window decay. Use this tool whenever you need to save facts, contracts, documentation, or user details for future reference. Do not use for querying existing memory (use icx_recall_scoped or icx_search_facts instead). Ingestion is additive and non-destructive.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The raw text, markdown document, code file, or factual statement to memorize. | |
| family | No | Optional document family grouping for deterministic verbatim register quoting (e.g. 'contract.indemnity', 'auth.tokens'). | |
| filename | No | Optional filename or document title provenance tag (e.g. 'architecture.md', 'master_agreement.pdf') to track document origin. | |
| space_id | No | Optional memory space partition (e.g. 'codebase_docs', 'contracts_v2', 'user_preferences'). Defaults to caller default space. |
| Name | Required | Description |
|---|---|---|
| family | No | description=Document semantic family |
| status | Yes | description=Crystallization status (VERIFIED_STORED | error) |
| filename | Yes | description=Stored document identifier |
| space_id | Yes | description=Target memory space partition |
| active_nodes | Yes | description=Total active nodes in memory space |
| learned_facts | Yes | description=Count of new simplicial facts learned |
| bytes_ingested | Yes | description=Raw bytes stored in verbatim register |
| persisted_state | Yes | description=Storage layer provenance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false, the annotation already signals a write operation. The description adds valuable behavioral context: states ingestion is additive and non-destructive, mentions 'zero context window decay', and clarifies topological memory nodes. It doesn't detail failure modes or side effects beyond that, but the additive/non-destructive note is strong supplementary transparency.
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 adding distinct value: what it stores, and when to use/avoid with alternatives. No redundancy, front-loaded with the primary purpose. Ideal 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?
The tool has 4 parameters (1 required), 100% schema coverage, no enums, and an output schema exists. The description covers purpose, ingestion behavior, non-destructive semantics, and usage boundaries. Minor gap: it doesn't explicitly state what the tool returns (e.g., confirmation or memory ID), but the output schema presumably covers that, and the complexity is moderate.
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% and each parameter has a meaningful description. The tool description adds context on the purpose of 'family' (deterministic verbatim register quoting) and 'filename' (provenance tag), but these details are already partly in the schema. The description does not add significant new semantic value beyond what the schema provides, so baseline 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 uses a specific verb ('Stores... into long-term persistent memory') and clearly identifies the resources (text, documents, code snippets, conversational facts). It distinguishes from siblings by explicitly noting that this is for ingestion, not querying, and references icx_recall_scoped and icx_search_facts as alternatives.
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?
Provides explicit guidance on when to use ('whenever you need to save facts, contracts, documentation, or user details') and when not to use ('Do not use for querying existing memory'), naming the alternative tools. This is a model example of usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resets conversational dialogue history for a session while strictly preserving all underlying crystallized knowledge, learned facts, and document weights in the memory space. Use when starting a new conversation topic while retaining all learned knowledge. Mutates session dialogue state but leaves persistent memory intact.
| Name | Required | Description | Default |
|---|---|---|---|
| space_id | No | Optional memory space partition whose turn history should be reset. Defaults to caller default space. |
| Name | Required | Description |
|---|---|---|
| status | Yes | description=Reset status (SESSION_RESET_SUCCESS) |
| space_id | Yes | description=Target memory space partition |
| session_cleared | Yes | description=Whether dialogue turns were cleared |
| memory_crystallized_preserved | Yes | description=Strictly true - underlying lattice memory is preserved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give readOnlyHint: false, indicating a mutation. The description goes beyond this by specifying exactly what is mutated (session dialogue) and what is preserved (crystallized knowledge, facts, weights). It adds valuable context about the side-effect scope, though it does not cover potential edge cases like timeouts or effects on concurrent sessions.
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 terse sentences plus a usage directive. The core action is front-loaded ('Resets conversational dialogue history'), followed by the preserving qualifier and the usage scenario. No filler or redundancy; every clause 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?
Given the tool's simplicity (one optional param, no required fields) and the presence of an output schema, the description covers purpose, side effects, and usage context. It does not describe the return value, but the output schema covers that. Minor omission: it doesn't explain what happens if the space_id is invalid or if resets affect multiple sessions, but these are not essential for basic usage.
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 sole parameter space_id with a clear description ('Optional memory space partition whose turn history should be reset. Defaults to caller default space.'). The tool description adds no additional meaning about the parameter beyond what the schema provides. With 100% schema coverage, baseline 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 clearly states the verb ('Resets') and the resource ('conversational dialogue history') while adding a critical qualifier: it preserves all crystallized knowledge and memory weights. This distinguishes it from siblings like icx_search_facts or icx_recall_scoped, which interact with long-term memory rather than session state. The final sentence reinforces the specific scope of the mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a when-to-use scenario: 'Use when starting a new conversation topic while retaining all learned knowledge.' It also clarifies what is not reset (persistent memory). However, it does not explicitly name alternative tools (e.g., 'for full memory reset, use X') or state when not to use it, so it's slightly below the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches memory lattice nodes and decoded facts by keyword overlap and proximity across the active memory space. Use this tool for entity exploration or keyword discovery. For natural language question answering with grounded factual citations, use icx_recall_scoped instead. Read-only with no side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of node matches to return (default: 20, min: 1, max: 100). | |
| query | Yes | Search terms or entity names to search across memory nodes. | |
| space_id | No | Optional memory space partition to search within. Defaults to caller default space. |
| Name | Required | Description |
|---|---|---|
| count | Yes | description=Number of matching nodes found |
| query | Yes | description=Search keyword query |
| status | Yes | description=Search status |
| matches | Yes | description=Simplicial complex nodes matching search query |
| space_id | Yes | description=Target memory space partition |
| total_in_space | Yes | description=Total nodes in active memory space |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint: true. The description reinforces this by stating 'Read-only with no side effects,' which adds explicit language beyond the annotation. It does not contradict the annotation and gives a clear behavioral statement about the tool's non-mutating nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, usage guidance, and read-only note. It is front-loaded with the core action and immediately distinguishes from a sibling, with no redundant or extraneous wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and readOnlyHint annotation, the description covers the essential context: purpose, usage, alternative, and side-effect statement. It omits details like ordering or match thresholds, but these are not critical given the schema richness. Slight room for improvement in describing result semantics, but overall complete.
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%, so all parameters are already described. The description adds minimal extra value, only reiterating that query terms are for entity names and keyword discovery, which is largely already in the schema. The baseline of 3 is appropriate since the schema carries the parameter semantics.
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 explicitly states the tool searches memory lattice nodes and decoded facts via keyword overlap and proximity, covering both resource and method. It also distinguishes itself from a sibling (icx_recall_scoped) by contrasting its use case, making the purpose 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 provides explicit guidance: 'Use this tool for entity exploration or keyword discovery' and 'For natural language question answering with grounded factual citations, use icx_recall_scoped instead.' This clearly indicates when to use and when not to use, with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0icx_quote_slot1 field changedInput schema / properties / space_id / descriptionPrevious value: -"Optional memory space partition where the family was stored."New value: +"Optional memory space partition where the family was stored. Defaults to caller default space."icx_recall_scoped4 fields changedInput schema / properties / space_id / descriptionPrevious value: -"Optional memory space partition to restrict recall to."New value: +"Optional memory space partition to restrict recall to. Defaults to caller default space."Input schema / properties / top_k / descriptionPrevious value: -"Maximum number of grounded facts to retrieve (default: 10, max: 50)."New value: +"Maximum number of grounded facts to retrieve (default: 10, min: 1, max: 50)."Output schema / properties / factsAdded value: +{
+ "description": "description=List of recalled grounded facts and citations",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Output schema / requiredPrevious value: -[
- "status",
- "query",
- "space_id",
- "count",
- "total_in_space"
-]New value: +[
+ "status",
+ "query",
+ "space_id",
+ "count",
+ "facts",
+ "total_in_space"
+]icx_remember2 fields changedInput schema / properties / filename / descriptionPrevious value: -"Optional filename or document title provenance tag (e.g. 'architecture.md', 'master_service_agreement.pdf')."New value: +"Optional filename or document title provenance tag (e.g. 'architecture.md', 'master_agreement.pdf') to track document origin."Input schema / properties / space_id / descriptionPrevious value: -"Optional memory space partition (e.g. 'codebase_docs', 'contracts_v2', 'user_preferences'). Defaults to caller's default space."New value: +"Optional memory space partition (e.g. 'codebase_docs', 'contracts_v2', 'user_preferences'). Defaults to caller default space."icx_reset_session1 field changedInput schema / properties / space_id / descriptionPrevious value: -"Optional memory space partition whose turn history should be reset."New value: +"Optional memory space partition whose turn history should be reset. Defaults to caller default space."icx_search_facts3 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of node matches to return (default: 20)."New value: +"Maximum number of node matches to return (default: 20, min: 1, max: 100)."Input schema / properties / query / descriptionPrevious value: -"Search terms or entity names to search across simplicial lattice nodes."New value: +"Search terms or entity names to search across memory nodes."Input schema / properties / space_id / descriptionPrevious value: -"Optional memory space partition to search within."New value: +"Optional memory space partition to search within. Defaults to caller default space."v0.1.0icx_inspect_spaceicx_quote_sloticx_recall_scopedicx_remembericx_reset_sessionicx_search_factsEach tool has a clearly distinct purpose: monitoring vs. exact quoting vs. semantic recall vs. storing vs. session reset vs. keyword search. The descriptions explicitly cross-reference each other to prevent misselection.
All tool names follow a consistent 'icx_verb_noun' pattern using lowercase with underscores, making the action and object predictable (e.g., icx_recall_scoped, icx_search_facts).
Six tools is well-scoped for a memory management server, covering storage, retrieval (semantic, exact, keyword), monitoring, and session control without bloat or redundancy.
The surface covers core memory operations (store, retrieve, monitor, reset) but lacks explicit delete or update functionality for persisted facts, which is a minor gap for a memory domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Universal persistent memory and knowledge retrieval layer for AI agents and LLMs.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Shared long-term memory for AI agents: save and recall context as a searchable knowledge graph.
Persistent memory for AI agents — verbatim conversations, searchable by meaning.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Calera-Labs/icx-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
