Memento MCP is a high-performance knowledge graph memory system for LLMs that enables semantic retrieval, contextual recall, and temporal awareness.
Key capabilities:
Entity Management: Create, retrieve, update, and delete entities with properties like name, type, observations, and metadata
Relation Management: Create, update, and delete relationships between entities with properties like strength and confidence
Graph Operations: Read the entire knowledge graph, search for nodes, and retrieve specific entities by name
Semantic Search: Search entities using vector embeddings and semantic similarity with configurable parameters
Temporal Features: Retrieve entity/relationship history, view graph state at specific timestamps, and apply time-decay to confidence values
Debugging Tools: Analyze embedding configuration and diagnose vector search operations
Enables GitHub Copilot to access the persistent knowledge graph memory system through the model context protocol.
Uses Neo4j as the storage backend for the knowledge graph, providing unified graph storage and vector search capabilities.
Leverages OpenAI's embedding models for semantic search capabilities, supporting multiple models including text-embedding-3-small/large.
Click on "Deploy 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., "@memento-mcp find all people who work at Anthropic and speak Spanish"
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.
Scalable, high performance knowledge graph memory system with semantic retrieval, contextual recall, and temporal awareness. Provides any LLM client that supports the model context protocol (e.g., Claude Desktop, Cursor, Github Copilot) with resilient, adaptive, and persistent long-term ontological memory.
Entities are the primary nodes in the knowledge graph. Each entity has:
A unique name (identifier)
An entity type (e.g., "person", "organization", "event")
A list of observations
Vector embeddings (for semantic search)
Complete version history
Example:
{
"name": "John_Smith",
"entityType": "person",
"observations": ["Speaks fluent Spanish"]
}Relations define directed connections between entities with enhanced properties:
Strength indicators (0.0-1.0)
Confidence levels (0.0-1.0)
Rich metadata (source, timestamps, tags)
Temporal awareness with version history
Time-based confidence decay
Example:
{
"from": "John_Smith",
"to": "Anthropic",
"relationType": "works_at",
"strength": 0.9,
"confidence": 0.95,
"metadata": {
"source": "linkedin_profile",
"last_verified": "2025-03-21"
}
}Related MCP server: Graph Memory MCP
Memento MCP uses Neo4j as its storage backend, providing a unified solution for both graph storage and vector search capabilities.
Unified Storage: Consolidates both graph and vector storage into a single database
Native Graph Operations: Built specifically for graph traversal and queries
Integrated Vector Search: Vector similarity search for embeddings built directly into Neo4j
Scalability: Better performance with large knowledge graphs
Simplified Architecture: Clean design with a single database for all operations
Neo4j 5.13+ (required for vector search capabilities)
The easiest way to get started with Neo4j is to use Neo4j Desktop:
Download and install Neo4j Desktop from https://neo4j.com/download/
Create a new project
Add a new database
Set password to memento_password (or your preferred password)
Start the database
The Neo4j database will be available at:
Bolt URI: bolt://127.0.0.1:7687 (for driver connections)
HTTP: http://127.0.0.1:7474 (for Neo4j Browser UI)
Default credentials: username: neo4j, password: memento_password (or whatever you configured)
Alternatively, you can use Docker Compose to run Neo4j:
# Start Neo4j container
docker-compose up -d neo4j
# Stop Neo4j container
docker-compose stop neo4j
# Remove Neo4j container (preserves data)
docker-compose rm neo4jWhen using Docker, the Neo4j database will be available at:
Bolt URI: bolt://127.0.0.1:7687 (for driver connections)
HTTP: http://127.0.0.1:7474 (for Neo4j Browser UI)
Default credentials: username: neo4j, password: memento_password
Neo4j data persists across container restarts and even version upgrades due to the Docker volume configuration in the docker-compose.yml file:
volumes:
- ./neo4j-data:/data
- ./neo4j-logs:/logs
- ./neo4j-import:/importThese mappings ensure that:
/data directory (contains all database files) persists on your host at ./neo4j-data
/logs directory persists on your host at ./neo4j-logs
/import directory (for importing data files) persists at ./neo4j-import
You can modify these paths in your docker-compose.yml file to store data in different locations if needed.
You can change Neo4j editions and versions without losing data:
Update the Neo4j image version in docker-compose.yml
Restart the container with docker-compose down && docker-compose up -d neo4j
Reinitialize the schema with npm run neo4j:init
The data will persist through this process as long as the volume mappings remain the same.
If you need to completely reset your Neo4j database:
# Stop the container
docker-compose stop neo4j
# Remove the container
docker-compose rm -f neo4j
# Delete the data directory contents
rm -rf ./neo4j-data/*
# Restart the container
docker-compose up -d neo4j
# Reinitialize the schema
npm run neo4j:initTo back up your Neo4j data, you can simply copy the data directory:
# Make a backup of the Neo4j data
cp -r ./neo4j-data ./neo4j-data-backup-$(date +%Y%m%d)Memento MCP includes command-line utilities for managing Neo4j operations:
Test the connection to your Neo4j database:
# Test with default settings
npm run neo4j:test
# Test with custom settings
npm run neo4j:test -- --uri bolt://127.0.0.1:7687 --username myuser --password mypass --database neo4jFor normal operation, Neo4j schema initialization happens automatically when Memento MCP connects to the database. You don't need to run any manual commands for regular usage.
The following commands are only necessary for development, testing, or advanced customization scenarios:
# Initialize with default settings (only needed for development or troubleshooting)
npm run neo4j:init
# Initialize with custom vector dimensions
npm run neo4j:init -- --dimensions 768 --similarity euclidean
# Force recreation of all constraints and indexes
npm run neo4j:init -- --recreate
# Combine multiple options
npm run neo4j:init -- --vector-index custom_index --dimensions 384 --recreateFind semantically related entities based on meaning rather than just keywords:
Vector Embeddings: Entities are automatically encoded into high-dimensional vector space using OpenAI's embedding models
Cosine Similarity: Find related concepts even when they use different terminology
Configurable Thresholds: Set minimum similarity scores to control result relevance
Cross-Modal Search: Query with text to find relevant entities regardless of how they were described
Multi-Model Support: Compatible with multiple embedding models (OpenAI text-embedding-3-small/large)
Contextual Retrieval: Retrieve information based on semantic meaning rather than exact keyword matches
Optimized Defaults: Tuned parameters for balance between precision and recall (0.6 similarity threshold, hybrid search enabled)
Hybrid Search: Combines semantic and keyword search for more comprehensive results
Adaptive Search: System intelligently chooses between vector-only, keyword-only, or hybrid search based on query characteristics and available data
Performance Optimization: Prioritizes vector search for semantic understanding while maintaining fallback mechanisms for resilience
Query-Aware Processing: Adjusts search strategy based on query complexity and available entity embeddings
Track complete history of entities and relations with point-in-time graph retrieval:
Full Version History: Every change to an entity or relation is preserved with timestamps
Point-in-Time Queries: Retrieve the exact state of the knowledge graph at any moment in the past
Change Tracking: Automatically records createdAt, updatedAt, validFrom, and validTo timestamps
Temporal Consistency: Maintain a historically accurate view of how knowledge evolved
Non-Destructive Updates: Updates create new versions rather than overwriting existing data
Time-Based Filtering: Filter graph elements based on temporal criteria
History Exploration: Investigate how specific information changed over time
Relations automatically decay in confidence over time based on configurable half-life:
Time-Based Decay: Confidence in relations naturally decreases over time if not reinforced
Configurable Half-Life: Define how quickly information becomes less certain (default: 30 days)
Minimum Confidence Floors: Set thresholds to prevent over-decay of important information
Decay Metadata: Each relation includes detailed decay calculation information
Non-Destructive: Original confidence values are preserved alongside decayed values
Reinforcement Learning: Relations regain confidence when reinforced by new observations
Reference Time Flexibility: Calculate decay based on arbitrary reference times for historical analysis
Rich metadata support for both entities and relations with custom fields:
Source Tracking: Record where information originated (user input, analysis, external sources)
Confidence Levels: Assign confidence scores (0.0-1.0) to relations based on certainty
Relation Strength: Indicate importance or strength of relationships (0.0-1.0)
Temporal Metadata: Track when information was added, modified, or verified
Custom Tags: Add arbitrary tags for classification and filtering
Structured Data: Store complex structured data within metadata fields
Query Support: Search and filter based on metadata properties
Extensible Schema: Add custom fields as needed without modifying the core data model
The following tools are available to LLM client hosts through the Model Context Protocol:
create_entities
Create multiple new entities in the knowledge graph
Input: entities (array of objects)
Each object contains:
name (string): Entity identifier
entityType (string): Type classification
observations (string[]): Associated observations
add_observations
Add new observations to existing entities
Input: observations (array of objects)
Each object contains:
entityName (string): Target entity
contents (string[]): New observations to add
delete_entities
Remove entities and their relations
Input: entityNames (string[])
delete_observations
Remove specific observations from entities
Input: deletions (array of objects)
Each object contains:
entityName (string): Target entity
observations (string[]): Observations to remove
create_relations
Create multiple new relations between entities with enhanced properties
Input: relations (array of objects)
Each object contains:
from (string): Source entity name
to (string): Target entity name
relationType (string): Relationship type
strength (number, optional): Relation strength (0.0-1.0)
confidence (number, optional): Confidence level (0.0-1.0)
metadata (object, optional): Custom metadata fields
get_relation
Get a specific relation with its enhanced properties
Input:
from (string): Source entity name
to (string): Target entity name
relationType (string): Relationship type
update_relation
Update an existing relation with enhanced properties
Input: relation (object):
Contains:
from (string): Source entity name
to (string): Target entity name
relationType (string): Relationship type
strength (number, optional): Relation strength (0.0-1.0)
confidence (number, optional): Confidence level (0.0-1.0)
metadata (object, optional): Custom metadata fields
delete_relations
Remove specific relations from the graph
Input: relations (array of objects)
Each object contains:
from (string): Source entity name
to (string): Target entity name
relationType (string): Relationship type
read_graph
Read the entire knowledge graph
No input required
search_nodes
Search for nodes based on query
Input: query (string)
open_nodes
Retrieve specific nodes by name
Input: names (string[])
semantic_search
Search for entities semantically using vector embeddings and similarity
Input:
query (string): The text query to search for semantically
limit (number, optional): Maximum results to return (default: 10)
min_similarity (number, optional): Minimum similarity threshold (0.0-1.0, default: 0.6)
entity_types (string[], optional): Filter results by entity types
hybrid_search (boolean, optional): Combine keyword and semantic search (default: true)
semantic_weight (number, optional): Weight of semantic results in hybrid search (0.0-1.0, default: 0.6)
Features:
Intelligently selects optimal search method (vector, keyword, or hybrid) based on query context
Gracefully handles queries with no semantic matches through fallback mechanisms
Maintains high performance with automatic optimization decisions
get_entity_embedding
Get the vector embedding for a specific entity
Input:
entity_name (string): The name of the entity to get the embedding for
get_entity_history
Get complete version history of an entity
Input: entityName (string)
get_relation_history
Get complete version history of a relation
Input:
from (string): Source entity name
to (string): Target entity name
relationType (string): Relationship type
get_graph_at_time
Get the state of the graph at a specific timestamp
Input: timestamp (number): Unix timestamp (milliseconds since epoch)
get_decayed_graph
Get graph with time-decayed confidence values
Input: options (object, optional):
reference_time (number): Reference timestamp for decay calculation (milliseconds since epoch)
decay_factor (number): Optional decay factor override
Configure Memento MCP with these environment variables:
# Neo4j Connection Settings
NEO4J_URI=bolt://127.0.0.1:7687
NEO4J_USERNAME=neo4j
NEO4J_PASSWORD=memento_password
NEO4J_DATABASE=neo4j
# Vector Search Configuration
NEO4J_VECTOR_INDEX=entity_embeddings
NEO4J_VECTOR_DIMENSIONS=1536
NEO4J_SIMILARITY_FUNCTION=cosine
# Embedding Service Configuration
MEMORY_STORAGE_TYPE=neo4j
OPENAI_API_KEY=your-openai-api-key
OPENAI_EMBEDDING_MODEL=text-embedding-3-small
# Debug Settings
DEBUG=trueThe Neo4j CLI tools support the following options:
--uri <uri> Neo4j server URI (default: bolt://127.0.0.1:7687)
--username <username> Neo4j username (default: neo4j)
--password <password> Neo4j password (default: memento_password)
--database <n> Neo4j database name (default: neo4j)
--vector-index <n> Vector index name (default: entity_embeddings)
--dimensions <number> Vector dimensions (default: 1536)
--similarity <function> Similarity function (cosine|euclidean) (default: cosine)
--recreate Force recreation of constraints and indexes
--no-debug Disable detailed output (debug is ON by default)Available OpenAI embedding models:
text-embedding-3-small: Efficient, cost-effective (1536 dimensions)
text-embedding-3-large: Higher accuracy, more expensive (3072 dimensions)
text-embedding-ada-002: Legacy model (1536 dimensions)
To use semantic search, you'll need to configure OpenAI API credentials:
Obtain an API key from OpenAI
Configure your environment with:
# OpenAI API Key for embeddings
OPENAI_API_KEY=your-openai-api-key
# Default embedding model
OPENAI_EMBEDDING_MODEL=text-embedding-3-smallNote: For testing environments, the system will mock embedding generation if no API key is provided. However, using real embeddings is recommended for integration testing.
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"memento": {
"command": "npx",
"args": ["-y", "@gannonh/memento-mcp"],
"env": {
"MEMORY_STORAGE_TYPE": "neo4j",
"NEO4J_URI": "bolt://127.0.0.1:7687",
"NEO4J_USERNAME": "neo4j",
"NEO4J_PASSWORD": "memento_password",
"NEO4J_DATABASE": "neo4j",
"NEO4J_VECTOR_INDEX": "entity_embeddings",
"NEO4J_VECTOR_DIMENSIONS": "1536",
"NEO4J_SIMILARITY_FUNCTION": "cosine",
"OPENAI_API_KEY": "your-openai-api-key",
"OPENAI_EMBEDDING_MODEL": "text-embedding-3-small",
"DEBUG": "true"
}
}
}
}Alternatively, for local development, you can use:
{
"mcpServers": {
"memento": {
"command": "/path/to/node",
"args": ["/path/to/memento-mcp/dist/index.js"],
"env": {
"MEMORY_STORAGE_TYPE": "neo4j",
"NEO4J_URI": "bolt://127.0.0.1:7687",
"NEO4J_USERNAME": "neo4j",
"NEO4J_PASSWORD": "memento_password",
"NEO4J_DATABASE": "neo4j",
"NEO4J_VECTOR_INDEX": "entity_embeddings",
"NEO4J_VECTOR_DIMENSIONS": "1536",
"NEO4J_SIMILARITY_FUNCTION": "cosine",
"OPENAI_API_KEY": "your-openai-api-key",
"OPENAI_EMBEDDING_MODEL": "text-embedding-3-small",
"DEBUG": "true"
}
}
}
}Important: Always explicitly specify the embedding model in your Claude Desktop configuration to ensure consistent behavior.
For optimal integration with Claude, add these statements to your system prompt:
You have access to the Memento MCP knowledge graph memory system, which provides you with persistent memory capabilities.
Your memory tools are provided by Memento MCP, a sophisticated knowledge graph implementation.
When asked about past conversations or user information, always check the Memento MCP knowledge graph first.
You should use semantic_search to find relevant information in your memory when answering questions.Once configured, Claude can access the semantic search capabilities through natural language:
To create entities with semantic embeddings:
User: "Remember that Python is a high-level programming language known for its readability and JavaScript is primarily used for web development."To search semantically:
User: "What programming languages do you know about that are good for web development?"To retrieve specific information:
User: "Tell me everything you know about Python."The power of this approach is that users can interact naturally, while the LLM handles the complexity of selecting and using the appropriate memory tools.
Memento's adaptive search capabilities provide practical benefits:
Query Versatility: Users don't need to worry about how to phrase questions - the system adapts to different query types automatically
Failure Resilience: Even when semantic matches aren't available, the system can fall back to alternative methods without user intervention
Performance Efficiency: By intelligently selecting the optimal search method, the system balances performance and relevance for each query
Improved Context Retrieval: LLM conversations benefit from better context retrieval as the system can find relevant information across complex knowledge graphs
For example, when a user asks "What do you know about machine learning?", the system can retrieve conceptually related entities even if they don't explicitly mention "machine learning" - perhaps entities about neural networks, data science, or specific algorithms. But if semantic search yields insufficient results, the system automatically adjusts its approach to ensure useful information is still returned.
Memento MCP includes built-in diagnostic capabilities to help troubleshoot vector search issues:
Embedding Verification: The system checks if entities have valid embeddings and automatically generates them if missing
Vector Index Status: Verifies that the vector index exists and is in the ONLINE state
Fallback Search: If vector search fails, the system falls back to text-based search
Detailed Logging: Comprehensive logging of vector search operations for troubleshooting
Additional diagnostic tools become available when debug mode is enabled:
diagnose_vector_search: Information about the Neo4j vector index, embedding counts, and search functionality
force_generate_embedding: Forces the generation of an embedding for a specific entity
debug_embedding_config: Information about the current embedding service configuration
To completely reset your Neo4j database during development:
# Stop the container (if using Docker)
docker-compose stop neo4j
# Remove the container (if using Docker)
docker-compose rm -f neo4j
# Delete the data directory (if using Docker)
rm -rf ./neo4j-data/*
# For Neo4j Desktop, right-click your database and select "Drop database"
# Restart the database
# For Docker:
docker-compose up -d neo4j
# For Neo4j Desktop:
# Click the "Start" button for your database
# Reinitialize the schema
npm run neo4j:init# Clone the repository
git clone https://github.com/gannonh/memento-mcp.git
cd memento-mcp
# Install dependencies
npm install
# Build the project
npm run build
# Run tests
npm test
# Check test coverage
npm run test:coverageTo install memento-mcp for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @gannonh/memento-mcp --client claudeYou can run Memento MCP directly using npx without installing it globally:
npx -y @gannonh/memento-mcpThis method is recommended for use with Claude Desktop and other MCP-compatible clients.
For development or contributing to the project:
# Install locally
npm install @gannonh/memento-mcp
# Or clone the repository
git clone https://github.com/gannonh/memento-mcp.git
cd memento-mcp
npm installMIT
Add new observations to existing entities in your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| observations | Yes | ||
| strength | No | Default strength value (0.0 to 1.0) for all observations | |
| confidence | No | Default confidence level (0.0 to 1.0) for all observations | |
| metadata | No | Default metadata for all observations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only restates the core action. It does not disclose behavior around non-existent entities, overwriting, errors, or side effects, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant content. It communicates the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a moderately rich schema, the tool has no annotations or output schema, and the description is too terse. It omits behavioral context (e.g., what happens if an entity doesn't exist, whether defaults apply) and return semantics, making it incomplete for a nested mutation 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 75%, and the schema already documents parameters like entityName, contents, metadata, strength, and confidence. The description adds no extra parameter-level nuance, but the schema provides enough meaning to warrant a baseline 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 uses a specific verb ('Add') and resource ('observations to existing entities'), clearly distinguishing it from sibling tools like create_entities or delete_observations. It also scopes the operation to existing entities, which is helpful.
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 phrase 'to existing entities' implies this is for attaching observations to already-created entities, but it does not explicitly mention alternatives or when not to use it. No exclusions or alternative tool names are given.
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 your Memento MCP knowledge graph memory system
| Name | Required | Description | Default |
|---|---|---|---|
| entities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavior such as idempotency, validation, limits, or side effects. For a mutation tool, this is insufficient; an agent cannot anticipate what happens on failure or whether existing entities are affected.
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 one sentence, concise and front-loaded. It avoids unnecessary words. However, it is so brief that it omits essential information, making it too minimal for a complex tool.
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 a nested entity array with many optional fields, but the description offers no guidance on the input structure or return behavior. There is no output schema, so the description carries full responsibility for explaining the tool's behavior, which it fails to do.
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 says nothing about the parameters; schema description coverage is 0%. While the schema itself contains detailed property descriptions, the tool description does not add any meaning beyond what is structured, failing to compensate for the low coverage.
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), the resource (multiple new entities), and the context (Memento MCP knowledge graph). This distinguishes it from sibling tools like create_relations or add_observations which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use this when you need to add new entities. However, it provides no explicit guidance on when to choose this over alternatives, nor any prerequisites or exclusions. For a create operation, the intent is straightforward, but the lack of any alternative comparison leaves room for ambiguity.
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 your Memento MCP knowledge graph memory. Relations should be in active voice
| Name | Required | Description | Default |
|---|---|---|---|
| relations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavior disclosure. It only states that relations are created, but does not mention idempotency, overwrite semantics, validation of entity existence, transactional behavior, or what happens on partial failure. The mutation effect is implied but no further behavioral context is given.
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 with no redundancy. It front-loads the core action and purpose, then adds a concise stylistic guideline. Every word earns its place, making it highly efficient for an 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?
This is a complex tool with a nested array of 13 fields, no annotations, and no output schema, yet the description offers only a high-level purpose. It lacks crucial context such as whether entities must already exist, how failures are handled, whether the operation is atomic, and what the tool returns. The sparse description is inadequate for an agent to use the tool safely and effectively.
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% for the top-level parameter, yet the description does not explain the array structure of 'relations' or the required fields. It adds the active voice requirement for relationType, which is helpful, but this only partially compensates. The nested schema descriptions exist but are not referenced or clarified by the tool description.
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) and the resource (between entities in the Memento MCP knowledge graph). It distinguishes from siblings like update_relation and delete_relations by focusing on creation, and the 'multiple' wording distinguishes it from any single-relation tool. The scope is unambiguous.
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 use for batch-creating relations ("multiple new relations"), but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or exclusions, though sibling tool names like update_relation suggest the contrast. The 'active voice' note is a formatting guideline, not a usage context.
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 your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| entityNames | Yes | An array of entity names to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose a key side effect: associated relations are also deleted. However, it does not mention what happens to observations attached to the entities, whether deletion is permanent, or any other side effects. This is a partial disclosure.
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 is front-loaded with the action and scope. Every word contributes meaning, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple one-parameter interface, the description covers the core operation, but it leaves ambiguity about the fate of observations and whether deletion is reversible. With no output schema and no annotations, these omissions prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes entityNames as 'An array of entity names to delete' (100% schema coverage). The description adds no additional meaning for the parameter, so the 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 uses a specific verb ('Delete') and identifies the resource ('multiple entities and their associated relations') within the Memento MCP knowledge graph. It clearly distinguishes this tool from siblings like delete_relations by noting the cascading 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 implies this tool should be used when both entities and their relations need to be deleted, versus using delete_relations separately. However, it does not explicitly state when to prefer this tool over alternatives, list exclusions, or mention prerequisites. The usage guidance is implied rather than explicit.
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 your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| deletions | Yes |
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 only states the action and does not disclose irreversibility, required permissions, partial failure behavior, or return format. The description adds no behavioral insight 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?
The description is a single, front-loaded sentence with no superfluous words. It efficiently communicates the core function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation tool with no annotations and no output schema. The description fails to mention side effects, irreversibility, prerequisites, or the exact parameter structure. The description is too minimal to fully support confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'deletions' with 0% top-level description coverage. The tool description hints at entities and observations, but it does not explain the array-of-objects structure or the required fields entityName and observations. The description provides minimal compensatory value for the schema gap.
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 target ('specific observations from entities'), making it distinct from sibling tools like delete_entities and delete_relations. It precisely identifies the resource and operation.
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 add_observations or delete_entities. It lacks context about prerequisites, exclusions, or conditions where this tool is preferred.
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 your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| relations | Yes | An array of relations to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without clarifying whether deletion is permanent, whether it is idempotent, or what response is returned. The word 'delete' implies mutation but lacks important safety and side-effect context.
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 concise sentence that front-loads the action and resource with no redundant or unnecessary information. Every word 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?
The description is minimal and lacks behavioral context for a destructive operation. It does not mention permanence, error handling, side effects, or return value expectations. With no output schema and no annotations, the description alone is insufficient for an agent to fully anticipate the operation's effects, especially given it is a delete action.
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 fully describes the single 'relations' parameter, including the nested fields from, to, and relationType, achieving 100% schema description coverage. The description adds no additional semantic meaning beyond what the schema already provides, 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 verb 'Delete' and the resource 'multiple relations' within the Memento knowledge graph, making the tool's function immediately obvious. It also distinguishes itself from sibling tools like delete_entities, which targets entities, and delete_observations, which targets 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 is provided on when to use this tool versus alternatives. It does not mention scenarios where this tool is preferred over delete_entities or when to avoid it, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your Memento MCP knowledge graph memory with confidence values decayed based on time
| Name | Required | Description | Default |
|---|---|---|---|
| reference_time | No | Optional reference timestamp (in milliseconds since epoch) for decay calculation | |
| decay_factor | No | Optional decay factor override (normally calculated from half-life) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states the core behavior—returning the knowledge graph with confidence values decayed by time—and the use of 'Get' implies a read-only operation. However, it does not elaborate on return format, potential side effects, or edge cases, though none are strongly suggested.
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 that conveys the essential purpose without any unnecessary words. Every phrase contributes to understanding the tool's function, making it highly concise and well-structured.
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 output schema and annotations, the description adequately conveys the main behavior and the optional override parameters. It is sufficient for a simple retrieval tool, though it could mention the default half-life calculation or the graph's composition (e.g., entities and relations).
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%, with both decay_factor and reference_time already described in the schema. The description adds only the context that decay is time-based but does not provide additional meaning beyond the parameter descriptions themselves, so it meets 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 uses a specific verb 'Get' with a clear resource 'Memento MCP knowledge graph memory' and specifies the unique aspect 'with confidence values decayed based on time'. This distinguishes it from sibling tools like get_graph_at_time, which focuses on temporal snapshots rather than confidence decay.
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 when time-decayed confidence values are needed, but it does not explicitly state when to use this tool versus alternatives like read_graph or get_graph_at_time. No exclusions or alternative recommendations are provided, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the vector embedding for a specific entity from your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| entity_name | Yes | The name of the entity to get the embedding for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states only that the tool 'gets' an embedding, implying a read operation, but does not disclose return format, error behavior, or any side effects. This is minimal beyond the basic 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?
The description is a single, concise sentence that front-loads the key action and resource. Every word contributes to clarity without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description provides adequate purpose but lacks completeness because no output schema exists, so return format is not described, and no usage guidelines or error behavior are mentioned. It is minimally viable but with clear 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?
The input schema fully describes the sole parameter (entity_name) at 100% coverage. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('the vector embedding for a specific entity') clearly distinguishing it from siblings like read_graph or get_entity_history. It precisely defines what the tool does.
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 (retrieve an embedding when needed) but does not explicitly mention when to use this tool over alternatives like semantic_search. No exclusions or alternatives are named, leaving usage guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the version history of an entity from your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| entityName | Yes | The name of the entity to retrieve history for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Get') without describing read-only nature, response format, pagination, or any limits. This is a minimal disclosure that does not inform the agent about what to expect 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?
The description is a single, well-structured sentence with no wasted words. It is appropriately concise and front-loaded with the key verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is minimally viable, but it lacks information about the return value (no output schema) and does not provide context on what 'version history' entails. Given the presence of siblings like get_relation_history, it could benefit from more contextual detail to guide the agent effectively.
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% (the only parameter entityName is fully described in the schema). The description adds no extra meaning beyond the schema, matching the baseline of 3 for full schema coverage.
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 with a specific verb ('Get') and resource ('version history of an entity'), distinguishing it from sibling tools like get_relation_history which target relations. The context 'from your Memento MCP knowledge graph memory' further clarifies scope.
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 for retrieving an entity's version history but provides no explicit guidance on when to use this tool versus alternatives like get_relation_history or get_graph_at_time. There is no mention of when not to use it or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your Memento MCP knowledge graph memory as it existed at a specific point in time
| Name | Required | Description | Default |
|---|---|---|---|
| timestamp | Yes | The timestamp (in milliseconds since epoch) to query the graph at |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only rephrases the tool name without adding operational details such as return format, potential side effects, timestamp validation, or performance implications. For a read operation, it is safe to assume non-destructiveness, but the description does not explicitly confirm or elaborate on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It earns its place by clearly stating the tool's purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and the description covers its core function. However, there is no output schema, and the description does not explain what the response contains (e.g., full graph snapshot, node/relation lists). This leaves minor ambiguity but is still adequate for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the timestamp parameter (100% coverage), so the description does not need to elaborate. It adds no parameter-specific semantics, but none are necessary given the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('knowledge graph memory') with a clear temporal qualifier ('as it existed at a specific point in time'). This distinguishes it from sibling tools like read_graph (current state) and get_decayed_graph (decay-based 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?
The description implies use for historical queries but does not explicitly contrast with alternatives such as read_graph or get_entity_history. The 'as it existed at a specific point in time' hints at the use case but leaves it to the agent to infer when to use this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific relation with its enhanced properties from your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | The name of the entity where the relation starts | |
| to | Yes | The name of the entity where the relation ends | |
| relationType | Yes | The type of the relation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only says 'get,' which implies a read-only operation, but it doesn't explicitly confirm safety, side effects, or prerequisites. The vague phrase 'enhanced properties' doesn't clarify behavior, leaving the agent to infer from the name alone.
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, concise sentence that communicates the tool's purpose without unnecessary words. It is front-loaded with the key action and resource, and every word 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?
Since there is no output schema, the description should explain what is returned, especially the vague 'enhanced properties.' It doesn't specify the response format, what 'enhanced' means, or whether any filtering or sorting applies. This is a significant gap for an agent needing to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters (from, to, relationType) with descriptions, and schema_description_coverage is 100%. The description adds no meaning beyond 'specific relation,' so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving a specific relation with enhanced properties from the Memento knowledge graph. It uses a specific verb ('get') and names the resource ('specific relation'), making it distinct from mutation or history tools like create_relations or get_relation_history, though it does not explicitly compare to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for retrieving a specific relation. It doesn't explicitly state when not to use it or mention alternatives, but the purpose is obvious enough for basic selection among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the version history of a relation from your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | The name of the entity where the relation starts | |
| to | Yes | The name of the entity where the relation ends | |
| relationType | Yes | The type of the relation |
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 of behavioral disclosure. It only says 'Get the version history', which implies a read operation but offers no details about return format, side effects, required permissions, or limitations. This is a significant gap for a tool without annotation support.
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 concise sentence of 15 words, front-loaded with the action 'Get the version history'. It wastes no words and is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the core purpose but omits details about the returned history structure or how it differs from entity history. With no output schema and no annotations, an agent may lack sufficient context to fully understand the tool's behavior, but the tool is a simple getter and the schema helps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters (from, to, relationType) with descriptions, achieving 100% coverage. The description adds no additional parameter meaning, so the 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 'Get the version history of a relation' with a specific verb and resource, and explicitly mentions 'history' to distinguish from the sibling tool get_relation which likely returns the current state. It also provides context that this is from the Memento MCP knowledge graph 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?
There is no guidance on when to use this tool instead of get_relation, get_entity_history, or other siblings. No alternatives or exclusions are mentioned. The description merely defines the action without contextual usage hints.
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 your Memento MCP knowledge graph memory by their names
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | An array of entity names to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It implies a read-like operation ('open') but does not explicitly state that it is non-destructive, what happens if names are not found, or whether it returns full node structures. This is a significant gap for a tool with no annotation support.
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, concise sentence that immediately conveys the action and target. It contains no fluff or redundant information, making it efficient and well-structured.
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 simple schema and no output schema, the description is minimally viable, but it lacks context about how this tool relates to siblings like read_graph or search_nodes. An agent may not know whether to use open_nodes for a full-graph read or for retrieving specific entities, leaving ambiguity in a larger tool ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter 'names' fully with a description ('An array of entity names to retrieve'), and the tool description reiterates this by saying 'by their names.' With 100% schema coverage, the baseline is 3, and the description adds no additional meaning 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: 'Open specific nodes' in the knowledge graph by name. The verb 'open' and resource 'nodes' are specific, and 'by their names' indicates a lookup operation. However, it does not explicitly distinguish from sibling tools like read_graph or search_nodes, so it misses full sibling differentiation.
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. It doesn't mention any prerequisites, exclusions, or context such as 'use search_nodes when you don't know exact names.' This leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the entire Memento MCP knowledge graph memory system
| Name | Required | Description | Default |
|---|---|---|---|
| random_string | No | Dummy parameter for no-parameter tools |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. 'Read' communicates a non-destructive operation and 'entire' indicates broad scope, but it does not disclose potential performance costs, response size, or exact return format, leaving some behavioral ambiguity.
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 that is front-loaded with the action and resource. Every word contributes to the meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-required-parameter graph read operation, the description adequately states scope and intent. The lack of an output schema is acceptable given the straightforward 'read entire graph' semantics, though a note on return format would make it slightly 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?
The schema fully describes the lone dummy parameter with 100% coverage, and the description adds no parameter-specific information. A baseline of 3 is appropriate because the schema already handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and identifies the resource as the 'entire Memento MCP knowledge graph memory system', making the tool's scope explicit. It clearly distinguishes this from sibling tools like search_nodes and get_graph_at_time, which imply filtered or temporal subsets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention that search_nodes or get_graph_at_time could be better for specific queries, nor does it state exclusions such as 'use only when you need the full graph'.
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 your Memento MCP knowledge graph memory based on a query
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to match against entity names, types, and observation content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the search is read-only, what it returns, or any limitations (e.g., pagination, scope). It only says 'search for nodes' without clarifying behavior beyond that obvious action, leaving the agent without safety or side-effect information.
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 redundant words. It communicates the essential purpose efficiently, earning its place without any waste. This is an ideal level of conciseness for a simple tool.
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 one parameter and no output schema, so complexity is low. However, the lack of annotations and absence of any usage guidance or behavioral context makes the description only minimally complete. It covers the basic purpose but omits important context like safety (read vs. write) and relationship to the sibling 'semantic_search' tool, leaving gaps for 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 description coverage is 100%, so the baseline is 3. The input schema already provides a clear description of the 'query' parameter ('match against entity names, types, and observation content'). The tool description adds no additional parameter semantics beyond what the schema already states, so it does not exceed 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 tool's function: 'Search for nodes in your Memento MCP knowledge graph memory based on a query.' It specifies a verb ('search'), a resource ('nodes'), and a mechanism ('based on a query'). However, it does not distinguish itself from the sibling tool 'semantic_search', which likely performs a similar function, so it misses the opportunity to differentiate.
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 for query-based search of nodes, but it does not provide explicit guidance on when to use this tool versus alternatives like 'semantic_search' or 'open_nodes'. There are no stated exclusions or alternative tool references, so the guidance is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for entities semantically using vector embeddings and similarity in your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The text query to search for semantically | |
| limit | No | Maximum number of results to return (default: 10) | |
| min_similarity | No | Minimum similarity threshold from 0.0 to 1.0 (default: 0.6) | |
| entity_types | No | Filter results by entity types | |
| hybrid_search | No | Whether to combine keyword and semantic search (default: true) | |
| semantic_weight | No | Weight of semantic results in hybrid search from 0.0 to 1.0 (default: 0.6) |
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 discloses the mechanism (vector embeddings and similarity) but does not state that the operation is read-only/non-destructive, nor does it mention any limitations, rate limits, or output behavior. The safety profile is not explicitly disclosed.
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, focused sentence that directly states the tool's purpose without extraneous information. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, no annotations, and no output schema, yet the description only provides the basic purpose. It lacks context on result format, default behaviors, or how this search integrates with the knowledge graph. The schema covers parameter details, but higher-level context is missing.
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 all six parameters with detailed explanations, so the description adds no additional parameter semantics beyond the schema. The 100% coverage supports the 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 defines the tool as a semantic search over Memento MCP entities using vector embeddings, making it distinct from the keyword-based sibling tools like search_nodes. The verb 'Search' and resource 'entities' are specific.
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 is for semantic queries but does not explicitly state when to use it over alternatives like search_nodes, nor does it mention any exclusions or crossover conditions. Without naming sibling tools, guidance is limited to the implied semantic use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing relation with enhanced properties in your Memento MCP knowledge graph memory
| Name | Required | Description | Default |
|---|---|---|---|
| relation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to declare safety or mutation, so the description carries full responsibility. It does not disclose what happens if the relation doesn't exist, whether the update is partial or full replacement, how versioning is handled, or if there are any validation constraints. The vague 'enhanced properties' adds no concrete behavioral detail.
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, grammatically correct sentence that is easy to parse. It is appropriately concise and front-loaded with the verb and object. It could be slightly more informative, but it contains 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 complexity of the nested 'relation' object with numerous optional fields, the lack of output schema, and no annotations, this description is too minimal. It fails to clarify critical update semantics such as which fields are required for identification, whether the operation is a partial merge or full replacement, and the meaning of 'enhanced properties'. The description alone is insufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter-level detail. 'Enhanced properties' gives a hint that the nested 'relation' object contains updates, but it does not explain which fields identify the relation versus which ones are updated. With low schema_description_coverage (0%), the description fails to compensate, despite the schema having well-documented fields.
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') and the resource ('existing relation'), and specifies the context ('Memento MCP knowledge graph memory'). It distinguishes itself from sibling tools like create_relations and delete_relations by intentionally targeting existing relations, and the 'enhanced properties' hints at additional attribute updates.
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 word 'existing' implies the relation must already be present, suggesting this is not for creation, but there is no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like delete and recreate, nor any prerequisites for updating a relation.
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.
add_observationscreate_entitiescreate_relationsdelete_entitiesdelete_observationsdelete_relationsget_decayed_graphget_entity_embeddingget_entity_historyget_graph_at_timeget_relationget_relation_historyopen_nodesread_graphsearch_nodessemantic_searchupdate_relationScored across 17 tools
Each tool has a clearly distinct purpose: CRUD operations for entities, relations, and observations are separated, and specialized tools for history, embeddings, and time-specific queries do not overlap. No ambiguity between tool functions.
All tool names follow a consistent verb_noun pattern (e.g., create_entities, delete_observations, get_entity_history). The naming is uniform and predictable, aiding agent selection.
With 17 tools, the count is slightly above the ideal 3-15 range but still well-scoped for a knowledge graph system. Each tool addresses a specific need, though a few could potentially be consolidated.
The tool surface covers most CRUD operations but lacks an update_entity tool and a dedicated get_entity (though open_nodes and read_graph partially fill this). Missing update for observations. These gaps may cause some workflow interruptions.
Company brain for AI agents — temporal knowledge graph search, exploration, and durable memory.
Persistent AI memory with semantic search, conflict detection, and ticketing.
Memory system for AI agents with semantic search. Store and recall memories with ease.
Shared long-term memory for AI agents: save and recall context as a searchable knowledge graph.
