Ragionex Memory MCP

Official

by ragionex

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.1
Disambiguation5/5
Each 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.4/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![memory-mcp MCP server](https://glama.ai/mcp/servers/ragionex/memory-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ragionex/memory-mcp)

Score Badge

Copy to your README.md:

[![memory-mcp MCP server](https://glama.ai/mcp/servers/ragionex/memory-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ragionex/memory-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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