Model Context Protocol server for SharedMemory. Gives Claude Code, Claude Desktop, Cursor, VS Code Copilot, and other MCP-compatible tools persistent memory.
The fastest way to set up SharedMemory — one command, no JSON editing:
# Interactive — picks your client, asks for your API key
npx -y @sharedmemory/mcp-server install
# Or specify everything inline
npx -y @sharedmemory/mcp-server install --cursor --api-key sm_live_... --volume your-volume-id
# Install for all supported clients at once
npx -y @sharedmemory/mcp-server install --all --api-key sm_live_...Supported clients: --claude-code, --claude, --cursor, --vscode, --windsurf, --all
Related MCP server: BaseGrid MCP Server
If you prefer to edit config files yourself:
One command:
claude mcp add sharedmemory -- npx -y @sharedmemory/mcp-serverOr with env vars:
claude mcp add --env SHAREDMEMORY_API_KEY=sm_live_... \
--env SHAREDMEMORY_VOLUME_ID=your-volume-id \
sharedmemory -- npx -y @sharedmemory/mcp-serverOr create .mcp.json in your project root to share with your team:
{
"mcpServers": {
"sharedmemory": {
"command": "npx",
"args": ["-y", "@sharedmemory/mcp-server"],
"env": {
"SHAREDMEMORY_API_KEY": "${SHAREDMEMORY_API_KEY}",
"SHAREDMEMORY_API_URL": "https://api.sharedmemory.ai",
"SHAREDMEMORY_VOLUME_ID": "${SHAREDMEMORY_VOLUME_ID}"
}
}
}
}Tip: Copy the included
CLAUDE.mdinto your project root to teach Claude Code when and how to use SharedMemory proactively.
~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"sharedmemory": {
"command": "npx",
"args": ["-y", "@sharedmemory/mcp-server"],
"env": {
"SHAREDMEMORY_API_KEY": "sm_live_...",
"SHAREDMEMORY_API_URL": "https://api.sharedmemory.ai",
"SHAREDMEMORY_VOLUME_ID": "your-volume-id"
}
}
}
}.cursor/mcp.json in your project root:
{
"mcpServers": {
"sharedmemory": {
"command": "npx",
"args": ["-y", "@sharedmemory/mcp-server"],
"env": {
"SHAREDMEMORY_API_KEY": "sm_live_...",
"SHAREDMEMORY_API_URL": "https://api.sharedmemory.ai",
"SHAREDMEMORY_VOLUME_ID": "your-volume-id"
}
}
}
}.vscode/mcp.json:
{
"servers": {
"sharedmemory": {
"command": "npx",
"args": ["-y", "@sharedmemory/mcp-server"],
"env": {
"SHAREDMEMORY_API_KEY": "sm_live_...",
"SHAREDMEMORY_API_URL": "https://api.sharedmemory.ai",
"SHAREDMEMORY_VOLUME_ID": "your-volume-id"
}
}
}
}~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"sharedmemory": {
"command": "npx",
"args": ["-y", "@sharedmemory/mcp-server"],
"env": {
"SHAREDMEMORY_API_KEY": "sm_live_...",
"SHAREDMEMORY_API_URL": "https://api.sharedmemory.ai",
"SHAREDMEMORY_VOLUME_ID": "your-volume-id"
}
}
}
}Variable | Required | Default | Description |
| Yes | — | Agent API key |
| No |
| API endpoint |
| No | — | Default volume |
Tool | Description |
| Store a fact or note |
| Retrieve context BEFORE answering — semantic search over memories |
| Get entity details and relationships |
| Search entities by name |
| Knowledge graph overview |
| List accessible volumes |
| Delete a memory by ID |
| Update a memory by ID |
| Submit feedback on memory relevance |
| Store multiple memories at once |
| Retrieve a specific memory by ID |
| Auto-generated user profile from memories |
| Get a context block for LLM prompting |
| Store a persistent rule all agents will follow |
| List all active instructions for a volume |
| List uploaded documents |
URI | Description |
| Knowledge graph for the default volume |
Name | Description |
| Summarize all knowledge in a volume |
| Retrieve everything known about a topic |
https://docs.sharedmemory.ai/sdks/mcp-server
MIT
Store multiple facts or pieces of information at once. More efficient than calling remember() in a loop.
| Name | Required | Description | Default |
|---|---|---|---|
| memories | Yes | Array of memories to store | |
| volume_id | No | Volume (memory space) ID. Uses default if not set. | |
| user_id | No | Scope all memories to a specific user | |
| session_id | No | Scope all memories to a conversation session | |
| agent_id | No | Agent that created these memories | |
| app_id | No | App identifier for scoping |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose behavioral traits like atomicity, error handling, or idempotency; it only states 'store multiple' and 'efficient', leaving significant 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?
Two sentences, no wasted words, front-loads the core purpose; highly 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?
With 6 parameters, no output schema, and no annotations, the description is too brief to cover needed context like batching behavior, return values, or failure handling.
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 descriptions already document all parameters; the description adds no further semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'store' and resource 'multiple facts or pieces of information', and explicitly differentiates from sibling 'remember' by noting efficiency gain.
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 clear guidance by comparing to 'remember()' and stating efficiency benefit, but lacks explicit when-not-to-use or alternatives beyond the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask SharedMemory to make a decision or answer a question based on all stored knowledge. Returns an answer with confidence score, supporting evidence, applicable procedures, and conflict detection. Use this when you need a definitive answer about 'what should we do?' or 'how do we handle X?'
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The question or situation to decide on (e.g. 'How do we handle refunds?' or 'What's the deployment process?') | |
| volume_id | No | Volume ID. Uses default if not set. | |
| domain | No | Optional domain filter (e.g. 'engineering', 'sales') | |
| fast | No | Skip LLM synthesis for faster response (returns raw source instead) |
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 disclosure. It details the return structure (confidence score, supporting evidence, applicable procedures, conflict detection) and explains the effect of the 'fast' parameter (skip LLM synthesis). It does not mention authorization, rate limits, or idempotency, but the overall behavior is sufficiently transparent for an AI agent to understand side effects and outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences plus a usage note. It front-loads the primary purpose and structure, with no extraneous information. Every sentence adds value, making it efficient for an AI agent to parse quickly.
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 absence of an output schema, the description compensates by explaining the return format (confidence, evidence, procedures, conflict). The 4 parameters are covered by the schema and the description addresses the key 'fast' behavior. The sibling tools list is diverse, and the description effectively differentiates 'decide' from retrieval-focused tools. The description feels complete for an agent to decide when and how to invoke the tool.
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 has 100% description coverage, meaning each parameter is already well-documented. The description adds no new semantic details beyond the schema, except for reinforcing the overall purpose. According to guidelines, when schema coverage is high, the baseline is 3, and the description does not substantially add to parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to ask SharedMemory to make a decision or answer a question based on stored knowledge. It uses specific verbs ('ask', 'make a decision', 'answer') and identifies the resource ('SharedMemory'). The examples ('what should we do?', 'how do we handle X?') further clarify the scope, distinguishing it from sibling tools like query (retrieval) or get_memory (specific memory lookup).
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 advises when to use the tool: 'when you need a definitive answer about 'what should we do?' or 'how do we handle X?''. This provides clear context for appropriate usage. However, it does not mention when not to use it or explicitly point to alternatives among the many sibling tools, which would improve the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an existing memory by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes | The UUID of the memory to delete | |
| volume_id | No | Volume (project) ID. Uses default if not set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states it's a delete operation but does not disclose any side effects, auth requirements, or reversibility.
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 a single, clear sentence with no unnecessary words. 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?
Given the simplicity of the tool (2 params, no output schema), the description lacks important details such as return value, error handling, and success confirmation. It is insufficient for an agent to fully understand the tool's behavior.
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 schema already documents both parameters. The description adds no additional meaning beyond the schema's 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 'Delete' and the resource 'memory by ID'. It is specific and distinguishes from sibling tools like get_memory or update_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?
No guidance on when to use this tool versus alternatives (e.g., update_memory). The description lacks context for when deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit feedback on a memory's relevance. Helps improve future recall quality.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes | The UUID of the memory to rate | |
| feedback | Yes | Whether the memory was relevant/helpful | |
| volume_id | No | Volume ID. Uses default if not set. | |
| reason | No | Optional reason for the feedback |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It indicates a write operation and a positive effect on recall, but does not detail side effects, auth requirements, or response format. Basic 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 short sentences, front-loaded with the action and purpose, with 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?
Given no output schema and four parameters, the description covers the basic purpose but lacks details on return values or error conditions. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is well described in schema. The description adds no extra meaning beyond what is already in the schema, meeting the baseline.
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 'Submit' and resource 'feedback on a memory's relevance', with a clear purpose of improving future recall. It distinguishes from sibling CRUD tools like update_memory or remember, as feedback is a rating mechanism.
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 usage context (when you want to provide relevance feedback) but lacks explicit guidance on when not to use or alternatives. It is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assemble a smart context block from stored memories. Returns a pre-formatted context string ready to inject into a system prompt.
| Name | Required | Description | Default |
|---|---|---|---|
| volume_id | No | Volume ID. Uses default if not set. | |
| user_id | No | User ID for personalized context | |
| max_tokens | No | Max tokens for the context block. Default: 2000 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that the output is a pre-formatted string, but it does not mention behavioral traits such as read-only nature, authentication requirements, or default behavior for missing parameters (though the schema mentions defaults).
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 with two sentences: one for action and one for output. It is front-loaded and contains no extraneous 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?
Given that the input schema fully documents parameters and no output schema exists, the description adequately explains the purpose and output format. However, it lacks usage guidance and does not explain how the context is assembled from memories in relation to sibling tools, leaving some 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 coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema; the schema already describes each parameter sufficiently. The description's mention of 'stored memories' is generic and does not enhance parameter understanding.
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 that the tool assembles a smart context block from memories and returns a pre-formatted string for system prompts. It specifies the verb 'assemble' and resource 'context block', distinguishing it from sibling tools like get_memory or get_profile.
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 no guidance on when to use this tool versus alternatives. Siblings include many memory retrieval tools, but there is no mention of when to prefer get_context over get_memory or query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get everything SharedMemory knows about a specific entity (person, project, concept, etc). Returns the summary, all facts, and relationships.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the entity to look up (e.g., 'John Smith', 'React', 'Project Alpha') | |
| volume_id | No | Volume ID. Uses default if not set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It implies a read operation but does not explicitly state it is non-destructive or safe. For a read tool, this is minimally adequate but not fully 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?
Two sentences with no unnecessary words. Front-loaded with the main purpose, then details returned data. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description specifies what is returned (summary, facts, relationships). It covers the core functionality for a retrieval tool. Could mention limitations or pagination, but not required for this context.
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 descriptions cover both parameters (name and volume_id) with examples and usage notes. The tool description adds context about entity types (person, project, concept), enhancing understanding 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' and resource 'entity', specifying it returns summary, facts, and relationships. It distinguishes from siblings like 'get_memory' and 'search_entities' by emphasizing comprehensive retrieval.
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 on when to use this tool versus alternatives like 'get_memory' or 'get_graph'. The description describes functionality but lacks when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an overview of the entire knowledge graph for a volume. Shows all entities and their relationships — like a map of everything SharedMemory knows.
| Name | Required | Description | Default |
|---|---|---|---|
| volume_id | No | Volume ID. Uses default if not set. | |
| limit | No | Max entities to return. Default: 50 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavior. It implies read-only but doesn't state side effects, permissions, performance, or return format. Schema documents limit, but description lacks behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The metaphor is slightly wasteful but not harmful. Efficiently communicates purpose.
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 no output schema and moderate complexity, the description covers basic purpose but lacks details on return structure, pagination, or how 'overview' is structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond what the schema provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'overview of the entire knowledge graph for a volume', distinguishing it from sibling tools like get_memory or get_entity.
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 on when to use this tool vs alternatives. The metaphor 'map' implies broad overview, but no exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific memory by its ID. Useful for viewing the full details of a memory found via recall.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes | The UUID of the memory to retrieve | |
| volume_id | No | Volume ID. Uses default if not set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies read-only operation but does not explicitly state non-destructive behavior, error handling (e.g., missing memory), or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence states core purpose; second adds context. Highly 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?
Adequate for a simple read function with two parameters, but lacks mention of output format or error behavior. With no output schema, description could be more 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 description adds no extra meaning beyond the schema. Baseline 3 is appropriate as the description does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Retrieve a specific memory by its ID,' providing a specific verb and resource. It distinguishes from generic tools but does not explicitly differentiate from sibling tools like get_context or get_entity.
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?
Description mentions it's useful after recall but lacks guidance on when not to use it or alternatives such as search_entities or query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive profile for a volume or user. Returns categorized facts (identity, preferences, expertise, projects), relationships, recent activity, instructions, topics, stats, and a pre-formatted context_block for LLM injection.
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | No | Optional user ID to scope the profile to a specific user | |
| volume_id | No | Volume ID. Uses default if not set. | |
| refresh | No | Force refresh (bypass 5-min cache) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It mentions caching behavior via the 'refresh' parameter but does not disclose whether the operation is read-only, required permissions, or any side effects.
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?
Single sentence that front-loads the purpose and lists output categories efficiently. Somewhat dense but no redundancy; could be slightly more concise.
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 three optional parameters and no output schema, the description provides a good overview of the return structure. However, it lacks behavioral details like read-only nature and potential side effects.
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 schema already documents all parameters. Description adds context about the output but does not enhance parameter meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool gets a comprehensive profile for a volume or user and enumerates the categories returned (identity, preferences, etc.). It distinguishes from siblings like 'profile' and 'get_context' by specifying the scope and content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for retrieving a rich profile for AI context injection but does not explicitly state when to use versus alternatives like 'get_entity' or 'get_context'. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all documents that have been uploaded and processed for a volume.
| Name | Required | Description | Default |
|---|---|---|---|
| volume_id | No | Volume ID. Uses default if not set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only states that documents are listed if 'uploaded and processed' but does not explain what 'processed' means, whether pagination occurs, or any permission or state requirements.
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 a single sentence with no extraneous words, efficiently conveying the core function.
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 tool with one parameter and no output schema, the description is adequate but leaves ambiguity about the return format and the exact status of documents (e.g., does 'processed' mean only successful ones?). Additional clarity would improve completeness.
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 provides 100% coverage for the single parameter. The description adds value by noting that volume_id 'uses default if not set', which clarifies optionality 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 'list' and the resource 'documents' with a specific scope ('uploaded and processed for a volume'). It is distinct from sibling tools like list_instructions and list_volumes.
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 on when to use this tool versus alternatives, nor any conditions or prerequisites. The description simply states the function without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active instructions/rules for a volume. These are automatically included in every context assembly.
| Name | Required | Description | Default |
|---|---|---|---|
| volume_id | No | Volume ID. Uses default if not set. |
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 describes a read-only list operation with no side effects, but does not disclose potential behaviors like pagination, error handling, or completeness guarantees beyond 'all active'.
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 concise sentences. The first states the core purpose, the second adds relevant context. 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?
The tool has no output schema, so the description should ideally describe the return format. It does not, but for a simple list tool, the missing information is minor. The description adequately covers the what and why, but not the what-to-expect.
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% (volume_id is described as 'Volume ID. Uses default if not set.'). The overall description does not add additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists active instructions/rules for a volume, which distinguishes it from sibling tools like set_instruction or get_context. The mention of being automatically included in context assemblies adds further 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 description implies usage: to view instructions that are automatically included. However, it does not explicitly state when to use this versus alternatives like get_context, nor does it provide exclusions. The context is clear enough for an AI agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all memory volumes (projects) this API key has access to. Each volume is an independent memory space.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only, non-destructive operation by stating 'list'. Since no annotations are provided, the description carries the full burden, and it sufficiently conveys that no side effects occur, though it could be more explicit.
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 with two sentences, well-structured, and front-loaded with the action. Every sentence adds value, with no unnecessary 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 simplicity of the tool (no parameters, no output schema), the description is complete. It explains what the tool does and the nature of the resource, which is sufficient for an agent to use it 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?
There are no parameters, so the schema coverage is 100% trivially. The description adds value by explaining what a volume is, which helps the agent understand the context of the returned data. This meets the baseline of 4 for zero-parameter tools.
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 'list', the resource 'memory volumes', and provides explanatory context ('Each volume is an independent memory space'). It effectively distinguishes from sibling tools like get_memory by focusing on volumes.
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 tells when to use the tool: to list all memory volumes accessible by the API key. It does not explicitly mention alternatives or when not to use, but the context is clear enough for a simple listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a structured profile for any entity (person, project, team, concept, company). Returns their role, facts, relationships, recent activity, and confidence level. Use this to understand 'who is X?' or 'what is project Y?'
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | Name of the entity to look up (e.g. 'Kevin', 'Acme Corp', 'auth service') | |
| volume_id | No | Volume ID. Uses default if not set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It implies a read-only operation ('Get'), but does not mention potential costs, failure modes, or dependencies (e.g., volume_id required? default?). The description is adequate for a simple query but lacks depth for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no unnecessary words. First sentence states purpose and output. Second sentence gives usage example. Every word earns its place. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists return fields (role, facts, relationships, recent activity, confidence). Input parameters are covered. It could mention error handling or edge cases (e.g., entity not found), but overall it is fairly complete for a straightforward lookup tool.
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 schema already provides clear descriptions for both parameters (entity and volume_id). The description adds context about entity types (person, project, etc.) but does not significantly enrich what the schema already conveys. 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?
Description clearly states it gets a structured profile for any entity type (person, project, etc.) and lists specific return fields (role, facts, relationships, recent activity, confidence). The verb 'Get' and resource 'profile' are explicit, and the examples make it easy to understand.
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 direct usage guidance with 'Use this to understand who is X? or what is project Y?', which helps the agent decide when to invoke it. However, it does not explicitly contrast with siblings like 'get_profile' or 'get_entity', leaving some ambiguity about which tool to prefer in overlapping scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve context BEFORE answering. Searches SharedMemory for relevant memories using semantic similarity. Returns matching memories from vector search + related knowledge graph facts.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to search for in memory | |
| volume_id | No | Volume ID. Uses default if not set. | |
| limit | No | Max results. Default: 10 | |
| date_from | No | Filter memories with event_date >= this ISO date (e.g. 2026-04-01) | |
| date_to | No | Filter memories with event_date <= this ISO date (e.g. 2026-04-30) | |
| user_id | No | Filter results to a specific user | |
| session_id | No | Filter results to a specific session | |
| agent_id | No | Filter results from a specific agent | |
| app_id | No | Filter results from a specific app | |
| rerank | No | Re-rank results for better relevance. Default: false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It explains the use of semantic similarity and combination of vector search with knowledge graph facts, but lacks details on side effects (none assumed), output format, or any destructive implications. This is adequate but not exhaustive.
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 key instruction 'Retrieve context BEFORE answering'. Every sentence adds value, and there is 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?
Given 10 parameters, no output schema, and no annotations, the description is somewhat incomplete. It explains the core behavior but does not elaborate on parameter interactions (e.g., default volume_id, effect of rerank) or output details. A more comprehensive description would benefit the agent.
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 baseline is 3. The description adds high-level context about how the tool processes queries (semantic similarity, vector + knowledge graph), but does not clarify individual parameter meanings beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving context before answering by searching SharedMemory via semantic similarity. It distinguishes from siblings like get_memory (specific retrieval) and search_entities (entity search).
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 advises using this tool 'BEFORE answering', providing clear context. However, it does not mention when not to use it or suggest alternatives like get_memory for direct lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a fact, note, or piece of information in SharedMemory. The memory pipeline will classify it, check for conflicts, extract knowledge, and build the graph automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The fact, note, or information to remember | |
| volume_id | No | Volume (memory space) ID. Uses default if not set. | |
| memory_type | No | Type hint for the memory. Default: factual. Use 'instruction' for rules/conventions all agents should follow. | |
| event_date | No | ISO date (YYYY-MM-DD or full ISO) of when the event occurred. Not when it's being stored. | |
| user_id | No | Scope this memory to a specific user | |
| session_id | No | Scope this memory to a conversation session | |
| agent_id | No | Agent that created this memory | |
| app_id | No | App identifier for scoping | |
| metadata | No | Arbitrary key-value metadata to attach |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the memory pipeline classifies, checks conflicts, extracts knowledge, and builds the graph automatically. This adds meaningful behavioral context beyond the simple 'store' action, especially since annotations are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only two sentences to convey the core purpose and behavioral outcome. 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 9 parameters and no output schema, the description is fairly complete for the main purpose but lacks details on return values, error conditions, or what the 'graph' output looks like. It is adequate but not fully comprehensive.
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 provides a high-level overview but does not add specific details about parameter usage or constraints beyond what the schema already documents.
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 stores facts, notes, or information in SharedMemory. However, it does not explicitly differentiate from sibling tools like batch_remember or update_memory, which have distinct purposes.
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 on when to use this tool versus alternatives, such as batch_remember for bulk storage or delete_memory for removal. There is no mention of prerequisites, exclusions, or 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 for entities in the knowledge graph by name. Useful for finding people, projects, concepts, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term (matched against entity names) | |
| volume_id | No | Volume ID. Uses default if not set. | |
| limit | No | Max results. Default: 20 |
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 implies a read-only search operation, but does not explicitly state that it is non-destructive or any other behavioral traits. However, for a search tool, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that covers purpose and use cases with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with three parameters and no output schema, the description is adequate. It explains what the tool does and when to use it, though it could mention the return format or that results are entity identifiers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for all three parameters. The description adds no additional meaning beyond the schema, providing a baseline score of 3.
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 it searches for entities in the knowledge graph by name, and gives examples (people, projects, concepts). This differentiates it from siblings like get_entity (likely by ID) and query (more general).
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 offers use cases ('useful for finding people, projects, concepts') but does not explicitly state when not to use it or suggest alternatives. For example, it doesn't mention get_entity for when you have an ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a persistent instruction or rule for a volume. Instructions are automatically included in every context assembly — any agent querying this volume will see them. Use for coding conventions, project rules, team preferences, or architectural decisions that all agents should follow.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The instruction or rule (e.g. 'Always use functional React components with TypeScript') | |
| volume_id | No | Volume ID. Uses default if not set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses persistence, automatic inclusion in context assemblies, and the write operation. It lacks details on overwrites or limits, but overall adequately 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?
Two sentences with no redundancy. The first sentence defines the action, the second gives concrete examples. Every sentence adds 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?
For a simple store tool with no output schema, the description covers purpose and behavior adequately. It mentions optional volume_id. It lacks error or success details, but the context is sufficient.
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 baseline is 3. The description adds context for the 'content' parameter by listing example uses, but does not provide syntax or formatting 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 states 'Store a persistent instruction or rule for a volume,' which is a specific verb-resource pair. It distinguishes from sibling tools like 'list_instructions' and 'delete_memory' by highlighting persistence and automatic inclusion.
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 lists suitable use cases (coding conventions, project rules, etc.), providing clear context for when to use. It does not explicitly state when not to use or mention alternatives, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the content of an existing memory by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes | The UUID of the memory to update | |
| content | Yes | New content for the memory | |
| volume_id | No | Volume (project) ID. Uses default if not set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description lacks details on behavioral traits such as whether the update is partial or full, idempotency, or side effects. Minimal transparency beyond the basic operation.
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?
A single sentence with no wasted words. Could add a little context without affecting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 params, no output schema), the description is minimally complete. However, it lacks usage context compared to many sibling tools, e.g., how it differs from remember.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional information about parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update), the resource (memory), and the identification method (by ID). It distinguishes from sibling tools like delete_memory, get_memory, and remember.
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 on when to use this tool versus alternatives. Does not mention when not to use or any prerequisites.
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.
v2.8.0batch_rememberdecidedelete_memoryfeedbackget_contextget_entityget_graphget_memoryget_profilelist_documentslist_instructionslist_volumesprofilequeryremembersearch_entitiesset_instructionupdate_memoryMost tools have distinct purposes, but 'get_entity' and 'profile' are very similar in function, which could cause confusion. Descriptions help differentiate them, but the overlap is notable.
The predominant pattern is verb_noun lowercase with underscores, but 'profile' and 'decide' are verb-only outliers, breaking perfect consistency. Overall, the naming is still predictable.
18 tools cover a wide range of memory operations without being excessive. Each tool serves a clear, non-redundant role in storing, retrieving, managing, and deciding based on knowledge.
The tool surface covers CRUD, search, context assembly, and decision-making. Missing volume creation/deletion and advanced ability management, but the core memory workflows are well-served.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
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/sharedmemoryai/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
