Skip to main content
Glama
yliuai

Spomory

by yliuai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
LLM_MODELNoLLM model to use. Optional; defaults to gpt-4o-mini.gpt-4o-mini
HF_ENDPOINTNoHuggingFace mirror endpoint, useful when huggingface.co is unreachable (e.g., behind the Great Firewall).
LLM_API_KEYYesAPI key for any OpenAI-compatible Chat Completions endpoint (OpenAI, DeepSeek, Qwen, etc.). Must be set at runtime.
DATABASE_URLNoPostgres connection URL. If set, uses the Postgres backend instead of local SQLite.
LLM_BASE_URLNoBase URL of the OpenAI-compatible API. Optional; defaults to OpenAI's endpoint.
EMBEDDING_MODELNoSentence-transformers model name for embeddings. Optional; defaults to BAAI/bge-m3.BAAI/bge-m3
MEMORY_CORE_DATA_DIRNoDirectory to store memory data. Optional; defaults to ~/.memory-core/.~/.memory-core/

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
add_memoryB

Extract facts from text and write them into the memory graph.

search_memoryC

Retrieve and assemble a natural-language context relevant to query.

forget_memoryA

Find the single fact that best matches query and permanently delete it.

This is the user-facing counterpart to the "true delete" backing export_memory's data-ownership promise (Epic 7.3): without it, that capability existed at the storage layer but a user had no way to actually invoke it from a conversation (e.g. "forget that I work at X"). Deletes at most one relation per call, on purpose -- a query vague enough to match many facts should be narrowed and retried rather than risk deleting the wrong ones silently.

forget_all_memoryA

Permanently delete the entire memory graph -- every entity and relation.

forget_memory is deliberately one-fact-at-a-time; this is its bulk counterpart for a user who wants a clean slate (e.g. before re-testing, or a genuine full data wipe) instead of narrowing and retrying a query N times.

destructive_hint=True on this tool's annotations is only a hint -- the MCP spec doesn't require a host to gate on it, so a host that treats it as advisory (or an agent auto-approving destructive tools) could otherwise wipe everything on the first call with no human in the loop at all. confirm is the actual enforcement: the first call (confirm left at its default, False) never deletes anything -- it only reports what a real call would remove -- so triggering a wipe needs an explicit second call with confirm=True, regardless of what the host's UI does or doesn't show.

get_graphB

Return the subgraph around entity_name as JSON.

export_memoryB

Export the full memory graph as a JSON memory passport.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a clear, distinct operation: add, graph lookup, semantic search, single-fact delete, full wipe, and export. The two delete tools are explicitly differentiated by scope, and get_graph vs search_memory are distinguished by input type (entity vs natural-language query) and output format.

Naming Consistency5/5

All tool names follow the same lower_snake_case verb_noun pattern: add_, get_, search_, forget_, forget_all_, export_. The shared 'memory' base and the obvious 'forget_memory' / 'forget_all_memory' pair make the naming highly predictable.

Tool Count5/5

Six tools is a well-scoped size for a memory-graph server, covering creation, retrieval, deletion, and export without redundancy or bloat. Each tool earns its place and the count sits comfortably in the ideal 3–15 range.

Completeness4/5

The core memory lifecycle is covered: add, retrieve (graph and semantic), delete single, delete all, and export. Minor gaps exist—there is no explicit update operation and no import counterpart to the export—but agents can work around these via add_memory and re-adding facts.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources