Universal persistent memory layer and knowledge retrieval engine for AI agents across Claude Code, Cursor, VS Code, and OpenClaw.
MCP-Native Persistence: Capture and recall decisions, architectural notes, and solutions across sessions.
Benchmarked 73% LoCoMo Accuracy: Built on Memwyre's hybrid dense-vector, BM25, and cross-encoder reranking architecture.
Cross-Tool Continuity: Share identical memory across your entire developer toolchain.
Fast & Lightweight: Direct cloud API integration with sub-second retrieval.
Related MCP server: Mnemoverse Memory
search_memwyre(query: str, limit: int = 5): Semantic search over saved memories and notes.
save_memory(content: str, tags: list, title: str): Ingest facts and solutions into your vault.
list_memories(limit: int = 10, skip: int = 0): Browse recent entries.
get_document(document_id: int): Retrieve complete document content.
Generate an API key from your Memwyre Dashboard.
export MEMWYRE_API_KEY="bv_sk_your_api_key_here"mcp.json / claude_desktop_config.json){
"mcpServers": {
"memwyre": {
"command": "uvx",
"args": ["mcp-memwyre"],
"env": {
"MEMWYRE_API_KEY": "bv_sk_your_key_here"
}
}
}
}{
"mcpServers": {
"memwyre": {
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "MEMWYRE_API_KEY=bv_sk_your_key", "ghcr.io/memwyreai/mcp-memwyre"]
}
}
}{
"mcpServers": {
"memwyre": {
"url": "https://api.memwyre.tech/mcp",
"headers": {
"Authorization": "Bearer bv_sk_your_key_here"
}
}
}
}Apache-2.0
Retrieve the full content of a specific document or memory by its ID.
Args:
document_id: The integer ID of the document to retrieve.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a read-like behavior through 'Retrieve' and sets return expectations with 'full content'. It does not mention error behavior, not-found cases, or permission requirements, but for a simple get-by-ID tool this is minimally adequate.
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 compact and front-loaded with the core action, followed by a brief Args listing. The Args section is slightly redundant with the schema property name, but it earns its place by adding semantic context that the schema lacks. 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?
Given the tool's simplicity—one required parameter and an output schema that can communicate return structure—the description is nearly sufficient. Missing context includes explicit guidance on where the ID comes from (e.g., list_memories) and what happens for invalid IDs. These are minor but real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must define document_id. It does so clearly: 'The integer ID of the document to retrieve.' This adds meaning beyond the schema's bare type/title by explaining that the parameter is the identifier of the target resource.
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 action and resource: 'Retrieve the full content of a specific document or memory by its ID.' It also uses a retrieval-by-ID mechanism that clearly distinguishes it from sibling tools like search_memwyre, list_memories, and save_memory.
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 usage context is implied: the agent should call this when it has an ID and needs the full content, rather than searching, listing, or saving. However, the description does not explicitly name alternatives or state when not to use this tool, so the guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent memories and notes from your Memwyre vault.
Args:
limit: Number of memories to return (default 10).
skip: Offset for pagination (default 0).
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. The verb 'List' reasonably implies a read-only operation, and 'recent' hints at ordering, but the description does not disclose sorting semantics, pagination behavior beyond the skip parameter, or what exactly is returned. It is adequate for a simple list operation 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 very short, front-loaded with the tool's purpose, and every sentence adds value. The parameter documentation is compact and immediately useful. There is no redundant or filler content.
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 two-optional-parameter listing tool, the description is mostly complete: purpose, parameters, and defaults are covered, and an output schema exists so return values need not be described. However, it lacks any guidance on choosing between list_memories and the sibling search tool, and it does not clarify what 'recent' means in terms of ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must document the parameters. It does so concisely: 'limit' is described as the number of memories to return and 'skip' as offset for pagination, adding practical meaning beyond the schema's bare types and defaults. This largely compensates for the missing schema descriptions.
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 action ('List') and the resource ('recent memories and notes from your Memwyre vault'). It is specific enough to understand the tool's core function, but it does not explicitly differentiate itself from the sibling tool search_memwyre, leaving some ambiguity about when listing is preferred over searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use list_memories versus search_memwyre, save_memory, or get_document. The description implies a simple listing use case but offers no exclusions, prerequisites, or conditions that would help an agent choose between this and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a new memory snippet, note, bug fix, or architecture decision to your Memwyre knowledge vault.
Args:
content: The technical content, note, pattern, or decision to save.
tags: Optional list of tags for organization (e.g. ['architecture', 'auth', 'database']).
title: Optional title for the memory note.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| title | No | ||
| content | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly indicates a persistent write operation ('Save ... to your vault') and describes the types of content to store. It does not disclose potential side effects, idempotency, or permission requirements, but for a simple create operation the essential behavior is conveyed.
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 and well-structured. The purpose is front-loaded in the first sentence, followed by a compact Args section that lists each parameter with a brief explanation. No redundant words or markdown overhead.
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 write tool with one required parameter and an output schema, the description covers the purpose, target vault, and all parameters. The sibling tools are clearly distinct, and nothing else is needed for an agent to invoke this 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?
Schema description coverage is 0%, so the description must compensate. It explains all three parameters meaningfully: content ('technical content, note, pattern, or decision'), tags ('Optional list of tags for organization' with an example), and title ('Optional title for the memory note'). This adds substantial value beyond the raw 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 states a specific verb ('Save') and a concrete resource ('memory snippet, note, bug fix, or architecture decision') with a clear destination ('Memwyre knowledge vault'). This clearly differentiates it from the sibling tools, which are all read/search 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?
Usage guidance is implied through the verb 'Save' and the obvious contrast with sibling names (search_memwyre, list_memories, get_document), but the description does not explicitly state when to use this tool over alternatives or include any exclusions. The intent is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search your Memwyre knowledge base and persistent memories using hybrid semantic search.
Args:
query: The natural language search query or topic to look up.
limit: Maximum number of relevant memories to return (default 5).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does convey that the tool performs hybrid semantic search and returns up to 'limit' relevant memories, but it does not explicitly state side-effect-free behavior, result ordering, or any access constraints. For a read-oriented search tool this is adequate but thin.
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 compact and well-organized: a single purpose statement followed by a minimal Args block. Every sentence contributes meaning, and the core action is stated first. No filler or redundant text is present.
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 is simple with two parameters and an output schema, so extensive return-value documentation is not required. The description covers the core purpose and both parameters adequately. It lacks explicit routing to sibling tools or note about behavioral nuances, but for a lightweight search operation it is largely 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 0%, so the description is the only source of parameter meaning. It explains 'query' as a natural language search query or topic, and 'limit' as the maximum number of memories to return, including its default. This adds real value beyond the raw schema, though it could provide more detail on constraints or examples.
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 and resource: 'Search your Memwyre knowledge base and persistent memories using hybrid semantic search.' This explicitly distinguishes the tool from siblings like save_memory, list_memories, and get_document by indicating query-based retrieval rather than saving, listing, or fetching a specific document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a natural-language query is needed to find relevant memories. However, it offers no explicit comparison to alternatives, such as using list_memories to browse all memories or get_document to retrieve a known document. Usage context is present but not elaborated, so it falls at 'implied usage' rather than clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_documentlist_memoriessave_memorysearch_memwyreEach tool has a fairly clear role: search finds relevant memories, list shows recent ones, get retrieves by ID, and save creates new content. Some minor overlap exists between search and list for locating memories, but the descriptions make the distinction workable.
Most tools follow a verb_noun pattern (save_memory, list_memories, get_document), but search_memwyre breaks the pattern by using the product name instead of a noun like 'memories'. There is also mild inconsistency between 'memory' and 'document' as the noun for the same underlying resource.
Four tools is a well-scoped size for a personal knowledge vault server. Each tool covers a distinct core operation—save, search, list, and get—without unnecessary bloat.
The server covers create and read workflows well, including semantic search, but it lacks update and delete operations for memories or documents. This is a noticeable gap in lifecycle coverage, though simple note-taking use cases can still succeed.
Portable memory for AI agents: capture once, recall across Claude, Cursor, and any MCP client.
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/memwyreai/mcp-memwyre'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
