Provides persistent memory across Codex and ChatGPT (via Apps SDK) sessions, enabling AI agents to recall information across sessions and projects.
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., "@Ragionex Memory MCP Remember I never use AWS, only Cloudflare Workers."
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.
Persistent memory for your AI agents. Tell it once - every session, every project, every tool remembers.
Your AI agent forgets everything between sessions. A month later, so do you.
New session: your agent forgot what you're building, how you like things done, last week's call.
Weeks later: you can't remember why you decided that either.
New agent: blank slate, all over again.
So you explain it all over again. Every. Single. Time.
Ragionex Memory remembers - so neither of you has to. Decisions, preferences, dead-ends: captured as you work, surfaced the instant they are relevant. It is an MCP server - one API key, the same memory in Claude Code, Claude Desktop, Codex, ChatGPT (Apps SDK), Cursor, Cline, and 500+ MCP clients.
And it is honest by design: when nothing matching is saved, it says so. It never fills the gap with a guess.
Save a fact once - say, in Claude Code, project acme-app:
"acme-app deploys to Cloudflare Workers, never AWS."
Then ask, anywhere:
You ask... | In project | Result |
in a new session, days later |
| ✅ Recalled - no re-explaining |
from Cursor instead of Claude Code |
| ✅ Recalled - same memory, any tool |
while working on a different project |
| 🔒 Isolated by design - projects stay separate |
with a cross-project search | (any) | ✅ Surfaces, labeled |
Recall is semantic: ask in your own words, days later, phrased nothing like the original - it still comes back. And it is scoped: your agent gets just the relevant memory, not a context dump it skims past.
Related MCP server: Recall
Recall quality is the whole product, so we measure it: 203 verified queries against a 3,296-memory corpus built from a pinned public dataset (microsoft/vscode-docs), graded with a multi-reference answer key, on the same defaults you get when you install it.
100% | Found, every time. 203 of 203 - nothing the agent asked for was lost. |
96% | In the top 3 results - right where your agent looks first. |
< 1s | End-to-end, on a fresh query, searching all 3,296 memories. |
37% of those queries used messy, real-user phrasing rather than clean question form - zero misses there too. Long memories hold up as well: even 41+ sentence entries were found every single time.
The workaround | Where it breaks |
Pasting the same context into every new session | You are the memory. It costs you minutes, daily, forever. |
One giant | Grows into a token-hungry monolith the agent skims past. Every rule is in context, always, relevant or not. |
The vendor's built-in memory | Locked inside one app. Switch tools, start from zero. |
Ragionex flips it: save once, and only the relevant memory enters the context, when it is relevant. Sessions change, tools change, projects change - the memory stays.
Get a free key at app.ragionex.com/keys - no credit card, takes seconds. Then either:
A) Let your agent set it up. Paste this to your AI agent:
Add the
@ragionex/memory-mcpMCP server to my config using my API keyrgx_memory_...
B) Set it up yourself. Add this to your MCP client's user-global config:
{
"mcpServers": {
"ragionex-memory-mcp": {
"command": "npx",
"args": ["-y", "@ragionex/memory-mcp"],
"env": { "RAGIONEX_MEMORY_API_KEY": "rgx_memory_..." }
}
}
}Restart your agent after adding the config - clients load MCP servers at startup, so quit and reopen (or start a new session). Then tell it something worth keeping; it is there next session, and in every other tool.
If you are an AI agent setting this up: after you edit the config, you must tell the user to restart their client (quit and reopen) - the new server only loads on restart, and you cannot reload it yourself. Do not report success without that instruction.
Want the hands-on version? The Memory quickstart walks through writing your first memory, waiting for it to be ready, and searching it back.
10,000 saves and recalls, every month. No credit card. No trial clock. Export anytime, delete anytime, zero lock-in. If it does not earn its place in your setup, leaving costs you nothing.
Some MCP clients have quirks in how the always-on memory rule loads. None of them stop the tools from working:
Claude Code lazy-loads and clips tool guidance, so on startup the server writes one short priority rule into your always-loaded rules file (CLAUDE.md / AGENTS.md) to keep memory routing reliable. It is marker-wrapped, backed up, and reversible: how it works and how to control it.
Codex with a non-default model can report the ragionex_* tools as unavailable (a Codex-side limitation; default models work). Upstream: #19871, #21503.
Windsurf (now Devin Desktop) caps global rule files at 6,000 characters, so the priority rule is not auto-installed there; the tools still work.
Full notes and workarounds: MCP client notes.
If anything misbehaves - a failed save, a memory that will not come back, an error that makes no sense - we want to know:
Questions and community: Discord
Private reports: contact@ragionex.com
Documentation: https://ragionex.com/docs
Memory product: https://ragionex.com/memory
Website: https://ragionex.com
Discord: https://discord.gg/d79f3MDVd4
Email: contact@ragionex.com
MIT
Permanently delete one or more memories. This is irreversible: all stored data for that memory is removed. Returns the count of deleted memories.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Memory IDs to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint, but the description adds meaningful context: deletion is irreversible, all stored data is removed, and the count of deleted memories is returned. This goes beyond the structured metadata.
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 sentences with no filler. It immediately communicates the action, consequence, and return value, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with comprehensive annotations, the description covers behavior (delete), irreversibility, all-data removal, and the return format. No output schema exists, but the return value is stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the 'ids' parameter (100% coverage), so the description adds little parameter-level meaning. 'One or more' mirrors the minItems constraint and does not introduce new 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?
Description uses the specific verb 'delete' with the resource 'memories', explicitly states 'one or more', and clearly differentiates from sibling tool delete_memory_project by targeting memories directly.
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?
Intent to delete is clear from the title and description, but it does not explicitly state when to use this tool versus alternatives like update_memory or delete_memory_project. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DESTRUCTIVE: permanently delete a project AND every memory inside it. All memories labelled with this project name are removed along with their stored data. This is irreversible. Use ragionex_delete_memory (with explicit IDs) when only some memories should be removed. Returns the count of memories deleted.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Project name to delete. EVERY memory in this project will be permanently removed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though destructiveHint=true is annotated, the description adds crucial behavioral context: all memories labelled with the project name are removed, the operation is irreversible, and it returns the count of deleted memories. This goes beyond the annotation and informs the agent of consequences and return behavior.
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 succinct and front-loaded with 'DESTRUCTIVE', then covers scope, irreversibility, alternative usage, and return value in just three sentences. Every sentence provides essential information without waste.
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?
With a single parameter, annotations, and no output schema, the description covers all essential aspects: purpose, destructive scope, irreversibility, alternative tool, and return value. It is fully sufficient for this tool's complexity.
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%, and the schema's parameter description already explains the 'name' parameter and its destructive implication. The description reinforces but does not add additional syntax or format details, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes an entire project AND every memory inside it, using a specific verb (delete) and resource (project). It also distinguishes itself from sibling ragionex_delete_memory by noting the alternative for partial deletion, 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?
Explicit guidance is provided: use this tool when deleting an entire project, and use ragionex_delete_memory with explicit IDs when only some memories should be removed. This directly addresses when vs. when-not, and names the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List memories with previews and processing status, ordered by most recently created. Use this to BROWSE what is stored when there is no specific topic to search for - especially when the user asks 'what did I save last week?', 'show me April memories', or any time-window-only request. Parameters: optional project (slug), optional start_date and end_date (ISO 8601: 'YYYY-MM-DD' or 'YYYY-MM-DDTHH:MM:SSZ'), optional limit (most recent first, default 50). See the priority rule (in CLAUDE.md, injected by the server) for the LIST vs RECALL decision (topic -> recall, no topic -> list) and the EXACT-vs-VAGUE date rule. For full content of specific IDs, use ragionex_view_memory.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum memories to return, most recent first. Default 50. When the account holds more than this, the output says how many were omitted - narrow with project/date filters or raise the limit. | |
| project | No | Optional project filter. Omit to list memories across all projects. | |
| end_date | No | Optional inclusive upper bound for memory creation date. ISO 8601: 'YYYY-MM-DD' (end-of-day UTC) or 'YYYY-MM-DDTHH:MM:SSZ'. Set ONLY for exact, calendar-anchored time references; omit for vague time. | |
| start_date | No | Optional inclusive lower bound for memory creation date. ISO 8601: 'YYYY-MM-DD' (start-of-day UTC) or 'YYYY-MM-DDTHH:MM:SSZ'. Set ONLY for exact, calendar-anchored time references; omit for vague time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, open-world, idempotent, non-destructive behavior. The description adds that results include previews and processing status (not full content) and are ordered by recency, plus references the exact-vs-vague date rule. This goes beyond the structured metadata without over-claiming.
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 front-loaded with the core function, then usage examples, then parameter summary, then cross-references. Each sentence serves a distinct purpose; it is slightly longer than minimal but well-organized and appropriately scoped for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a browse/list tool with no output schema, the description covers purpose, ordering, parameter semantics, and points to the relevant decision rules and sibling tools. It could specify the exact return fields, but the mention of previews and processing status suffices given the context signals.
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% with detailed descriptions for all four parameters. The description summarizes them (slug, ISO 8601, default limit) but adds little beyond what the schema already documents. A baseline 3 is appropriate because the schema carries the semantic load.
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 clear verb+resource+scope: 'List memories with previews and processing status, ordered by most recently created.' It explicitly contrasts with siblings such as ragionex_recall_memory (topic-based search) and ragionex_view_memory (full content), making its 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?
Gives explicit when-to-use guidance: browse when there is no specific topic, with concrete example queries ('what did I save last week?'). It also points to the LIST vs RECALL priority rule and directs users to ragionex_view_memory for full content, covering alternatives and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every project that exists on this account, with the memory_count per project (sorted alphabetically). Use this to discover which project labels are in use before calling ragionex_list_memories, ragionex_recall_memory, ragionex_rename_memory_project, or ragionex_delete_memory_project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds value by detailing the return content (memory_count per project) and alphabetical sorting, plus the purpose of label discovery. It does not mention pagination or rate limits, but for a simple list this is acceptable.
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, information-dense sentences. The first states the action and output specifics, the second provides usage context and related tools. No wasted words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool, the description is complete: it specifies the function, output elements, sorting, and a clear use case. Even without an output schema, it conveys the essential return information.
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 tool has zero parameters, so parameter semantics are inherently unobstructed. The description and schema need no further elaboration, and the baseline for 0-param tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all projects on the account with memory_count per project, sorted alphabetically. It distinguishes itself from siblings by specifying that it serves to discover project labels before using related tools.
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 instructs to use this tool before calling ragionex_list_memories, ragionex_recall_memory, ragionex_rename_memory_project, or ragionex_delete_memory_project, providing clear when-to-use guidance and naming specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current processing status of a memory. Returns 'processing' (still being prepared), 'ready' (available), or 'failed' (an error occurred during processing). Use after ragionex_save_memory to know when ragionex_recall_memory will return the new memory.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Memory ID to check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior semantics by explaining the three statuses and their meaning, which goes beyond the annotations. It does not mention polling behavior or error handling, but the added context is sufficient given the tool's simplicity.
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 sentences, front-loaded with the primary action, and every word earns its place. It avoids redundancy and clearly communicates the key information without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple polling tool with one parameter, complete annotations, and no output schema, the description provides enough context: it explains the return values and how the tool fits into the memory workflow. No significant gaps remain.
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%: the 'id' parameter is described as 'Memory ID to check.' The description does not add further parameter-level detail, but none is needed since the schema fully specifies the parameter. Baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the current processing status of a memory.' It enumerates the possible return values ('processing', 'ready', 'failed'), which both specifies the verb+resource and distinguishes it from sibling tools that save, recall, list, or delete memories.
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 usage context: 'Use after ragionex_save_memory to know when ragionex_recall_memory will return the new memory.' This tells the agent when to call the tool relative to its siblings. It does not explicitly state when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search memories in ragionex-memory-mcp by semantic similarity. queries is an ARRAY of full QUESTION sentences (English, no time vocabulary) - full questions match far better than keyword fragments. ALWAYS send 2-3 different phrasings of the topic as separate array items (results are merged + deduped server-side, so extras only help) - never a single bare keyword. Other params: optional project, optional start_date / end_date (ISO 8601 'YYYY-MM-DD' or 'YYYY-MM-DDTHH:MM:SSZ'). The priority rule (in CLAUDE.md, injected by the server) defines full RECALL semantics: the 2-3-question rule, the EXACT-vs-VAGUE date rule, time-stays-out-of-queries. For a time window with no topic, use ragionex_list_memories instead. Returns ranked matches.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Optional project filter - a precision tool, not a generic narrowing knob (same logic as the date filter). Set it ONLY when the question is explicitly project-scoped: the user names a project, or asks about the current codebase's own code or decisions. For vague, general, or personal questions (the user's preferences, identity, anything spanning projects), OMIT it and search across all projects - an auto-guessed project filter hides relevant matches in 'general' and other projects, exactly like a guessed date range. Never pass 'general' as the filter: it is a save label, not a search scope, and would exclude every other project. | |
| queries | Yes | 1-5 full QUESTION sentences about the topic, one per array item. ALWAYS send 2-3 phrasings, never a single item, and NEVER bare keywords - full questions match far better than keyword fragments. DO: ['what is the user\'s preferred editor?', 'which IDE does the user use?', 'what development environment has the user chosen?']. AVOID: ['user editor'] (keywords, weak match). For several independent topics, give each its own 2-3 questions within the 5-item cap. Time references (week, month, last, since, dates) MUST NOT appear here - they go in start_date / end_date. If there is no topic at all (only a time window), use ragionex_list_memories instead. | |
| results | No | Maximum number of results to return, merged across all questions. Default 10 is a good general fit; raise for broader recall, lower for tight focused recall. | |
| end_date | No | Optional inclusive upper bound for memory creation date. ISO 8601: 'YYYY-MM-DD' (end-of-day UTC) or 'YYYY-MM-DDTHH:MM:SSZ'. Omit for no upper bound. Set ONLY for exact, calendar-anchored time references. | |
| start_date | No | Optional inclusive lower bound for memory creation date. ISO 8601: 'YYYY-MM-DD' (start-of-day UTC) or 'YYYY-MM-DDTHH:MM:SSZ'. Omit for no lower bound. Set ONLY for exact, calendar-anchored time references. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent, and non-destructive. The description adds meaningful behavioral context: 'results are merged + deduped server-side,' 'extras only help,' and 'Returns ranked matches,' going beyond what annotations state. 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?
The description is front-loaded with the purpose and is information-dense, but slightly long and references an external 'CLAUDE.md' rule. Every clause earns its place, though a minor trim could improve readability.
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 five-parameter schema and no output schema, the description covers purpose, query construction, date handling, project filtering, and an alternative tool. It provides sufficient context for an agent to invoke correctly.
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 baseline is 3. The description mentions parameter names and the query format but largely repeats schema content; it does not add materially new parameter-level semantics beyond what the schema already provides.
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 and resource: 'Search memories ... by semantic similarity,' clearly identifying a search/recall operation. It also distinguishes from sibling tools by explicitly routing time-window-no-topic cases to ragionex_list_memories.
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 when-to-use guidance: 'ALWAYS send 2-3 different phrasings,' 'never a single bare keyword,' and 'For a time window with no topic, use ragionex_list_memories instead.' It also references the priority rule for recall semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a project: bulk-update every memory currently labelled 'name' to use 'new_name' instead. The source project must exist. Returns the number of memories that were re-labelled. If 'name' equals 'new_name', this is a no-op.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Current project name. Must already exist (call ragionex_list_memory_projects to verify). | |
| new_name | Yes | New project name. Lowercase alphanumeric and hyphens only, 1-50 chars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond annotations: it performs a bulk update of all memories under a project label, returns the count of re-labelled memories, and includes an edge-case no-op. Annotations only indicate mutation and open-world semantics, so this is valuable added context.
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, front-loading the action and then adding necessary details in two sentences. Every sentence earns its place: purpose, bulk behavior, prerequisite, return value, and no-op case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename tool, the description covers all essential context: what happens, prerequisites, return value, and edge case. No output schema exists, so the description properly takes on the responsibility of explaining the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (name must exist, new_name format). The description adds a bit of nuance by clarifying the bulk-update behavior tied to 'name', but it mostly reiterates schema information. 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 tool's action ('Rename a project') and specifies the exact operation: bulk-update every memory labelled 'name' to 'new_name'. It distinguishes itself from siblings like delete_memory_project by describing the rename behavior, and even notes the no-op condition.
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?
Clear context is provided: the source project must exist, and renaming to the same name is a no-op. While it does not explicitly name alternative tools for different scenarios, it implicitly guides usage by explaining the rename semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a durable fact, preference, or decision to ragionex-memory-mcp (cross-client persistent memory: Claude Desktop, Claude Code, Cursor, Cline, Codex, ChatGPT, Zed). Use for content that should persist across sessions and AI tools. Parameters: content (English; memories are stored in English), project (slugified ^[a-z0-9-]+$, e.g. 'general', 'acme-app'). The priority rule (in CLAUDE.md, injected by the server) defines the full write semantics: PROJECT LABEL inference, WHAT TO SAVE vs SKIP signals, LIFECYCLE replacement detection, and the WRITE RULES (atomic save: ONE fact per call, no bundling). Returns memory ID + status; async, use ragionex_memory_status to check readiness.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content to remember. Plain text, one focused fact per call. DO: 'The user prefers Fraunces for headings.', 'Decision: use 4-space indents in all Python files.', 'The user's deployment target is Cloudflare Workers, not Vercel.'. AVOID bundling unrelated facts in one entry like 'The user likes Fraunces AND prefers 4-space indents AND deploys to Cloudflare' -- save those as three separate memories so each one can surface independently in future searches. | |
| project | Yes | Project label, slugified `^[a-z0-9-]+$`. Only two kinds: the current project's folder name (cwd basename) for facts about this codebase, or 'general' for facts about the user or all projects. See the priority rule for details. Do not invent other labels and do not use the full path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=false and idempotentHint=false, but the description adds valuable behavioral context: the operation is async, returns memory ID + status, and requires checking ragionex_memory_status for readiness. It also discloses the 'atomic save: ONE fact per call, no bundling' rule and the normalization to English. This goes beyond the basic annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise enough, with the purpose front-loaded in the first sentence. It then covers usage context, parameter constraints, behavioral notes, and return semantics in a structured flow. Some redundancy with the schema exists, but every sentence still adds useful guidance; it's not bloated.
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 covers the core invocation aspects: what the tool does, when to use it, parameter constraints, the async behavior, and the need to poll with a sibling status tool. It references an external 'priority rule' for full write semantics, which is a slight gap but it explicitly names the key rule categories. Given the rich schema and annotations, this is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with extremely detailed descriptions for both parameters, including examples, slug patterns, and DO/AVOID rules. The tool description mostly re-summarizes this information, adding only a small extra detail that memories are 'stored in English'. Since the schema already does the heavy lifting, the description adds minimal new meaning 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 opens with a specific verb+resource: 'Save a durable fact, preference, or decision to ragionex-memory-mcp'. It clearly states the action and the destination, and further clarifies the persistence scope ('cross-client persistent memory'). It implicitly differentiates from siblings by being the write-capture tool versus recall/list/view/update/delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use for content that should persist across sessions and AI tools.' It also gives usage constraints like 'memories are stored in English' and 'atomic save: ONE fact per call', plus points to the priority rule for WHAT TO SAVE vs SKIP signals. It does not explicitly name alternatives or when-not-to-use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the content or move to a different project for an existing memory. Provide at least one of content or project. Updating content reprocesses the memory (status returns to 'processing' until reprocessing finishes).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Memory ID to update. | |
| content | No | New content. Omit to keep existing content. | |
| project | No | New project. Omit to keep existing project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as non-read-only and non-idempotent, and the description adds a concrete side effect: 'Updating content reprocesses the memory (status returns to processing until reprocessing finishes).' This provides behavioral context beyond the structured hints, though it does not disclose return values or error behavior.
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 short sentences: what the tool does, the invocation requirement, and the key behavioral consequence. It is front-loaded with the primary purpose and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter update tool with no output schema, the description covers the core operation, the 'at least one' constraint, and the reprocessing side effect. Minor gaps remain around the return value and what happens if the ID does not exist, but these are not exposed in the schema and do not undermine tool selection.
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 already describes all three parameters, so the baseline is 3. The description adds value by stating the cross-field constraint 'Provide at least one of content or project,' which is not expressed in the schema's required list. It also links the content parameter to the reprocessing behavior.
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 'Replace the content or move to a different project for an existing memory,' specifying the verb and resource scope precisely. This clearly distinguishes update from save (new memory), recall, delete, and project-rename siblings.
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 phrase 'for an existing memory' and 'Provide at least one of content or project' imply that the tool is for modifying an existing memory, but no explicit alternatives or when-not-to-use exclusions are provided. Sibling tools like save_memory and rename_memory_project are not mentioned, leaving usage guidance only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve full original content for one or more memory IDs. Use this when ragionex_list_memories or ragionex_recall_memory returned a preview and you need the complete content. Non-owned IDs are silently skipped.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Memory IDs to fetch. Get IDs from ragionex_list_memories or ragionex_recall_memory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive hints. The description adds valuable behavioral context beyond annotations by disclosing that non-owned IDs are silently skipped, which is not implied by the schema or annotation hints. This is useful but only one additional behavioral trait.
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, front-loaded with the core purpose. Each sentence serves a distinct role: what it does, when to use it, and a non-obvious behavioral caveat. No wasted 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?
For a simple one-parameter tool with strong annotations and a fully described schema, the description is complete. It covers purpose, usage context, and the only non-obvious behavior (silent skipping of non-owned IDs). No output schema exists, but no return value explanation is necessary given the straightforward 'retrieve full content' semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single 'ids' parameter fully documented in the input schema (type, min/max length, min/max items, and source from list/recall tools). The description adds no parameter-specific details beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Retrieve full original content for one or more memory IDs.' It clearly distinguishes this from sibling tools by noting that list_memories and recall_memory return previews, while this tool returns full content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'when ragionex_list_memories or ragionex_recall_memory returned a preview and you need the complete content.' It also explains what happens with non-owned IDs ('silently skipped'), providing clear boundaries for expected behavior.
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.
v0.5.1ragionex_delete_memoryragionex_delete_memory_projectragionex_list_memoriesragionex_list_memory_projectsragionex_memory_statusragionex_recall_memoryragionex_rename_memory_projectragionex_save_memoryragionex_update_memoryragionex_view_memoryEach tool has a clearly distinct purpose: save creates a memory, recall searches semantically, list browses without a topic, view retrieves by ID, update modifies, delete removes, status checks async progress, and project tools manage projects. There is no meaningful overlap between any two tools.
All tools use the ragionex_ prefix and most follow a verb_noun pattern (save_memory, recall_memory, list_memories, view_memory, update_memory, delete_memory). The one outlier is memory_status, which is noun_verb instead of verb_noun, and list_memories uses a plural where others use singular, but the overall pattern is predictable.
10 tools is well-scoped for a memory management server: it covers CRUD, semantic search, async status, and project-level operations. Each tool has a clear role and none feel redundant or excessive.
The tool set provides complete lifecycle coverage: create (save), read (recall/list/view), update, delete, plus status tracking and project management. There are no obvious missing operations; projects can be created implicitly via save, and rename/delete provide bulk management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Long-term memory for AI assistants. Isolated per-user storage, recall across conversations.
Memory system for AI agents with semantic search. Store and recall memories with ease.
Persistent AI memory with semantic search, conflict detection, and ticketing.
Persistent memory for AI agents. Search, store, and recall across sessions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ragionex/memory-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
