의미 검색, 맥락적 회상, 시간 인식 기능을 갖춘 확장 가능하고 고성능의 지식 그래프 메모리 시스템입니다. 모델 맥락 프로토콜(예: Claude Desktop, Cursor, Github Copilot)을 지원하는 모든 LLM 클라이언트에 복원력, 적응성, 지속성을 갖춘 장기 온톨로지 메모리를 제공합니다.
엔티티는 지식 그래프의 주요 노드입니다. 각 엔티티는 다음을 갖습니다.
고유한 이름(식별자)
엔터티 유형(예: "사람", "조직", "이벤트")
관찰 목록
벡터 임베딩(의미 검색용)
전체 버전 기록
예:
지엑스피1
관계는 향상된 속성을 가진 엔터티 간의 방향성 연결을 정의합니다.
강도 지표(0.0-1.0)
신뢰 수준(0.0-1.0)
풍부한 메타데이터(소스, 타임스탬프, 태그)
버전 기록을 통한 시간 인식
시간 기반 신뢰도 감소
예:
{
"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는 Neo4j를 스토리지 백엔드로 사용하여 그래프 스토리지와 벡터 검색 기능을 위한 통합 솔루션을 제공합니다.
통합 스토리지 : 그래프와 벡터 스토리지를 단일 데이터베이스로 통합합니다.
네이티브 그래프 작업 : 그래프 탐색 및 쿼리를 위해 특별히 구축됨
통합 벡터 검색 : Neo4j에 직접 내장된 임베딩에 대한 벡터 유사성 검색
확장성 : 대규모 지식 그래프로 더 나은 성능 제공
단순화된 아키텍처 : 모든 작업을 위한 단일 데이터베이스를 갖춘 깔끔한 디자인
Neo4j 5.13+(벡터 검색 기능에 필요)
Neo4j를 시작하는 가장 쉬운 방법은 Neo4j Desktop을 사용하는 것입니다.
https://neo4j.com/download/ 에서 Neo4j Desktop을 다운로드하고 설치하세요.
새 프로젝트를 만듭니다
새로운 데이터베이스 추가
비밀번호를 memento_password (또는 원하는 비밀번호)로 설정하세요.
데이터베이스 시작
Neo4j 데이터베이스는 다음 위치에서 사용할 수 있습니다.
Bolt URI : bolt://127.0.0.1:7687 (드라이버 연결용)
HTTP : http://127.0.0.1:7474 (Neo4j 브라우저 UI용)
기본 자격 증명 : 사용자 이름: neo4j , 비밀번호: memento_password (또는 사용자가 구성한 것)
또는 Docker Compose를 사용하여 Neo4j를 실행할 수 있습니다.
# Start Neo4j container
docker-compose up -d neo4j
# Stop Neo4j container
docker-compose stop neo4j
# Remove Neo4j container (preserves data)
docker-compose rm neo4jDocker를 사용하면 Neo4j 데이터베이스를 다음 위치에서 사용할 수 있습니다.
Bolt URI : bolt://127.0.0.1:7687 (드라이버 연결용)
HTTP : http://127.0.0.1:7474 (Neo4j 브라우저 UI용)
기본 자격 증명 : 사용자 이름: neo4j , 비밀번호: memento_password
docker-compose.yml 파일의 Docker 볼륨 구성으로 인해 컨테이너를 다시 시작하거나 버전을 업그레이드해도 Neo4j 데이터는 그대로 유지됩니다.
volumes:
- ./neo4j-data:/data
- ./neo4j-logs:/logs
- ./neo4j-import:/import이러한 매핑은 다음을 보장합니다.
/data 디렉토리(모든 데이터베이스 파일 포함)는 호스트의 ./neo4j-data 에 저장됩니다.
/logs 디렉토리는 호스트의 ./neo4j-logs 에 저장됩니다.
/import 디렉토리(데이터 파일을 가져오기 위한)는 ./neo4j-import 에 저장됩니다.
필요한 경우 docker-compose.yml 파일에서 이러한 경로를 수정하여 다른 위치에 데이터를 저장할 수 있습니다.
데이터 손실 없이 Neo4j 에디션과 버전을 변경할 수 있습니다.
docker-compose.yml 에서 Neo4j 이미지 버전을 업데이트합니다.
docker-compose down && docker-compose up -d neo4j 로 컨테이너를 다시 시작합니다.
npm run neo4j:init 사용하여 스키마를 다시 초기화합니다.
볼륨 매핑이 동일하게 유지되는 한 이 프로세스에도 데이터가 유지됩니다.
Neo4j 데이터베이스를 완전히 재설정해야 하는 경우:
# 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:initNeo4j 데이터를 백업하려면 데이터 디렉토리를 복사하기만 하면 됩니다.
# Make a backup of the Neo4j data
cp -r ./neo4j-data ./neo4j-data-backup-$(date +%Y%m%d)Memento MCP에는 Neo4j 작업을 관리하기 위한 명령줄 유틸리티가 포함되어 있습니다.
Neo4j 데이터베이스에 대한 연결을 테스트하세요.
# 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 neo4j일반적인 작동의 경우, Memento MCP가 데이터베이스에 연결될 때 Neo4j 스키마 초기화가 자동으로 수행됩니다. 일반적인 사용 시에는 수동 명령을 실행할 필요가 없습니다.
다음 명령은 개발, 테스트 또는 고급 사용자 지정 시나리오에만 필요합니다.
# 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 --recreate키워드만이 아닌 의미를 기반으로 의미적으로 관련된 엔터티를 찾으세요.
벡터 임베딩 : 엔터티는 OpenAI의 임베딩 모델을 사용하여 고차원 벡터 공간에 자동으로 인코딩됩니다.
코사인 유사성 : 용어가 다르더라도 관련 개념을 찾습니다.
구성 가능한 임계값 : 결과 관련성을 제어하기 위한 최소 유사도 점수 설정
크로스 모달 검색 : 설명 방식에 관계없이 관련 엔터티를 찾기 위해 텍스트가 포함된 쿼리
다중 모델 지원 : 여러 임베딩 모델과 호환(OpenAI text-embedding-3-small/large)
문맥적 검색 : 정확한 키워드 일치보다는 의미적 의미에 따라 정보를 검색합니다.
최적화된 기본값 : 정밀도와 재현율 간의 균형을 위해 조정된 매개변수(0.6 유사도 임계값, 하이브리드 검색 활성화)
하이브리드 검색 : 의미 검색과 키워드 검색을 결합하여 더욱 포괄적인 결과를 제공합니다.
적응형 검색 : 시스템은 쿼리 특성과 사용 가능한 데이터를 기반으로 벡터 전용, 키워드 전용 또는 하이브리드 검색 중에서 지능적으로 선택합니다.
성능 최적화 : 복원력을 위한 대체 메커니즘을 유지하면서 의미적 이해를 위한 벡터 검색을 우선시합니다.
쿼리 인식 처리 : 쿼리 복잡성 및 사용 가능한 엔터티 임베딩을 기반으로 검색 전략을 조정합니다.
특정 시점의 그래프 검색을 통해 엔터티 및 관계의 전체 기록을 추적합니다.
전체 버전 기록 : 엔터티 또는 관계에 대한 모든 변경 사항은 타임스탬프와 함께 보존됩니다.
특정 시점 쿼리 : 과거 어느 시점의 지식 그래프의 정확한 상태를 검색합니다.
변경 추적 : createdAt, updatedAt, validFrom 및 validTo 타임스탬프를 자동으로 기록합니다.
시간적 일관성 : 지식이 어떻게 진화했는지에 대한 역사적으로 정확한 관점을 유지합니다.
비파괴적 업데이트 : 업데이트는 기존 데이터를 덮어쓰는 대신 새 버전을 생성합니다.
시간 기반 필터링 : 시간 기준에 따라 그래프 요소 필터링
역사 탐구 : 시간이 지남에 따라 특정 정보가 어떻게 변했는지 조사합니다.
관계는 구성 가능한 반감기에 따라 시간이 지남에 따라 자동으로 신뢰도가 감소합니다.
시간 기반 감소 : 관계에 대한 신뢰는 강화되지 않으면 시간이 지남에 따라 자연스럽게 감소합니다.
구성 가능한 반감기 : 정보가 얼마나 빨리 불확실해지는지 정의합니다(기본값: 30일)
최소 신뢰 수준 : 중요 정보의 과도한 붕괴를 방지하기 위한 임계값 설정
붕괴 메타데이터 : 각 관계에는 자세한 붕괴 계산 정보가 포함되어 있습니다.
비파괴적 : 원래 신뢰 값은 감소된 값과 함께 보존됩니다.
강화 학습 : 새로운 관찰을 통해 강화되면 관계가 자신감을 회복합니다.
참조 시간 유연성 : 과거 분석을 위해 임의의 참조 시간을 기반으로 감소를 계산합니다.
사용자 정의 필드가 있는 엔터티와 관계 모두에 대한 풍부한 메타데이터 지원:
소스 추적 : 정보가 어디에서 유래되었는지 기록합니다(사용자 입력, 분석, 외부 소스)
신뢰 수준 : 확실성에 따라 관계에 신뢰 점수(0.0-1.0)를 할당합니다.
관계 강도 : 관계의 중요성 또는 강도를 나타냅니다(0.0-1.0)
시간 메타데이터 : 정보가 추가, 수정 또는 검증된 시점을 추적합니다.
사용자 정의 태그 : 분류 및 필터링을 위한 임의의 태그 추가
구조화된 데이터 : 메타데이터 필드 내에 복잡한 구조화된 데이터를 저장합니다.
쿼리 지원 : 메타데이터 속성을 기반으로 검색 및 필터링
확장 가능한 스키마 : 핵심 데이터 모델을 수정하지 않고 필요에 따라 사용자 정의 필드를 추가합니다.
다음 도구는 모델 컨텍스트 프로토콜을 통해 LLM 클라이언트 호스트에서 사용할 수 있습니다.
엔티티 생성
지식 그래프에 여러 개의 새 엔터티 만들기
입력: entities (객체 배열)
각 객체에는 다음이 포함됩니다.
name (문자열): 엔터티 식별자
entityType (문자열): 유형 분류
observations (문자열[]): 연관된 관찰
관찰 추가
기존 엔터티에 새로운 관찰 추가
입력: observations (객체 배열)
각 객체에는 다음이 포함됩니다.
entityName (문자열): 대상 엔티티
contents (문자열[]): 추가할 새로운 관찰
엔티티 삭제
엔터티와 해당 관계 제거
입력: entityNames (string[])
관찰 삭제
엔터티에서 특정 관찰을 제거합니다.
입력: deletions (객체 배열)
각 객체에는 다음이 포함됩니다.
entityName (문자열): 대상 엔티티
observations (string[]): 제거할 관찰
관계 생성
향상된 속성을 사용하여 엔터티 간에 여러 개의 새로운 관계를 생성합니다.
입력: relations (객체 배열)
각 객체에는 다음이 포함됩니다.
from (문자열): 소스 엔터티 이름
to (문자열): 대상 엔터티 이름
relationType (문자열): 관계 유형
strength (숫자, 선택 사항): 관계 강도(0.0-1.0)
confidence (숫자, 선택 사항): 신뢰 수준(0.0-1.0)
metadata (객체, 선택 사항): 사용자 정의 메타데이터 필드
get_relation
향상된 속성을 통해 특정 관계를 얻으세요
입력:
from (문자열): 소스 엔터티 이름
to (문자열): 대상 엔터티 이름
relationType (문자열): 관계 유형
업데이트_관계
향상된 속성으로 기존 관계 업데이트
입력: relation (객체):
포함 내용:
from (문자열): 소스 엔터티 이름
to (문자열): 대상 엔터티 이름
relationType (문자열): 관계 유형
strength (숫자, 선택 사항): 관계 강도(0.0-1.0)
confidence (숫자, 선택 사항): 신뢰 수준(0.0-1.0)
metadata (객체, 선택 사항): 사용자 정의 메타데이터 필드
관계 삭제
그래프에서 특정 관계 제거
입력: relations (객체 배열)
각 객체에는 다음이 포함됩니다.
from (문자열): 소스 엔터티 이름
to (문자열): 대상 엔터티 이름
relationType (문자열): 관계 유형
읽기_그래프
지식 그래프 전체를 읽어보세요
입력이 필요하지 않습니다
검색_노드
쿼리 기반 노드 검색
입력: query (문자열)
오픈 노드
이름으로 특정 노드 검색
입력: names (string[])
의미론적 검색
벡터 임베딩과 유사성을 사용하여 의미적으로 엔터티 검색
입력:
query (문자열): 의미적으로 검색할 텍스트 쿼리
limit (숫자, 선택 사항): 반환할 최대 결과 수(기본값: 10)
min_similarity (숫자, 선택 사항): 최소 유사도 임계값(0.0-1.0, 기본값: 0.6)
entity_types (string[], 선택 사항): 엔티티 유형별로 결과 필터링
hybrid_search (부울, 선택 사항): 키워드 검색과 의미 검색을 결합합니다(기본값: true)
semantic_weight (숫자, 선택 사항): 하이브리드 검색에서 의미적 결과의 가중치(0.0-1.0, 기본값: 0.6)
특징:
쿼리 컨텍스트에 따라 최적의 검색 방법(벡터, 키워드 또는 하이브리드)을 지능적으로 선택합니다.
의미적 일치가 없는 쿼리를 대체 메커니즘을 통해 우아하게 처리합니다.
자동 최적화 결정으로 높은 성능 유지
엔티티 임베딩 가져오기
특정 엔터티에 대한 벡터 임베딩 가져오기
입력:
entity_name (문자열): 임베딩을 가져올 엔티티의 이름
엔티티 히스토리 가져오기
엔터티의 전체 버전 기록 가져오기
입력: entityName (문자열)
get_relation_history
관계의 전체 버전 기록 가져오기
입력:
from (문자열): 소스 엔터티 이름
to (문자열): 대상 엔터티 이름
relationType (문자열): 관계 유형
시간에 그래프 가져오기
특정 타임스탬프에서 그래프 상태를 가져옵니다.
입력: timestamp (숫자): Unix 타임스탬프(시대 이후 밀리초)
부패된 그래프 얻기
시간 감소 신뢰도 값을 사용하여 그래프 가져오기
입력: options (객체, 선택 사항):
reference_time (숫자): 감쇠 계산을 위한 참조 타임스탬프(epoch 이후 밀리초)
decay_factor (숫자): 선택적 붕괴 인자 재정의
다음 환경 변수를 사용하여 Memento MCP를 구성하세요.
# 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=trueNeo4j CLI 도구는 다음 옵션을 지원합니다.
--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)사용 가능한 OpenAI 임베딩 모델:
text-embedding-3-small : 효율적이고 비용 효율적(1536차원)
text-embedding-3-large : 정확도는 더 높고, 비용은 더 비쌈(3072차원)
text-embedding-ada-002 : 레거시 모델(1536차원)
의미 검색을 사용하려면 OpenAI API 자격 증명을 구성해야 합니다.
OpenAI 에서 API 키 받기
다음을 사용하여 환경을 구성하세요.
# OpenAI API Key for embeddings
OPENAI_API_KEY=your-openai-api-key
# Default embedding model
OPENAI_EMBEDDING_MODEL=text-embedding-3-small참고 : 테스트 환경에서 API 키가 제공되지 않으면 시스템은 임베딩 생성을 모의합니다. 하지만 통합 테스트에는 실제 임베딩을 사용하는 것이 좋습니다.
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"
}
}
}
}또는 로컬 개발을 위해 다음을 사용할 수 있습니다.
{
"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"
}
}
}
}중요 : 일관된 동작을 보장하려면 Claude Desktop 구성에서 항상 내장 모델을 명시적으로 지정하세요.
Claude와 최적의 통합을 위해 시스템 프롬프트에 다음 명령문을 추가하세요.
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.구성이 완료되면 Claude는 자연어를 통해 의미 검색 기능에 액세스할 수 있습니다.
의미적 임베딩을 사용하여 엔터티를 생성하려면:
User: "Remember that Python is a high-level programming language known for its readability and JavaScript is primarily used for web development."의미적으로 검색하려면:
User: "What programming languages do you know about that are good for web development?"특정 정보를 검색하려면:
User: "Tell me everything you know about Python."이 접근 방식의 장점은 사용자가 자연스럽게 상호 작용할 수 있고, LLM이 적절한 메모리 도구를 선택하고 사용하는 데 따르는 복잡성을 처리한다는 것입니다.
Memento의 적응형 검색 기능은 다음과 같은 실질적인 이점을 제공합니다.
다양한 쿼리 유형 : 사용자는 질문을 어떻게 표현해야 할지 걱정할 필요가 없습니다. 시스템은 다양한 쿼리 유형에 자동으로 적응합니다.
실패 회복력 : 의미적 일치가 사용 가능하지 않더라도 시스템은 사용자 개입 없이 대체 방법으로 대체될 수 있습니다.
성능 효율성 : 최적의 검색 방법을 지능적으로 선택함으로써 시스템은 각 쿼리에 대한 성능과 관련성의 균형을 맞춥니다.
향상된 컨텍스트 검색 : LLM 대화는 시스템이 복잡한 지식 그래프에서 관련 정보를 찾을 수 있으므로 더 나은 컨텍스트 검색의 이점을 얻습니다.
예를 들어, 사용자가 "머신러닝에 대해 무엇을 알고 계십니까?"라고 질문하면 시스템은 "머신러닝"을 명시적으로 언급하지 않더라도 개념적으로 관련된 항목(예: 신경망, 데이터 과학 또는 특정 알고리즘 관련 항목)을 검색할 수 있습니다. 하지만 의미 검색에서 충분한 결과가 나오지 않으면 시스템은 자동으로 접근 방식을 조정하여 유용한 정보가 계속 반환되도록 합니다.
Memento MCP에는 벡터 검색 문제를 해결하는 데 도움이 되는 내장 진단 기능이 포함되어 있습니다.
임베딩 검증 : 시스템은 엔터티에 유효한 임베딩이 있는지 확인하고 누락된 경우 자동으로 생성합니다.
벡터 인덱스 상태 : 벡터 인덱스가 존재하고 온라인 상태인지 확인합니다.
대체 검색 : 벡터 검색이 실패하면 시스템은 텍스트 기반 검색으로 대체됩니다.
상세 로깅 : 문제 해결을 위한 벡터 검색 작업의 포괄적인 로깅
디버그 모드가 활성화되면 추가 진단 도구를 사용할 수 있습니다.
diagnose_vector_search : Neo4j 벡터 인덱스, 임베딩 카운트 및 검색 기능에 대한 정보
force_generate_embedding : 특정 엔터티에 대한 임베딩을 강제로 생성합니다.
debug_embedding_config : 현재 임베딩 서비스 구성에 대한 정보
개발 중에 Neo4j 데이터베이스를 완전히 재설정하려면:
# 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:coverageSmithery를 통해 Claude Desktop용 memento-mcp를 자동으로 설치하려면:
npx -y @smithery/cli install @gannonh/memento-mcp --client claudenpx를 사용하여 전역적으로 설치하지 않고도 Memento MCP를 직접 실행할 수 있습니다.
npx -y @gannonh/memento-mcp이 방법은 Claude Desktop 및 기타 MCP 호환 클라이언트와 함께 사용하는 것이 좋습니다.
프로젝트 개발 또는 참여를 위해:
# 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 must disclose behavior but only states 'add new observations'. It does not specify what happens if the entity does not exist, whether observations are appended or overwritten, or any other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it omits important context. It is concise but not optimally structured with key usage info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested object structure and multiple parameters, the description is too sparse. It lacks explanation of relationships between observations and entities, and no output schema is provided to compensate.
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%, so the schema already explains most parameters. The description adds no further semantic value beyond the tool name, so a 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 uses a specific verb-resource pair ('Add new observations to existing entities') and clearly distinguishes from sibling tools like 'create_entities' or 'delete_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 information is provided about when to use this tool versus alternatives (e.g., updating entities directly). No prerequisites or exclusions are mentioned.
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 present, so the description carries the full burden. It only states that the tool 'creates' entities, implying mutation, but provides no details on side effects, constraints, error conditions, or whether it is destructive. The description lacks sufficient behavioral 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 sentence that is concise and front-loaded with the core action. It contains no unnecessary words or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch creation with many optional fields), the absence of annotations and output schema, the description is minimal. It does not explain return values, error handling, batch limits, or how it relates to sibling tools like 'delete_entities' or 'read_graph'. The context is incomplete.
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 provides descriptions for all parameters, so the baseline is 3. The description does not add meaningful information beyond what the schema already states; it simply mentions 'multiple new entities' without detailing parameter usage.
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 memory system'. It effectively distinguishes from sibling tools like 'create_relations' and 'add_observations'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to use create_entities vs add_observations). There is no mention of prerequisites, exclusions, or use cases.
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?
No annotations provided, and the description does not disclose behavioral traits such as idempotency, side effects, permissions, or error conditions. The only extra information is 'active voice' style.
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 short (2 sentences) but lacks substance. It is concise but not effectively structured for quick comprehension of tool usage.
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 complex nested schema (multiple relation properties), no output schema, and many sibling tools, the description is too sparse. It does not address error handling, success behavior, or relationships to other tools.
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 reported as 0%, meaning the input schema's own descriptions are not counted. The tool description adds minimal parameter insight beyond the schema: 'Relations should be in active voice' does not clarify parameters.
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 specifies the action 'create multiple new relations' and the target resource 'entities in your Memento MCP knowledge graph memory'. It distinguishes from sibling tools like delete_relations and update_relation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., update_relation). The 'active voice' note is a stylistic hint but not a usage guideline.
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?
With no annotations, the description must fully disclose behavior. It notes cascading deletion of relations, a key trait, but does not mention prerequisites, reversibility, or limits.
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 single-sentence description is concise (12 words), front-loaded with the verb and object, and includes all essential information without fluff.
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 delete tool with one parameter and no output schema, the description covers the main action and scope. It could mention permanence but is otherwise adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description is clear. The tool description adds no extra semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes multiple entities and their associated relations, distinguishing it from sibling tools like delete_observations or delete_relations that handle 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 description provides clear context for when to use the tool (when deleting entities and their relations), but lacks explicit when-not or alternative tool mentions.
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 provided, so description carries full burden. It states 'delete', implying mutation, but lacks details on side effects, irreversibility, permissions, or what happens if observations don't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb 'Delete', no extraneous information. Every word contributes to understanding the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too brief. It does not explain the deletions parameter format, behavior on missing entities or observations, or any return value. Leaves too many gaps for an 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 0% (per signal), so description should compensate. It does not mention the nested structure with entityName and observations. The schema provides definitions, but the description adds no value beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (delete), resource (observations), and context (Memento MCP knowledge graph memory). Distinguishes from sibling tools like delete_entities and delete_relations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention that delete_entities or delete_relations are for other resource types, or any prerequisites or limitations.
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?
No annotations provided. The description does not disclose any side effects, error states, or constraints beyond the action of deletion. For a delete operation, more detail on idempotency or cascade effects would be expected.
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 very concise (11 words), but it sacrifices necessary context. It is minimally adequate but not an example of efficient depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description lacks details on return values, error handling, or behavioral context. It is incomplete for a tool with a single, complex parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description adds no additional meaning beyond the schema, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes multiple relations, with a specific verb and resource. It distinguishes from siblings like create_relations and get_relation, though the scope is implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., no mention of deleting single relations vs batch, or when to prefer this over update_relation). The context is missing entirely.
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?
No annotations are provided, and the description fails to disclose whether the tool is read-only, destructive, or requires special permissions. It does not explain the decay mechanism or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, but slightly vague. Could be more informative while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing return value description (no output schema) and behavioral details. Adequate for a simple retrieval, but incomplete given no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds context by linking parameters (reference_time, decay_factor) to the decay behavior, but does not elaborate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a knowledge graph with decayed confidence values, distinguishing it from siblings like get_graph_at_time and read_graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_graph_at_time, semantic_search), nor any when-not-to-use conditions.
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?
No annotations are present, so the description must convey behavioral traits. It only states the action without disclosing side effects, read-only nature, performance characteristics, or any constraints. The agent cannot deduce that this is a safe read operation without additional 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 sentence that is concise and front-loaded. However, it is somewhat terse and could benefit from slight expansion without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally complete. However, it lacks mention of the return type (vector embedding) and does not clarify that it is a read-only operation, which would be helpful for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the parameter 'entity_name'. The description adds only the phrase 'from your Memento MCP knowledge graph memory', which provides context but no additional semantic detail about the parameter itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a vector embedding for a specific entity, using a specific verb ('Get') and resource. It mentions the knowledge graph context, but does not explicitly differentiate from siblings like 'get_entity_history' or 'semantic_search', which are distinct but also involve entities/embeddings.
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. For example, it does not explain how this differs from 'semantic_search' which also uses embeddings, or when to prefer 'get_entity_embedding' over 'get_entity_history'.
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?
No annotations exist, so the description must carry the burden of behavioral disclosure. It only states retrieval of history but does not mention whether it is read-only, any rate limits, or side effects like data mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, efficiently conveying the purpose. However, it could include more detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, no nested objects), the description is adequate but lacks mention of what the version history format includes or any temporal context, which is relevant given siblings like get_graph_at_time.
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% for the only parameter 'entityName'. The description adds no additional meaning beyond what the schema already provides, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get), the resource (version history of an entity), and the context (from Memento MCP knowledge graph memory). It distinguishes itself from siblings like get_relation_history by specifying 'entity'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_entity_embedding or get_graph_at_time. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states a read operation without mentioning performance implications, return format, or any potential side effects. Essential context is missing.
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 conveys the core functionality efficiently 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?
Given the lack of output schema and annotations, the description is minimal. It does not explain the output format, limitations on time range or precision, or how this tool relates to other time-based tools. An agent would need additional information to use it 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?
The schema already describes the timestamp parameter with high coverage (100%), including its unit (milliseconds since epoch). The description adds no additional semantic value beyond what the schema provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Memento MCP knowledge graph memory' with a specific temporal scope 'as it existed at a specific point in time'. This effectively differentiates it from siblings like read_graph (current state) and get_decayed_graph (decayed state).
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 historical queries but provides no explicit guidance on when to use this tool versus alternatives like get_entity_history or get_decayed_graph. No exclusion criteria or alternative names are mentioned.
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?
With no annotations, the description carries full burden but only says 'enhanced properties' without explaining behavior (e.g., side effects, permissions). It does not reveal what enhanced properties are.
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?
One concise sentence, front-loaded with purpose, though 'from your Memento MCP knowledge graph memory' is slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations; the description lacks details about return format, pagination, or error conditions, leaving the agent under-informed for a get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter is described. The description adds no extra meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'a specific relation', including 'enhanced properties', which distinguishes it from sibling tools like create_relations 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get_relation_history or read_graph. The description does not mention prerequisites or context.
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 present, so the description carries full burden for behavioral disclosure. However, it only states 'get version history', omitting traits like read-only nature, authorization requirements, or whether history includes changes to properties or just the relation's existence. Minimal behavioral context provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy or filler. Front-loaded with the core action and resource. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain what is returned (e.g., list of versions, timestamps, field changes). It does not, leaving the agent uncertain about the response format. Also lacks details on ordering, pagination, or limits.
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%; each parameter (from, to, relationType) has a clear description. The description does not add meaning beyond the schema, meeting the baseline expectation. No additional parameter details like format or constraints are offered.
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 action: 'Get the version history of a relation'. It specifies the verb (get), resource (relation), and scope (version history), distinguishing it from sibling tools like 'get_relation' (current state) and 'get_entity_history' (entity version history).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'get_relation' for current state, 'get_graph_at_time' for historical snapshots). No prerequisites or context provided, leaving the agent to infer usage from the tool name alone.
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?
With no annotations, the description must fully disclose behavior. The description only states it 'opens' nodes, but does not clarify whether the operation is read-only, what side effects exist, or what happens if a node is not found. This is insufficient for safe tool invocation.
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 filler. It is front-loaded with the action. However, it is borderline too terse, missing important details that could be included without significant length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description does not explain what the tool returns (e.g., full node data, status messages). Given the complexity of the knowledge graph context and many sibling tools, this lack of completeness hinders effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents the parameter 'names' as an array of strings. The description adds minimal extra meaning ('by their names') that aligns with the schema. No additional details like name format, case sensitivity, or behavior for missing names are provided, keeping it at 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 ('Open') and resource ('nodes'), and adds the qualifier 'by their names', which clarifies the tool's action. However, it does not explicitly differentiate this from other retrieval tools like 'read_graph' or 'search_nodes', leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., search_nodes, read_graph). There are no exclusions or context hints, forcing the agent to infer usage from the description alone.
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 provided, so description carries full burden. Describes a read operation (non-destructive) but omits details about size constraints, timeouts, or permissions. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy. All words are necessary and front-loaded.
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?
No output schema, no annotations. Reading the entire graph could be heavy; description lacks warnings or suggestions for partial reads via sibling tools. Incomplete given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one dummy parameter explained. Description adds no new meaning beyond schema; baseline 3 applies as schema suffices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Read' and the resource 'entire Memento MCP knowledge graph memory system'. It distinguishes from siblings like 'get_graph_at_time' or 'get_decayed_graph' which offer 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?
Implies usage for retrieving the full graph, but no explicit guidance on when to use versus alternatives like 'search_nodes' or 'semantic_search'. No when-not-to-use or prerequisite info.
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?
With no annotations, the description must disclose behavioral traits. It only says 'based on a query' but omits return format, pagination, or read-only nature, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the action and resource, containing no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate but lacks information on what the search returns or how it differs from similar tools like semantic_search.
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 100% of parameters, and the description adds value by specifying that the query matches 'entity names, types, and observation content', which clarifies the parameter's usage.
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 'Search for nodes' and the resource 'Memento MCP knowledge graph memory', but does not differentiate from sibling tools like semantic_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives (e.g., semantic_search). The description only states what it does, 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.
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 provided, so description must disclose behavior. It does not mention return format, result interpretation, performance implications, or safety traits. Only states the action without side-effect details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently communicates the tool's purpose with no redundancy. All words contribute to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 parameters, no output schema, and no annotations, the description provides only a high-level overview. Missing details on return values, pagination, and specific behaviors for parameters like hybrid_search or entity_types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented in the schema. The description adds no additional meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for entities semantically using vector embeddings and similarity, specifying the resource (Memento MCP knowledge graph memory) and methodology. It distinguishes from sibling tools like search_nodes which likely use keyword search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., search_nodes, open_nodes). Does not mention 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.
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?
With no annotations, the description must disclose behavioral traits. It indicates mutation but does not mention idempotency, error cases (e.g., relation not found), or side effects. The description is too brief to provide transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the core action.
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 mutation tool with a complex nested parameter structure and no output schema, the description omits return values, error handling, and behavioral specifics. It does not fully enable an agent to use 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 text does not describe any parameters; all parameter meaning comes from the schema itself. Since schema description coverage is 0% from the description's perspective, it fails to add value beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update', the resource 'existing relation', and the context 'in your Memento MCP knowledge graph memory'. It distinguishes from siblings like create_relations (create vs update) and delete_relations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives (e.g., when to update vs create, or prerequisites like relation existence). Usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
add_observationscreate_entitiescreate_relationsdelete_entitiesdelete_observationsdelete_relationsget_decayed_graphget_entity_embeddingget_entity_historyget_graph_at_timeget_relationget_relation_historyopen_nodesread_graphsearch_nodessemantic_searchupdate_relationEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gannonh/memento-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
