官方 Model Context Protocol (MCP) 连接器，适用于 Calera Labs Infinite Context (ICX)。将 AI 代理（Claude Desktop、Cursor、VS Code、Zed 以及自定义自主代理集群）直接连接到 Volumetric Lattice Network 上的持久化、次二次拓扑记忆。
"上下文无极限。记忆无丢失。"
零注意力扩散： 与其将数百万个 token 塞入密集注意力机制（模型在其中遭受"中间丢失"衰减），ICX 将知识结晶为永久的 $A_4$ 单纯复形晶格节点（icx_remember）。
2026-07-28 无状态协议核心： 完全符合 2026-07-28 无状态 MCP 规范（SEP-2243、SEP-2575、SEP-2549），支持亚 5 毫秒零握手的直接工具调用和智能缓存（ttlMs: 86400000）。
亚 5 毫秒范围召回： 测地线关联搜索通过紧凑的编号视口（icx_recall_scoped）返回经过验证的事实句和逐字引用。
基准测试溯源：
在 128k 上下文下的 RULER MRCR v2 上达到 96.28%（466/484 精确）。
在 LongBench v2 官方基准上达到 54.87%（276/503）。
跨上下文视口实现 51.98% 的噪声降低。
可流式托管端点： 无需本地模型下载。使用来自 dashboard.caleralabs.com 的 API 密钥，通过流式 HTTP/SSE 连接。
Related MCP server: Mnemexa MCP
将以下内容添加到项目的 .cursor/mcp.json（或全局 Cursor 设置 → 功能 → MCP）：
{
"mcpServers": {
"infinite-context": {
"url": "https://icx.caleralabs.com/mcp",
"headers": {
"X-License-Key": "clabs_live_YOUR_KEY",
"X-Space-ID": "default"
}
}
}
}（在 dashboard.caleralabs.com 获取免费 API 密钥）
添加到您的 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"
}
}
}
}使用 Smithery 在 Claude、Cursor 或 VS Code 中自动安装：
# 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 vscode添加到 .vscode/mcp.json：
{
"servers": {
"infinite-context": {
"url": "https://icx.caleralabs.com/mcp",
"headers": {
"X-License-Key": "clabs_live_YOUR_KEY"
}
}
}
}如果您的环境仅支持本地 stdio 子进程：
{
"mcpServers": {
"infinite-context": {
"command": "npx",
"args": ["-y", "@caleralabs/icx-mcp"],
"env": {
"ICX_LICENSE_KEY": "clabs_live_YOUR_KEY",
"ICX_SPACE_ID": "default"
}
}
}
}工具 | 用途 | 主要输入 | 行为 |
| 将文本、代码、决策和文档存储到持久化长期记忆中。 |
| 增量且非破坏性 |
| 跨记忆执行语义搜索，检索有依据的事实和用于 QA 的来源引用。 |
| 只读 |
| 跨记忆节点执行关键词和实体搜索，用于词法探索和 token 查找。 |
| 只读 |
| 从文档寄存器中检索逐字符精确的逐字文本和 SHA-256 哈希。 |
| 只读 |
| 返回诊断遥测数据：活动节点、总突触、已确认事实和矛盾警报。 |
| 只读 |
| 清除对话轮次历史，同时保留所有底层持久化记忆。 |
| 仅修改会话 |
为确保您的自主代理系统性地存储架构决策并召回真实上下文，请将此块添加到代理的系统提示中：
Store project decisions, architectural constraints, and key invariants in ICX using `icx_remember`.
Before answering historical codebase questions or resolving complex dependencies, use `icx_recall_scoped` to retrieve exact grounded facts.产品落地页： https://icx.caleralabs.com
交互式 MCP 文档： https://icx.caleralabs.com/mcp-docs
通用仪表板与密钥： https://dashboard.caleralabs.com
Calera FINSEC MCP： 面向 AI 代理的经认证 SEC EDGAR 金融记忆，具有 0.00% 统计幻觉率和加密文件溯源（Glama Hub · Smithery）。
Apache License 2.0。详情请参阅 LICENSE。由 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.
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_factsScored across 6 tools
Each 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.
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 and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
