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., "@MemoryPlugin MCP Server Search my memories for anything about the Johnson project"
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.
An MCP (Model Context Protocol) server for MemoryPlugin, enabling AI assistants like Claude to store and retrieve your memories. This server provides a bridge between AI assistants and your MemoryPlugin account, allowing them to:
Store new memories and organize them into buckets
Search your memories with hybrid semantic + keyword search
Browse Smart Memory categories and their summaries
Edit memories or move them between buckets
Recall your imported chat history from ChatGPT, Claude, and other AI tools
Read or summarize a specific past conversation
Fetch the full transcript of a past conversation as structured JSON for deeper analysis
Search documents you uploaded to MemoryPlugin
Find your API token in the dashboard
Copy the token for use in configuration
Configure the server in your Claude Desktop configuration file:
{
"mcpServers": {
"memoryplugin": {
"command": "npx",
"args": ["-y", "@memoryplugin/mcp-server"],
"env": {
"MEMORY_PLUGIN_TOKEN": "your-token-here"
}
}
}
}First, install the package globally:
npm install -g @memoryplugin/mcp-serverThen find your Node.js installation path:
which node
# Example output: /Users/username/.nvm/versions/node/v21.7.3/bin/nodeAnd find the installed package path:
npm root -g
# Look for something like: /Users/username/.nvm/versions/node/v22.14.0/lib/node_modulesAdd @memoryplugin/mcp-server/dist/index.js to the end of the path you received in the previous step.
So the final path should look like:
/Users/username/.nvm/versions/node/v22.14.0/lib/node_modules/@memoryplugin/mcp-server/dist/index.jsUse these paths in your configuration:
{
"mcpServers": {
"memoryplugin": {
"command": "/Users/username/.nvm/versions/node/v21.7.3/bin/node",
"args": [
"/Users/username/.nvm/versions/node/v21.7.3/lib/node_modules/@memoryplugin/mcp-server/dist/index.js"
],
"env": {
"MEMORY_PLUGIN_TOKEN": "your-token-here"
}
}
}
}If you experience any startup issues with Option 2, please use Option 1 with global installation instead.
Related MCP server: Simple Memory MCP
The MCP server exposes these tools to AI assistants:
store_memory — save a new memory, optionally into a specific bucket
search_memories — hybrid semantic + keyword search over your saved memories
get_memories_and_buckets — fetch recent or all memories (optionally by bucket) along with your bucket list
list_buckets — view all memory buckets with memory counts
create_bucket — create a new bucket to organize memories by topic
list_bucket_categories — list Smart Memory categories inside a bucket, each with a summary
list_category_memories — load the full memories of one Smart Memory category
update_or_move_memories — edit a memory's text, or move one or many memories to another bucket
recall_chat_history — search your imported past conversations across AI tools; supports parallel queries, token budgets, date bounds, and a quality mode
get_conversation_summary — AI-generated summary of one past conversation (needs 5,000+ tokens; for shorter chats use get_full_conversation)
get_full_conversation — the complete transcript of one past conversation
export_conversation — a temporary download URL (expires in 15 minutes, no auth needed) the assistant fetches to get one past conversation as a structured JSON file, for transcripts too long to read inline or destined for file-based processing
search_uploaded_files — search documents you uploaded to your MemoryPlugin file buckets
Here are some example prompts you can use with Claude once the server is configured:
Could you store this as a memory: "Had coffee with Sarah at Blue Bottle, discussed upcoming project deadlines"
Can you show me my latest 5 memories?
Could you create a new bucket called "Work Meetings"?
Search my memories for anything related to "coffee meetings"
Show me the categories in my main bucket
What did we decide about the pricing page? Check my past conversations.
Go through my whole conversation about the pricing redesign and pull out every action itemFor any issues or questions, please contact support@memoryplugin.com
MIT. See LICENSE.
Create a new bucket to organize memories. Buckets are folders like 'Work', 'Personal', 'Health'. Ask the user for a name if not specified.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the new bucket |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It discloses the core mutation behavior (creating a bucket) and the agent instruction to request a name if missing. However, it does not mention potential error cases (e.g., duplicate name) or what is returned, which is a gap for a mutation tool.
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 short sentences with no filler. The first sentence states the action and purpose, the second provides guidance and examples. It is front-loaded and efficient.
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 low complexity (single required parameter, no output schema, no nested objects). The description covers purpose, examples, and the required parameter well. It does not specify return value or duplicate handling, but for such a simple create operation, the description is reasonably 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 coverage is 100%, and the schema describes 'name' as 'Name for the new bucket.' The description adds valuable context by giving concrete examples ('Work', 'Personal', 'Health') and instructing the agent to ask the user for the name if not provided, which enriches the parameter semantics 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 clearly states the tool's function with a specific verb ('Create') and resource ('new bucket'), and distinguishes it from sibling tools like list_buckets or update_or_move_memories. The examples 'Work', 'Personal', 'Health' add clarity about what a bucket represents.
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 this tool (to organize memories into folders) and provides a key procedural guideline: 'Ask the user for a name if not specified.' It lacks explicit alternatives or exclusions, but the context is clear enough for the intended simple operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download the complete transcript of a past conversation as a machine-readable JSON file. Returns a temporary download URL (expires in 15 minutes, no auth needed) that you fetch yourself to get the full conversation as structured messages (role, content, timestamp).
Use when a transcript is too long to read inline, or when you need it as a file for analysis or scripting. To read a short transcript directly, use get_full_conversation instead. Requires the conversationId from recall_chat_history's sources array.
| Name | Required | Description | Default |
|---|---|---|---|
| conversationId | Yes | Conversation ID from the recall_chat_history sources array |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and does so thoroughly. It discloses that the tool returns a temporary URL (15-minute expiry), requires no auth to fetch, and that the agent must fetch the URL itself to obtain structured message data with role, content, and timestamp. This provides clear behavioral expectations beyond the schema.
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 first sentence front-loads the core action and result, the second paragraph provides contextual usage guidance. Every sentence adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description fully compensates by describing the return flow (temporary URL, expiry, fetch action, message structure). It also explains where to obtain the required input and how this tool relates to siblings, making it complete for agent decision-making.
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 fully describes the single parameter (conversationId) with the source from recall_chat_history. Since schema coverage is 100%, the description adds no additional semantic detail about the parameter format or behavior beyond what the schema provides, matching the baseline for well-covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Download the complete transcript') and clearly identifies the resource (past conversation as JSON). It distinguishes from sibling tools by explicitly referencing get_full_conversation for short transcripts, and sets scope ('complete transcript', 'machine-readable JSON file').
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 criteria: when transcript is too long to read inline or when a file is needed for analysis/scripting. Also states when not to use it and names the alternative, get_full_conversation, and gives the source of the required conversationId from recall_chat_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific past conversation. For short conversations (<5K tokens), returns the full transcript. For longer conversations, returns an AI-generated summary. Use when the user wants to dive deeper into a conversation returned by recall_chat_history. Requires the conversationId from that tool's sources array.
| Name | Required | Description | Default |
|---|---|---|---|
| conversationId | Yes | Conversation ID from the recall_chat_history sources array |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavioral traits: the transcript-vs-summary threshold and the requirement to use conversationId from recall_chat_history. It does not mention any potential side effects or permissions, but as a read operation, the description adequately conveys its safe nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, behavior, and usage context. It is front-loaded with the core action and contains no redundant information.
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?
Despite having no output schema, the description provides sufficient context for a single-parameter tool. It explains both possible response types (transcript or summary) and the source of the required ID. The main gap is lacking a description of the response structure, but this is not critical for tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameter completely with a description matching the tool description. The description adds no new meaning beyond that, so it meets the baseline of 3. No ambiguity exists about the parameter's purpose or source.
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 'Get details of a specific past conversation' with a specific verb and resource. It distinguishes itself from siblings by explaining the length-based behavior (full transcript vs AI summary) and explicitly references recall_chat_history as the source of the ID.
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 provides explicit when-to-use guidance: 'Use when the user wants to dive deeper into a conversation returned by recall_chat_history.' It also clarifies the conditional behavior based on token count. However, it does not explicitly state when not to use it or mention alternatives like get_full_conversation, so it lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete transcript of a specific past conversation. Returns all messages in the conversation without summarization. Use when you need the raw conversation content. Requires the conversationId from recall_chat_history's sources array.
| Name | Required | Description | Default |
|---|---|---|---|
| conversationId | Yes | Conversation ID from the recall_chat_history sources array |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds context that the tool returns all messages without summarization and requires the conversationId from a specific source. It does not explicitly state read-only behavior, side effects, or error handling, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each providing valuable information: what it does, when to use it, and the required parameter source. It is front-loaded and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool without an output schema, the description covers purpose, usage context, parameter origin, and return value ('all messages'). It could be more explicit about non-mutating behavior or failure cases, but overall it is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter description already states 'Conversation ID from the recall_chat_history sources array'. The tool description repeats this requirement but adds no new syntactic or format details 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 clearly states the verb 'Get', the resource 'complete transcript of a specific past conversation', and specifies 'all messages without summarization'. This distinguishes it from siblings like get_conversation_summary and recall_chat_history.
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 says 'Use when you need the raw conversation content' and indicates the prerequisite of obtaining conversationId from recall_chat_history. However, it does not explicitly mention when not to use it or name alternative tools, though the contrast with summary is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the user's saved memories from MemoryPlugin, optionally filtered by bucket. Also returns the list of available buckets.
Use to see what the user has previously saved. Consider using at conversation start if the user's query might benefit from their stored context.
| Name | Required | Description | Default |
|---|---|---|---|
| all | No | Whether to fetch all memories | |
| count | No | Number of memories to retrieve (default: 10) | |
| query | No | Optional search query | |
| latest | No | Whether to fetch only latest memories | |
| bucketId | No | Optional bucket ID to filter memories |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Retrieve' and phrase 'see what the user has previously saved' imply a read-only operation, which is adequate. However, it does not disclose any potential edge cases, rate limits, or effects of the optional parameters, leaving some behavioral aspects undocumented.
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, consisting of two sentences that front-load the core function and then provide usage guidance. Every word earns its place, with no unnecessary 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?
Given the tool's moderate complexity (5 optional parameters, no output schema), the description adequately states what is returned (memories and buckets) and when to use it. It does not describe return value structure, but the absence of an output schema makes that less critical. The schema covers parameter details, so the description is reasonably 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 coverage is 100%, so parameter descriptions are already present. The description only adds meaning for bucketId via 'filtered by bucket' but does not elaborate on all, count, query, or latest. This aligns with the baseline of 3, as the schema handles most parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the user's saved memories and available buckets, with optional filtering by bucket. This specific verb+resource phrasing distinguishes it from siblings like search_memories and list_buckets by combining both functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Use to see what the user has previously saved' and suggests using it at conversation start. However, it does not explicitly mention alternatives or when not to use the tool, so it lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List AI-generated categories within a bucket. When users activate Smart Memory, their memories are automatically organized into topic-based categories.
Returns for each category:
name: Category title
summary: Dense overview of core facts, preferences, current projects, key context (~200 words)
additionalInfo: Lists specific topics available in this category and suggests when to load the full memories
memoryCount: Number of memories in category
Also returns recentMemories: the 30 most recent memories in the bucket.
Use the summary and additionalInfo to decide if/when to load full memories via list_category_memories.
| Name | Required | Description | Default |
|---|---|---|---|
| bucketId | Yes | Bucket ID to get categories for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden—and it delivers. It details the return structure (fields, meaning, memory count), notes that recentMemories returns the 30 most recent memories, and explains how summaries serve as previews. It does not discuss edge cases like empty categories or missing bucket IDs, but overall it is transparent about 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 well-structured: a one-sentence summary, clear bullet points for return fields, a line for recentMemories, and a final usage tip. It is appropriately sized and every sentence provides value without 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?
Given only one parameter, no output schema, and no annotations, the description is remarkably complete. It explains the purpose, return data semantics, recentMemories behavior, and decision workflow. The only minor gap is the lack of explicit mention of behavior when Smart Memory is inactive or a bucket has no categories, but the description already implies these conditions.
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 fully describes bucketId with 100% coverage. The description does not add new constraints or special semantics for the parameter itself, though it helps clarify the bucket context and what categories are. This aligns with the baseline of 3 when schema coverage is high.
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 'List AI-generated categories within a bucket', which clearly states the action (list), the resource (categories), and the scope (within a bucket). It also distinguishes itself from the sibling tool list_category_memories by explaining when to load full 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?
The description gives clear context on when to use this tool: when Smart Memory is active and memories are auto-categorized. It also explicitly directs the agent to 'Use the summary and additionalInfo to decide if/when to load full memories via list_category_memories', providing an alternative tool and decision heuristic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's memory buckets. Buckets are organizational folders for memories (e.g., 'Work', 'Personal', 'Health').
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explains the concept of buckets but does not disclose operational behaviors such as whether the list is sorted, paginated, or whether it includes only names or also metadata. As a read-only list, the lack of side-effect disclosure is acceptable but not comprehensive.
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 includes a helpful example. There is no wasted wording 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 zero-parameter read-only list tool, the description is largely complete. It explains the domain concept and gives examples, but does not specify the exact return structure (e.g., bucket names only vs. metadata). Without an output schema, a little more detail would have been beneficial, but it's still sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by clarifying the meaning of 'buckets' as organizational folders, which is useful context even though no parameter documentation is needed.
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 the user's memory buckets with a specific verb and resource. It also provides concrete examples ('Work', 'Personal', 'Health') and distinguishes this from sibling tools like list_bucket_categories or list_category_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?
No explicit guidance is given about when to use this tool versus alternatives like get_memories_and_buckets or search_memories. The description is self-contained but provides no exclusions or contextual decision help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all memories within a specific Smart Memory category. Use when a category's summary (from list_bucket_categories) indicates it's relevant to the current conversation. The categoryId persists across conversations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of memories to retrieve (default: 20) | |
| bucketId | Yes | Bucket ID containing the category | |
| categoryId | Yes | Category ID to get memories from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It adds a useful persistence note ('The categoryId persists across conversations') but fails to reconcile the claim 'Get all memories' with the schema's limit parameter (default 20), which could mislead an agent expecting unbounded results. It also doesn't mention pagination or return format.
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 only two sentences and immediately front-loads the action and resource. Every phrase earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple category-based list operation, but the description omits key behavioral details like the limit default and pagination, and since there is no output schema, it doesn't explain the return shape. It covers the purpose and primary use case but leaves gaps around cardinality and response structure, making it minimally 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?
The schema already documents all three parameters with descriptions, so the description adds little beyond a note that categoryId persists across conversations. The baseline of 3 applies due to 100% schema coverage; the added persistence note is peripheral and doesn't clarify the semantics of the limit parameter or the relationship between bucketId and categoryId.
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 ('Get all memories') and the resource ('within a specific Smart Memory category'), which distinguishes it from siblings like search_memories or list_bucket_categories. It also references list_bucket_categories as a prerequisite, reinforcing its specific role.
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 provides a condition for use: 'Use when a category's summary (from list_bucket_categories) indicates it's relevant to the current conversation.' This gives an actionable guideline and connects to the sibling tool that provides the category summary, though it doesn't contrast with search_memories or discuss when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and synthesize context from the user's past AI conversations. MemoryPlugin's Chat History feature syncs conversations from ChatGPT, Claude, and other platforms, making them searchable.
Also known as the 'MemoryPlugin inject tool' or 'memoryplugin chat history tool'.
WHEN TO USE: When the user asks about their past decisions, patterns, preferences, relationships, projects, or anything where their conversation history provides valuable personal context. Consider proactively suggesting this when the user's question could benefit from their history.
HOW TO USE:
For simple lookups: a single query is fine
For complex/multifaceted topics: use parallel queries (via 'queries' array) approaching from different angles - timeline, emotions, people, decisions, outcomes, etc.
Set maxTokens per query (300-1000) to control how much context is returned. More tokens = richer detail but consumes more conversation window.
If unclear how much context to fetch, ask the user.
Use 'before'/'after' (ISO 8601 dates like "2025-01-15" or "2025-01-15T10:30:00Z") to constrain results to a date range. Bare dates are interpreted in UTC and are inclusive on both ends.
Use 'mode: "quality"' for slower but more thorough recall on hard or ambiguous queries; defaults to 'speed'.
Returns synthesized summaries (not raw conversation logs) with source metadata for citations.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Retrieval mode. 'speed' (default) is fastest; 'quality' runs a slower, more thorough retrieval pipeline for hard or ambiguous queries. | |
| after | No | Optional ISO 8601 date lower bound (inclusive). Bare dates like "2025-01-15" mean start-of-day UTC. | |
| query | No | Natural-language description of what the assistant is currently helping with. Use the end-user's latest request and any key details that should guide retrieval. | |
| before | No | Optional ISO 8601 date upper bound (inclusive). Bare dates like "2025-01-15" mean end-of-day UTC. | |
| queries | No | Array of query objects to process in parallel (max 15). Use for complex topics requiring multiple angles. | |
| platform | No | Optional hint about the downstream chat platform to influence formatting. | |
| maxTokens | No | Maximum tokens to allocate for injected context (defaults to 600, hard cap 2000). | |
| conversationContext | No | Short plaintext summary of the immediate conversation exchange, if available. | |
| conversationHistory | No | Ordered list of recent dialogue turns to ground retrieval. Each item must include a role ('user' or 'assistant') and the full message text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden and discloses return format (synthesized summaries with source metadata), date bound semantics (inclusive UTC), mode behavior (quality vs speed), and token consumption. It does not discuss failure modes or rate limits, but covers the most relevant behaviors.
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 longer than average but well-structured with WHEN TO USE, HOW TO USE, and output-format note. Most lines earn their place, though the alias sentence adds little functional value.
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 purpose, when to use, how to use key parameters, and return behavior, which is sufficient for a 9-parameter tool with no output schema. It omits edge cases like the 15-query parallel cap or failure behavior, but those are minor for selection/invocation.
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?
Although schema coverage is 100%, the description adds practical value by suggesting maxTokens range (300-1000), giving ISO 8601 date examples, and explaining parallel queries for complex topics. This goes beyond the schema's field descriptions without fully clarifying every parameter interaction.
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 opening sentence 'Search and synthesize context from the user's past AI conversations' states a specific verb and resource, and the later note 'Returns synthesized summaries (not raw conversation logs)' distinguishes it from raw-log retrieval tools like get_full_conversation. The alias 'MemoryPlugin inject tool' reinforces its role in injecting recall context.
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 WHEN TO USE section explicitly lists situations (past decisions, patterns, preferences, relationships, projects) and even suggests proactive use. It lacks explicit when-not-to-use instructions or named alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the user's saved memories using hybrid semantic + keyword search. Returns matching memories ranked by relevance.
Results may include image memories with a temporary image_url that can be fetched to view the image. Image URLs expire after a few hours.
MemoryPlugin stores memories the user wants to persist across AI conversations. Use when looking for specific saved information.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of memories to retrieve (default: 10) | |
| query | Yes | Search query | |
| bucketId | No | Optional bucket ID to limit search scope |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds valuable non-obvious context: image memories may include temporary image_urls that expire after a few hours, and the search is hybrid (semantic + keyword) with ranking by relevance. This goes beyond the bare operation and helps the agent understand potential pitfalls.
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. It front-loads the primary purpose, then adds the image URL caveat, and finally provides context and usage guidance. Each of the three short paragraphs serves a distinct purpose without redundancy or excessive detail.
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?
Despite having no output schema or annotations, the description covers the essential aspects: what it searches, how results are ranked, the presence of expiring image URLs, and when to use it. It could be more complete by describing the returned memory structure or mentioning default bucket behavior, but it is sufficient for a search operation with well-documented parameters.
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 covers 100% of parameters with descriptions (query, limit, bucketId). The tool description does not introduce additional parameter-level meaning, such as accepted formats or constraints. Thus, the baseline of 3 applies; the description doesn't go beyond the schema's already adequate documentation.
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 what the tool does: 'Search the user's saved memories using hybrid semantic + keyword search.' It includes a specific verb (search), a specific resource (saved memories), and a result description (ranked by relevance). It is distinct from sibling tools like search_uploaded_files, which targets files, and store_memory, which is for saving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use when looking for specific saved information.' This gives the agent a clear trigger for selecting this tool. However, it does not explicitly name alternatives or exclusions, such as noting that search_uploaded_files should be used for file content, so it doesn't fully differentiate between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search documents the user has uploaded to their MemoryPlugin document library (not files uploaded directly to this conversation). MemoryPlugin file buckets store documents persistently across all AI chats.
Returns relevant text passages with source file and page info.
Use when:
User explicitly mentions their MemoryPlugin documents
User asks about "my files" or "my documents" and there are no files in the current conversation
If unsure whether they mean MemoryPlugin files or conversation files, ask to clarify
| Name | Required | Description | Default |
|---|---|---|---|
| topK | No | Number of results to return (default: 5, max: 20) | |
| query | Yes | Search query text | |
| bucketId | No | Optional file bucket ID to limit search scope |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral transparency burden. It discloses that MemoryPlugin file buckets persist across AI chats, and that the tool returns text passages with source file and page info. It doesn't mention potential errors or rate limits, but covers the main behavioral aspects.
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 well-structured and concise: purpose statement, output summary, and a bulleted 'Use when' list. All sentences earn their place with no 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?
The description fully explains what the tool does, what it returns, and when to use it, including a caveat for ambiguity. It lacks an output schema, so the description's mention of text passages with source/page info fills that gap. Minor omissions like empty-result behavior prevent a 5.
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%, so each parameter is described in the schema. The description adds context that file buckets persist across chats, which gives meaning to bucketId, but overall the schema does the heavy lifting. 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 searches documents in the user's MemoryPlugin document library, explicitly excluding files uploaded directly to the conversation. This distinguishes it from sibling tools like search_memories and clarifies the exact resource being searched.
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 'Use when' section provides explicit conditions: user mentions MemoryPlugin documents, or asks about 'my files' with no conversation files, and instructs to clarify if unsure. This gives clear guidance on when to choose this tool over alternatives and when to ask for clarification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save information to the user's MemoryPlugin account. MemoryPlugin lets users build persistent memory across AI conversations.
WHEN TO USE: Proactively save anything that might be useful for future context - preferences, decisions, project details, personal info, insights, or anything the user might want recalled later. Err on the side of saving. Ask the user which bucket to save to if unclear.
Buckets are organizational folders (e.g., 'Work', 'Personal', 'Health').
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The memory text to store | |
| bucketId | No | Optional bucket ID to store the memory in |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral transparency. It explains that the tool saves to a persistent memory store and introduces buckets as organizational folders. However, it does not disclose potential side effects such as duplicate saves, overwrite behavior, authentication requirements, or what the response/return value looks like. This is adequate but not deeply transparent.
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 well-structured and appropriately sized: it opens with a one-sentence purpose, includes a clearly labeled 'WHEN TO USE' section with actionable guidance, and ends with a brief explanation of buckets. Every sentence adds useful context, with 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?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description covers the essential aspects: what it does, why to use it, and the key concept of buckets. It lacks details about return values, error conditions, or behavior when a bucketId is invalid, but for a basic save operation it is reasonably 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 coverage is 100%, so the baseline is 3. The description adds value by explaining that buckets are 'organizational folders' with examples, and by advising the agent to ask the user which bucket to use when unclear. This gives additional semantic guidance for the optional bucketId parameter beyond the schema's simple 'Optional bucket ID to store the memory in.'
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 leads with a specific verb and resource: 'Save information to the user's MemoryPlugin account.' It clearly distinguishes this as a write operation compared to sibling tools like search_memories or list_buckets. The MemoryPlugin context and the 'WHEN TO USE' section further clarify its purpose of building persistent 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 'WHEN TO USE' section provides explicit context: 'Proactively save anything that might be useful for future context' and 'Err on the side of saving.' It also advises asking the user which bucket to use when unclear. However, it does not explicitly state when not to use the tool or mention alternative tools for retrieval, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit a single memory's text or bucket, or move multiple memories to a different bucket.
WHEN TO USE: When the user wants to correct, update, or reorganize their saved memories.
Single memory: provide memoryId with optional text and/or bucketId/bucketName. Bulk move: provide memoryIds array with bucketId or bucketName.
Bucket can be specified by ID (number) or name (string). If a name is given and no bucket exists with that name, one is created automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | New text content (single memory only) | |
| bucketId | No | Target bucket ID | |
| memoryId | No | Encoded memory ID for single edit/move | |
| memoryIds | No | Array of encoded memory IDs for bulk move (max 100) | |
| bucketName | No | Target bucket name (auto-creates if missing) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does add useful context, such as 'If a name is given and no bucket exists with that name, one is created automatically,' and explains the single vs bulk operational modes. However, it omits details about side effects (e.g., what happens to the previous bucket/text) or whether the operation is reversible, which would be valuable for a mutating tool.
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 well-structured and appropriately sized. It opens with a clear one-sentence summary, then provides a usage directive, followed by concise mode-specific instructions. Every sentence adds value, and the formatting makes it easy to scan.
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 complexity (two modes, five optional parameters, no output schema), the description covers the essential operational context: when to use it, how to specify buckets by ID or name, and the auto-creation side-effect. It could be more complete by explicitly stating that memoryId or memoryIds is effectively required, and by mentioning the max 100 limit for bulk moves (though it appears in the schema). Overall, it is quite 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?
Despite full schema coverage, the description adds significant semantic value beyond the schema. It explains the relationship between parameters: 'Single memory: provide memoryId with optional text and/or bucketId/bucketName. Bulk move: provide memoryIds array with bucketId or bucketName.' This clarifies the valid combinations and mutual exclusivity, which the schema alone does not convey.
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 function: 'Edit a single memory's text or bucket, or move multiple memories to a different bucket.' This uses specific verbs (edit, move) and resources (memories, bucket), making it easy to distinguish from siblings like store_memory or create_bucket.
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 includes an explicit 'WHEN TO USE' section and clearly differentiates single-memory vs bulk-move scenarios. It does not explicitly name alternatives or state when not to use the tool, but the context is clear enough for an agent to decide.
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.4.0create_bucketexport_conversationget_conversation_summaryget_full_conversationget_memories_and_bucketslist_bucket_categorieslist_bucketslist_category_memoriesrecall_chat_historysearch_memoriessearch_uploaded_filesstore_memoryupdate_or_move_memoriesMost tools are clearly distinct, but there is some overlap between list_buckets and get_memories_and_buckets (both return buckets), and between get_full_conversation and get_conversation_summary (both retrieve conversation content). Otherwise, search, store, list, and update operations are well separated.
Naming follows a mostly consistent verb_noun pattern (e.g., search_memories, list_buckets, create_bucket). Minor deviations include 'recall_chat_history' instead of 'search_chat_history', 'store_memory' instead of 'save_memory', and the compound 'update_or_move_memories'.
13 tools is well-scoped for a memory plugin covering memories, buckets, categories, chat history, and file search. Each tool has a clear role, and the count feels appropriate without being excessive.
The tool set covers create, read, and update operations for memories and buckets, but lacks delete operations for memories or buckets. It also lacks an explicit upload tool for files, though search functionality exists. These gaps could hamper full lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent cloud memory for AI agents. Store and search key-value memories across sessions.
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
Persistent memory for AI agents. Search, store, and recall across sessions.
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/memoryplugin/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
