Skip to main content
Glama
iAchilles

Memento

by iAchilles
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

Memento

Some memories are best persisted.

Provides persistent memory capabilities through a SQLite-based knowledge graph that stores entities, observations, and relationships with semantic search using BGE-M3 embeddings for intelligent context retrieval across conversations.

Features

  • Semantic vector search (sqlite-vec/pgvector, 1024d)

  • Offline embedding model (bge-m3)

  • Modular repository layer with SQLite and PostgreSQL backends

  • Enhanced Relevance Scoring with temporal, popularity, contextual, and importance factors

  • Structured graph of entities, observations, and relations

  • Easy integration with Claude Desktop (via MCP)

Related MCP server: Engram

Prerequisites

System SQLite Version Check

Memento requires SQLite 3.38+. Most macOS and Linux distros ship sqlite3 out of the box, but double-check that it's there and new enough:

sqlite3 --version       # should print a version string, e.g. 3.46.0

Important Note: This check is just to verify SQLite is installed on your system. Memento does NOT use the sqlite3 CLI for its operation it uses the Node.js sqlite3 module internally.

If you see "command not found" (or your version is older than 3.38), install SQLite:

Platform

Install command

macOS (Homebrew)

brew install sqlite

Debian / Ubuntu

sudo apt update && sudo apt install sqlite3

Configuration

Memento now supports pluggable storage backends. Configuration is controlled entirely through environment variables so it remains easy to embed inside MCP workflows.

Variable

Description

MEMORY_DB_DRIVER

Optional selector for the database backend. Defaults to sqlite. Set to postgres to enable the PostgreSQL manager.

MEMORY_DB_PATH

Filesystem path for the SQLite database file (only used when the driver is sqlite).

SQLITE_VEC_PATH

Optional absolute path to a pre-built sqlite-vec extension shared library.

MEMORY_DB_DSN / DATABASE_URL

PostgreSQL connection string consumed by the pg client.

PGHOST, PGPORT, PGUSER, PGPASSWORD, PGDATABASE

Individual PostgreSQL connection parameters. Used when no DSN is provided.

PGSSLMODE

When set to require, SSL will be enabled with rejectUnauthorized: false.

MEMENTO_WRITE_HOOK_PATH

Optional path to a JSON Lines file. When set, Memento appends one event after each successful graph mutation.

Write hook events

Set MEMENTO_WRITE_HOOK_PATH when another process needs to react to memory writes without polling the full graph:

MEMENTO_WRITE_HOOK_PATH=/tmp/memento-events.jsonl memento

Each line is a JSON object with an ISO timestamp, an operation, and the changed entity/relation payload. Example:

{"timestamp":"2026-05-05T16:33:16.619Z","operation":"create_entity","entity":{"name":"Hook Test","entityType":"test"}}

Supported operations are create_entity, add_observations, create_relation, delete_entities, delete_relations, delete_observations, and set_importance. Delete events are emitted only for records that were actually removed.

Hook write failures are logged to stderr but do not fail the graph mutation that already succeeded. Consumers that require strict reconciliation should combine the hook with occasional read_graph or targeted open_nodes checks.

PostgreSQL notes

  • The PostgreSQL manager requires the pgvector extension. It is automatically initialized with CREATE EXTENSION IF NOT EXISTS vector.

Claude Desktop:

{
  "mcpServers": {
    "memory": {
      "description": "Custom memory backed by SQLite + vec + FTS5",
      "command": "npx",
      "args": [
        "@iachilles/memento@latest"
      ],
      "env": {
        "MEMORY_DB_PATH": "/Path/To/Your/memory.db"
      },
      "options": {
        "autoStart": true,
        "restartOnCrash": true
      }
    }
  }
}

Troubleshooting

sqlite-vec Extension Issues

Important: Memento loads the sqlite-vec extension programmatically through Node.js, NOT through the sqlite3 CLI.

Common misconceptions:

  • ❌ Creating shell aliases for sqlite3 CLI won't affect Memento

  • ❌ Loading extensions in sqlite3 CLI won't help Memento

  • ✅ Use the npm-installed sqlite-vec or set SQLITE_VEC_PATH environment variable if automatic detection fails. This should point to the Node.js-compatible version of the extension, typically found in your node_modules directory.

If automatic vec loading fails:

# Find the Node.js-compatible vec extension
find node_modules -name "vec0.dylib"  # macOS
find node_modules -name "vec0.so"     # Linux

# Use it via environment variable
SQLITE_VEC_PATH="/full/path/to/node_modules/sqlite-vec-darwin-x64/vec0.dylib" memento

API Overview

This server exposes the following MCP tools:

  • create_entities

  • create_relations

  • add_observations

  • delete_entities

  • delete_relations

  • delete_observations

  • read_graph

  • search_nodes

  • open_nodes

  • set_importance - Set importance level (critical/important/normal/temporary/deprecated)

When MEMENTO_WRITE_HOOK_PATH is configured, mutating tools also append JSONL write events for downstream consumers.

An example of an instruction set that an LLM should know for effective memory handling (see MEMORY_PROTOCOL.md)

Embedding Model

This project uses @xenova/transformers, with a quantized version of bge-m3, running fully offline in Node.js.

License

MIT

Available Tools

10 tools
add_observationsB

Add text observations to existing entities and index them for full-text and semantic search.

ParametersJSON Schema
NameRequiredDescriptionDefault
observationsYesList of {entityName, contents} pairs.

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits. It mentions indexing for search, which is helpful, but fails to disclose side effects such as whether observations are additive or overwriting, what happens if the entity does not exist, or any error conditions. The behavior beyond addition is unclear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 15 words, efficiently conveying the core action and a key feature (indexing). Every word serves a purpose, and no redundant or irrelevant information is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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 or annotations, the description provides sufficient context for basic use but lacks details on error handling, idempotency, or return behavior. It is minimally viable but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the schema already documents the parameters well. The description does not add extra meaning beyond the schema; it merely describes the tool's function. Baseline 3 is appropriate as no additional semantics are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'add' and the resource 'text observations to existing entities', and adds context about indexing for search. It distinguishes from sibling tools like delete_observations and create_entities, though it could be more explicit about the 'existing entities' requirement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when adding text observations to entities that already exist, but it does not explicitly state when to use it versus alternatives, nor does it provide conditions or exclusions. There is no guidance on prerequisites or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_entitiesA

Create entities in the knowledge graph. Inserts each entity if not exists and optionally seeds it with observations.

ParametersJSON Schema
NameRequiredDescriptionDefault
entitiesYesArray of entities to create.

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavior. It mentions creation, existence check, and optional observation seeding, but omits details on error handling, return values, or side effects (e.g., what happens if an entity already exists).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences convey the core purpose and key behavior with no unnecessary words. Every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity (array of objects) and absence of output schema, the description covers basic purpose and behavior but lacks details on return values, errors, and relations to sibling tools. 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.

Parameters4/5

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 value by explaining the 'observations' parameter ('optionally seeds it with observations'), which goes beyond the schema's default description. This clarifies how the parameter is used.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create entities') and the resource ('knowledge graph'), distinguishing it from sibling tools like 'create_relations' or 'delete_entities'. However, it does not explicitly differentiate from similar creation tools or clarify limitations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies idempotent behavior ('if not exists') but provides no explicit guidance on when to use this tool versus alternatives like 'add_observations' or 'create_relations'. No when-not-to-use cues are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_relationsB

Create directed relations between entities. Skips existing relations.

ParametersJSON Schema
NameRequiredDescriptionDefault
relationsYesArray of relations to create.

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must fully disclose behavioral traits. It only mentions that existing relations are skipped, but it does not state whether the tool is idempotent, what happens on duplicate attempts, or any side effects. Important mutation details are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two clear sentences. It is front-loaded with the core purpose. While it could be slightly more structured, it contains no wasteful content and is easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter with full schema coverage and no output schema, the description is adequate. However, it does not explain the return value or error handling, and with multiple sibling tools, more context about when to use it would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema describes all parameters with full coverage (100%), so the description does not need to add parameter details. The description adds no further meaning to the parameters beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (create), the resource (directed relations), and the scope (between entities). It also adds the behavior of skipping existing relations, which is specific and helpful. This distinguishes it from sibling tools like create_entities or delete_relations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 add_observations or delete_relations. There is no indication of prerequisites, when not to use, or how it fits into a workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_entitiesB

Delete entities (and cascaded observations/relations) by their names.

ParametersJSON Schema
NameRequiredDescriptionDefault
entityNamesYesNames of entities to delete.

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. While it mentions cascading deletions, it fails to disclose that this is a destructive irreversible operation, potential authorization requirements, 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with the action and scope. However, it could be slightly more structured (e.g., listing effects) without adding verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema or annotations, the description is minimally adequate but lacks details about return values, error conditions, or confirmation of deletion.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the parameter description in the schema is minimal ('Names of entities to delete.'). The description adds the context of 'by their names' but no additional constraints or format expectations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Delete' and the resource 'entities' with the specific detail of cascading to observations/relations. This distinguishes it from sibling tools like delete_observations 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.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use the tool versus alternatives. Given the existence of more specific deletion tools for observations and relations, the description should clarify when to choose this tool over those.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_observationsB

Remove specific observations from entities by matching text.

ParametersJSON Schema
NameRequiredDescriptionDefault
deletionsYesList of {entityName, observations} deletion requests.

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior fully. It only states deletion by matching text, but omits details such as whether the operation is permanent, what happens if observations are not found, or if any permissions are required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, concise sentence that front-loads the key action and resource, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool, the description covers the basic purpose but lacks details on expected behavior (e.g., failure handling, batch scope). It is adequate for a minimalist tool but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents parameters adequately. The description adds that deletion is 'by matching text,' which aligns with the schema's 'exact observation texts,' but does not provide significant new information beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (Remove), the resource (specific observations), and the method (matching text). It is easily distinguishable from sibling tools like add_observations or delete_entities, though it does not explicitly reference them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 delete_entities or delete_relations, nor are there any prerequisites or context for its appropriate use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_relationsA

Remove specified relations between entities without deleting the entities themselves.

ParametersJSON Schema
NameRequiredDescriptionDefault
relationsYesArray of relations to delete.

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description adds the key behavioral note that entities are not deleted. However, it lacks details on reversibility, failure modes, or side effects, which are important for a deletion operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, 12 words, immediate clarity. No extraneous information – every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple deletion tool with a single parameter, but lacks context on underlying behavior, error handling, or output. Given no output schema or annotations, more detail would help.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides full descriptions for the relations array and its nested properties (from, to, relationType). The description adds no additional parameter information beyond what's in the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool removes relations without deleting entities, distinguishing it from sibling delete_entities. The verb ('Remove') and resource ('relations') are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 create_relations or delete_entities. The distinction from entity deletion is implied but not elaborated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

open_nodesA

Expand specified entities: return their full details including observations and relations.

ParametersJSON Schema
NameRequiredDescriptionDefault
namesYesNames of entities to expand.

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It states that the tool returns full details including observations and relations, which implies a read operation. However, it does not explicitly confirm read-only behavior, absence of side effects, or any required permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that communicates the purpose and output concisely. Every word is necessary, and no extraneous information is included.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is adequate. It explains the action and return content. However, it could mention whether the tool is read-only or has any limitations, but given the low complexity, completeness is high.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage with a description for the 'names' parameter. The tool description adds context by explaining that expansion returns full details including observations and relations, which goes beyond the schema's 'Names of entities to expand'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's action: expanding entities and returning full details including observations and relations. It distinguishes itself from siblings like 'read_graph' (reads entire graph) and 'search_nodes' (searches) by focusing on specific entities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you have entity names and want their details, but it does not explicitly state when to use this tool over alternatives like 'read_graph' or 'search_nodes'. No when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_graphA

Retrieve the entire knowledge graph: all entities with their observations and relations.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so description carries full burden. It correctly implies read-only behavior, but lacks disclosure of potential performance impacts for large graphs or any rate limits. Adequate but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, 12 words, with no fluff. Perfectly front-loaded and concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description could elaborate on the return format (structure of entities, observations, relations). It is adequate for a simple retrieval but incomplete for an agent to fully anticipate the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist. Schema coverage is 100%, and the description adds no parameter info, which is appropriate since there are none. Baseline for 0 parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it retrieves the entire knowledge graph with all entities, observations, and relations. This distinguishes it from sibling tools like search_nodes (filtered) and create/delete operations (mutating).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 such as search_nodes or open_nodes. No mention of context, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_nodesC

Search for entities and relations by semantic similarity.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query string.
topKNoMax number of results to return.
thresholdNoDistance threshold for semantic filtering.

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions 'semantic similarity' but does not explain how it works, whether it is read-only, or what the threshold and topK parameters affect behaviorally. Critical context missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise and front-loaded. However, it sacrifices necessary detail for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description should provide more context about return format, ordering, and behavior. It is incomplete for a 3-parameter search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline 3 is appropriate. The description does not add any extra meaning beyond what the schema already provides for the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for entities and relations by semantic similarity, which is specific. However, it does not explicitly differentiate from sibling tools like 'open_nodes' or 'read_graph', though those are not search tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites or scenarios where other tools would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_importanceB

Set the importance level for an entity (critical, important, normal, temporary, deprecated).

ParametersJSON Schema
NameRequiredDescriptionDefault
entityNameYesName of the entity.
importanceYesImportance level for the entity.

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must convey behavioral traits. It indicates a write operation but lacks details on whether importance is overwritten, if the entity must exist, or if there are side effects. The description only restates the action and enum values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 14 words, which is concise and front-loaded. It effectively states the purpose without extraneous words, though it could potentially be slightly more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple nature of the tool (two required parameters, no output schema), the description is adequate but omits context like whether the tool is idempotent, what happens if the entity doesn't exist, or return behavior. It covers the basics but not fully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds the enumeration list which is already in the schema, providing no additional semantic value beyond what is already defined.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Set' and the resource 'importance level for an entity', and provides the allowable enum values, distinguishing it from sibling tools which handle different operations like adding observations or deleting entities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 create_entities or update_entity attributes. There is no mention of prerequisites or conditions that would help an agent decide to invoke this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • Removedadd_tags
    • Changedread_graph1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedsearch_nodes1 field changed
      • removedInput schema / properties / mode
        Removed value: -{
-  "default": "keyword",
-  "description": "Search mode to use.",
-  "enum": [
-    "keyword",
-    "semantic",
-    "hybrid"
-  ],
-  "type": "string"
-}
  2. 11 tool updates
    • First observedadd_observations
    • First observedadd_tags
    • First observedcreate_entities
    • First observedcreate_relations
    • First observeddelete_entities
    • First observeddelete_observations
    • First observeddelete_relations
    • First observedopen_nodes
    • First observedread_graph
    • First observedsearch_nodes
    • First observedset_importance
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool targets a distinct operation: create entities, relations, and observations; read via open_nodes, read_graph, and search_nodes; update via add_observations and set_importance; delete for entities, observations, and relations. No overlap exists.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_entities, delete_observations, search_nodes). No deviations or mixed styles.

Tool Count5/5

10 tools is well-scoped for a knowledge graph management server, covering all essential operations without redundancy. The number is within the ideal range (3-15).

Completeness4/5

The toolset covers CRUD for entities, observations, and relations, plus search and importance setting. Minor gaps exist: no update for entity properties (beyond importance) and no update for relations, but core workflows are complete.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • tartarus-mcp

    saluca-labs
    A
    license
    Not graded
    quality
    C
    maintenance
    A local-first MCP memory server providing persistent, searchable memory for AI agents, powered by SQLite.
    6
    1
    Apache 2.0

  • Engram

    Kalyan-Deva
    A
    license
    Not graded
    quality
    B
    maintenance
    A local-first memory MCP server that enables storing, searching, and managing personal memories with hybrid keyword and semantic recall, all on-device.
    21
    MIT

  • heropen

    Koradji77
    A
    license
    Not graded
    quality
    B
    maintenance
    A local memory server for AI agents that stores and retrieves information via MCP, keeping all data in SQLite on your machine.
    1
    Apache 2.0

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/iAchilles/memento'

If you have feedback or need assistance with the MCP directory API, please join our Discord server