Provides a storage backend using MongoDB, enabling shared team memory with document-based storage and atomic operations.
Provides a storage backend using PostgreSQL, using JSONB columns for observations and supporting concurrent writes with ON CONFLICT DO NOTHING.
Provides a storage backend using Redis, with fast reads using hash fields and atomic creates using HSETNX.
Provides a storage backend using SQLite, storing memory data in a local database file with WAL mode and transactions.
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., "@NexMem MCP Save that the payment service uses gRPC and depends on AuthService"
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.
Shared Agent Memory for Teams — a plug-and-play MCP memory server with pluggable database backends.
NexMem gives AI coding agents (Cursor, Claude Desktop, etc.) a persistent knowledge graph that the whole team shares. Agents learn as they work — discovering services, architecture patterns, and conventions — then recall that knowledge instantly in future sessions.
Self or Team memory — personal graph or shared team graph, switchable via env var
5 storage backends — JSONL (default), SQLite, MongoDB, PostgreSQL, Redis
Atomic operations — no race conditions when multiple team members write simultaneously
Strong consistency — reads always return the latest state
Wire-compatible — same JSONL format as @modelcontextprotocol/server-memory for import/export
Guided autonomous — built-in instructions tell the agent what to save (and what not to)
Extensible — add custom backends by implementing the StorageAdapter ABC
Related MCP server: MegaMemory
pip install mcp-nexmemOr with a database backend:
pip install "mcp-nexmem[mongodb]" # MongoDB
pip install "mcp-nexmem[postgres]" # PostgreSQL
pip install "mcp-nexmem[redis]" # Redis
pip install "mcp-nexmem[all]" # All backendsAdd to your ~/.cursor/mcp.json:
{
"mcpServers": {
"nexmem": {
"command": "nexmem-mcp",
"env": {
"NEXMEM_MODE": "self"
}
}
}
}That's it. The agent now has persistent memory.
For a guided setup that generates the config for you:
nexmem-mcp initOr run the install script:
bash scripts/install.shAll configuration is via environment variables (prefix: NEXMEM_):
Variable | Default | Description |
|
|
|
| OS username | Your identity |
| (required for team) | Team identifier |
|
|
|
|
| Disable write tools |
| (built-in) | Custom instructions file path or inline text |
Variable | Default |
|
|
|
|
|
|
|
|
|
|
NEXMEM_TEAM_NAME and NEXMEM_USER_NAME control which namespace your data is stored under. Namespaces provide complete data isolation within the same database.
Config | Namespace | Who sees the data |
|
| Only Alice |
|
| Only Bob |
|
| Everyone with same team name |
|
| Different team, separate graph |
Every entity and relation is tagged with the namespace in the database:
{ "namespace": "team:platform-eng", "name": "AuthService", "entity_type": "service", ... }In team mode, NEXMEM_TEAM_NAME determines the namespace. All team members who set the same team name share one knowledge graph.
In self mode, NEXMEM_USER_NAME determines the namespace. Each user has a private graph.
Multiple teams can share the same database — their data is isolated by namespace.
Switching modes doesn't delete data. Both self:alice and team:platform-eng can coexist.
Without shared memory, every agent on your team works in isolation. Alice's agent spends 20 minutes tracing how PaymentService authenticates requests — then Bob's agent does the exact same work the next day. A new hire's agent rediscovers every architectural decision from scratch. Knowledge stays locked inside individual sessions and vanishes when the conversation ends.
With NexMem in team mode, that cycle breaks:
Before — Each developer's agent starts from zero every session. The same services, patterns, and gotchas get rediscovered over and over. Onboarding is slow. Tribal knowledge lives in Slack threads and outdated wiki pages that agents can't read.
After — One agent discovers that PaymentService uses gRPC and depends on AuthService. Seconds later, every team member's agent knows it too. A new hire's agent on day one already understands the architecture, naming conventions, and non-obvious configuration details that took the team months to accumulate.
This happens with zero extra effort — agents read from and write to the shared graph as a natural part of their workflow. No one has to remember to "save to memory" or maintain documentation manually. The knowledge graph grows organically as the team works and stays current because it's written by the agents actually touching the code.
Pick a database your team can all reach.
Option A: MongoDB Atlas (recommended, free tier available)
Sign up at mongodb.com/atlas and create a Free M0 cluster
Create a database user and set Network Access to 0.0.0.0/0 (allow all IPs)
Click Connect > Drivers > copy the connection string
Use it as NEXMEM_MONGODB_URI (append /nexmem as the database name)
Option B: Local Docker (for testing)
docker compose --profile mongodb up -dEach team member adds this to their ~/.cursor/mcp.json:
{
"mcpServers": {
"nexmem": {
"command": "nexmem-mcp",
"env": {
"NEXMEM_MODE": "team",
"NEXMEM_TEAM_NAME": "platform-eng",
"NEXMEM_BACKEND": "mongodb",
"NEXMEM_MONGODB_URI": "mongodb://shared-host:27017/nexmem"
}
}
}
}Agents will proactively read from and write to the shared knowledge graph. When Alice's agent discovers that PaymentService uses gRPC, Bob's agent will know it too — immediately, with no manual sync.
NexMem stores a knowledge graph with two types of records:
Entities — things the agent knows about (services, repos, APIs, etc.):
{"type":"entity","name":"PaymentAPI","entityType":"service","observations":["Uses gRPC","Handles billing"]}Relations — connections between entities:
{"type":"relation","from":"PaymentAPI","to":"AuthService","relationType":"depends_on"}The server exposes 11 MCP tools:
Tool | Description |
| Read the entire knowledge graph |
| Search entities by name, type, or observations |
| Get specific entities by name |
| Create new entities |
| Create relations between entities |
| Add observations to existing entities |
| Delete entities and their relations |
| Remove specific observations |
| Remove specific relations |
| Show current config, mode, and health |
| Import from upstream server-memory format |
The server includes built-in instructions that guide the agent:
Reads automatically — searches memory at the start of relevant tasks
Writes proactively — saves useful discoveries (services, patterns, decisions) without being asked
Skips noise — doesn't save trivial or temporary information
You can customize this behavior with NEXMEM_INSTRUCTIONS.
Unlike file-based approaches that load → modify → overwrite (causing race conditions), NexMem uses atomic database operations:
create_entities → INSERT ... ON CONFLICT DO NOTHING
add_observations → atomic array append
delete_entities → atomic delete by name
Two team members writing simultaneously both succeed without overwriting each other.
Zero dependencies. Stores one .jsonl file per namespace in ~/.nexmem/. Uses file locking for safety. Best for self mode.
Zero extra dependencies (uses stdlib). Stores a single .db file with proper tables and indexes. Uses WAL mode and transactions. Good for lightweight local use.
Install: pip install "mcp-nexmem[mongodb]"
Recommended for teams. Document model fits naturally. Uses insertMany(ordered=false) for idempotent creates, $push for atomic observation appends.
Install: pip install "mcp-nexmem[postgres]"
Uses JSONB columns for observations. INSERT ... ON CONFLICT DO NOTHING for safe concurrent writes. Connection pooling via asyncpg.
Install: pip install "mcp-nexmem[redis]"
Stores entities as hash fields, relations as set members. Fast reads. HSETNX for atomic creates.
Implement the StorageAdapter ABC and register it:
from nexmem_mcp.adapters import register_adapter
from nexmem_mcp.adapters.base import StorageAdapter
@register_adapter("dynamodb")
class DynamoDBAdapter(StorageAdapter):
...If you have JSONL files from @modelcontextprotocol/server-memory or other MCP memory servers, use the import_jsonl tool:
"Import this data into memory: <paste JSONL content>"Or programmatically, the agent can call import_jsonl(jsonl_content="...").
docker compose --profile mongodb up -d # MongoDB on :27017
docker compose --profile postgres up -d # PostgreSQL on :5432
docker compose --profile redis up -d # Redis on :6379docker build --target all -t nexmem-mcp .
docker run -e NEXMEM_MODE=team -e NEXMEM_BACKEND=mongodb \
-e NEXMEM_MONGODB_URI=mongodb://host:27017/nexmem nexmem-mcpgit clone https://github.com/arpanroy41/nexmem-mcp.git
cd nexmem-mcp
pip install -e ".[dev]"
pytestMIT
Add new observations to existing entities in the knowledge graph.
Each dict must have: entityName (str), contents (list[str]).
| Name | Required | Description | Default |
|---|---|---|---|
| observations | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only indicates mutation (add). It does not disclose error handling (e.g., missing entity), idempotency, or safety traits. The output schema exists but isn't shown, so behavioral gaps remain.
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: first states purpose, second details parameter structure. No unnecessary words, efficient front-loading of key info.
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 output schema exists, return info is covered elsewhere. However, the description lacks usage guidelines and behavioral details, which are needed for a tool with 0% schema coverage and no annotations. It covers the basics but is 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 coverage is 0%, so the description adds significant value by specifying that each dict must have entityName (str) and contents (list[str]), which is missing from the schema. This provides critical structure for the agent.
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 (add) and resource (observations to existing entities), and specifies required fields in each dict. However, it does not explicitly distinguish from sibling tools like create_entities or delete_observations, though the purpose is evident.
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 vs alternatives, no prerequisites mentioned (e.g., entities must exist), and no when-not-to-use info. The description implies usage but lacks explicit context for an agent to decide between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create multiple new entities in the knowledge graph.
Each entity dict must have: name (str), entityType (str), observations (list[str]).
| Name | Required | Description | Default |
|---|---|---|---|
| entities | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies creation but does not disclose behavior on duplicates, validation, or side effects. Minimal behavioral context beyond the action.
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 purpose, second details required structure. 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?
For a bulk creation tool with an output schema, the description lacks details on error handling, limits, or return value behavior. Adequate but not thorough.
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 has 0% coverage and only specifies an array of objects. The description adds required fields (name, entityType, observations), providing essential meaning missing from 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 creates multiple new entities in the knowledge graph, specifying the action and resource. It distinguishes from sibling tools like add_observations or create_relations by focusing on entity creation.
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 add_observations or create_relations. The description does not mention prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create multiple new relations between entities in the knowledge graph.
Each relation dict must have: from (str), to (str), relationType (str). Relations should be in active voice.
| Name | Required | Description | Default |
|---|---|---|---|
| relations | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, error handling, idempotency, or authorization requirements, leaving significant gaps for an agent.
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, no wasted words. The first sentence states the purpose, the second adds a clear requirement.
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 only one parameter and an existing output schema, the description covers the basics but omits behavioral aspects like failure modes or limitations, leaving it adequate but not 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?
The description specifies required fields (from, to, relationType) and style (active voice), adding meaningful detail beyond the bare schema (which only defines an array of objects with additionalProperties true).
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 ('Create multiple new relations'), the resource ('relations in the knowledge graph'), and distinguishes from siblings like 'create_entities' and 'delete_relations'.
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 a specific guideline ('Relations should be in active voice') but lacks explicit when-to-use or when-not-to-use instructions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete multiple entities and their associated relations from the knowledge graph.
| Name | Required | Description | Default |
|---|---|---|---|
| entityNames | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the destructive action but lacks details on reversibility, safety, atomicity, or permissions. Minimal transparency beyond the core action.
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, clear sentence with no extraneous information. 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 tool's simplicity and the presence of an output schema, the description is mostly complete. It covers the action and scope, though it could mention side effects or constraints for 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?
Schema description coverage is 0% and the description does not elaborate on the parameter 'entityNames' (format, case-sensitivity, etc.). While the tool description implies the parameter's role, it adds little meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete', the resource 'entities', and the scope 'multiple entities and their associated relations'. It distinguishes from sibling tools like delete_relations by explicitly mentioning the deletion of associated relations.
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 such as delete_relations or create_entities. Absence of context about prerequisites or exclusions reduces usefulness for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete specific observations from entities in the knowledge graph.
Each dict must have: entityName (str), observations (list[str]).
| Name | Required | Description | Default |
|---|---|---|---|
| deletions | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only details input format, not behavioral traits like destructiveness, permissions, or atomicity. Agent cannot infer side effects or error handling.
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 succinct sentences: first states purpose, second details parameter structure. No redundant or irrelevant text. Ideal front-loading.
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 but incomplete: explains input format but no behavior on success/failure, idempotency, or what happens if observations missing. Output schema exists, partially compensating for missing return value description.
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 0%, so description compensates by specifying required keys (entityName, observations) for each dict in the deletions array, adding meaning beyond the permissive 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 deletes specific observations from entities, with a precise verb and resource. It distinguishes from sibling tools like delete_entities, delete_relations, and add_observations.
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., delete_entities for deleting entire entities). 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.
Delete multiple relations from the knowledge graph.
Each relation dict must have: from (str), to (str), relationType (str).
| Name | Required | Description | Default |
|---|---|---|---|
| relations | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It omits important details such as whether deletion is permanent, if it returns confirmation, or error behavior for missing relations. The description only covers input format, not the consequences of the action.
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 states the purpose, and the second clarifies the input format. It is front-loaded and succinct.
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 deletion tool with no annotations, the description is incomplete. It does not explain the return value (though output schema exists), error handling, idempotency, or whether the entire graph is affected. The required fields are specified, but additional allowed properties are not mentioned. Overall, the description covers basic usage but leaves gaps in expected behaviors.
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 has 0% description coverage and the items schema is loosely defined with additionalProperties: true. The description adds critical semantic information by specifying the required keys (from, to, relationType) and their types (str), which is not enforced by the schema. This adds significant meaning beyond the schema definition.
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 (relations from the knowledge graph). It specifies that it handles multiple relations, distinguishing it from single-relation operations or other entity operations like delete_entities.
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 versus alternatives. The description implies usage for deleting relations but does not mention when not to use (e.g., for single relation deletion or bulk deletion vs iterative calls). Alternatives like create_relations exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the current memory configuration: mode, backend, namespace, health.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description implies read-only operation by using 'Show'. Does not explicitly state non-destructive behavior, but output schema exists to clarify returns.
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 of 10 words, directly states purpose and output fields. 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 no parameters, output schema present, and simple status-check function, the description fully covers what the tool does and returns.
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?
No parameters; schema coverage is 100%. Description correctly omits parameter info as none exist, meeting baseline 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?
Description uses specific verb 'Show' and resource 'memory configuration', listing fields. Clearly distinguishes from sibling mutation tools like add_observations or delete_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context for when to use (checking memory configuration). No exclusions or alternatives needed due to simple nature, but no explicit guidance provided either.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import entities and relations from JSONL-formatted text.
Compatible with @modelcontextprotocol/server-memory and other MCP memory exports. Each line should be a JSON object with a 'type' field of 'entity' or 'relation'.
| Name | Required | Description | Default |
|---|---|---|---|
| jsonl_content | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes expected line format but does not disclose error handling, duplicate behavior, or whether it merges or replaces existing data. Leaves significant behavioral 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 succinct sentences. First sentence states purpose, second adds compatibility and format. 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?
One parameter and an output schema exist; description omits return value details and error cases. Adequate for basic use but lacking edge-case context for a bulk import operation.
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?
Only parameter jsonl_content is explained as JSONL with required 'type' field. Adds meaning beyond schema (which only says string), but could detail valid values and structure more thoroughly.
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?
Clearly states it imports entities and relations from JSONL-formatted text. Mentions compatibility with MCP memory exports, distinguishing it from siblings like create_entities (which handle single items).
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?
Implies usage for batch import from compatible exports, but lacks explicit when-not-to-use or alternative tools for individual operations. The context of sibling tools partially compensates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open specific nodes in the knowledge graph by their names.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'open specific nodes' without disclosing read-only status, side effects, permissions required, or what happens to the nodes (e.g., are they returned as data? marked as active?). This is insufficient for a tool that interacts with a knowledge graph.
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 that states the core action and resource. It is concise and front-loaded, but could be slightly improved by adding key constraints without becoming verbose.
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 lack of annotations, the description does not explain what 'open' returns or modifies. Despite having an output schema (not shown), the description omits expected outcomes. Compared to sibling tools, it is inadequately specified for an operation on graph nodes.
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 0% description coverage for the `names` parameter. The description adds only 'by their names', which does not specify expected format, uniqueness, case sensitivity, or behavior for missing nodes. With a single required parameter, more detail 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 uses the verb 'open' and the resource 'nodes in the knowledge graph', and specifies the selection method 'by their names'. This distinguishes it from sibling tools that create, delete, or search nodes, but 'open' could be more precise (e.g., 'retrieve' or 'fetch').
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 given on when to use this tool versus alternatives like `search_nodes` or `read_graph`. It does not state prerequisites, limitations, 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.
Read the entire knowledge graph.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly indicates a read-only operation, which is the primary behavioral trait. However, with no annotations provided, the description does not disclose potential performance implications for large graphs or guarantee idempotency. It is transparent about the basic aspect but lacks 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?
The description is a single, front-loaded sentence with no waste. It is concise and to the point, but could be slightly expanded to include additional context without breaking 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 tool's simplicity (no parameters, output schema exists), the minimal description is adequate but not complete. It does not mention what the output contains (e.g., all entities, relations, observations) or potential data volume. With siblings and no annotations, more context 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 tool has zero parameters, and schema coverage is trivially 100%. According to guidelines, 0 parameters yields a baseline of 4. The description adds no parameter information, which is acceptable since there are none to describe.
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 'read' and the resource 'the entire knowledge graph', which is specific and distinguishes this tool from sibling tools like search_nodes or open_nodes. However, it does not specify the format or structure of the returned graph, leaving minor ambiguity.
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 like search_nodes for targeted queries or get_memory_status for summary. The description lacks context for appropriate usage or when not to use it, such as for large graphs that may be slow to retrieve entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for nodes in the knowledge graph based on a query.
Matches against entity names, types, and observation content (case-insensitive).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 search specifics (matches against names, types, observations) and case-insensitivity, but omits details like result limits, pagination, or error handling. The behavior is generally clear but lacks 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 sentences, front-loaded with purpose, then details. No redundant phrases. Every word contributes.
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 a single parameter and an output schema, the description covers core behavior. It could mention that results are nodes or hint at result structure, but the output schema presumably handles that. Almost 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?
With no schema description coverage (0%), the description adds meaningful context: the query is matched case-insensitively against three specific fields. This is essential for correct usage beyond the bare parameter name.
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 searches for nodes in a knowledge graph based on a query. It specifies the search targets (entity names, types, observation content) and notes case-insensitivity, making it distinct from sibling tools like 'open_nodes' or 'read_graph'.
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 the tool should be used for searching but provides no explicit guidance on when to use it versus alternatives (e.g., 'open_nodes' for retrieving specific nodes). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: creating vs adding to entities, deleting specific types, reading graph, searching, etc. No overlapping functionality.
All tool names follow a consistent verb_noun snake_case pattern (e.g., add_observations, create_entities, read_graph), making it predictable.
11 tools is a well-scoped set for a knowledge graph server, covering CRUD for entities, relations, observations, plus admin operations like status and import.
Core operations are present, but missing update operations for entities, observations, and relations (though add_observations and delete_observations allow workarounds).
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP memory server. One memory your agents share — across models, devices and apps.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/arpanroy41/nexmem-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
