Skip to main content
Glama
tyxiumud

personal-memory-mcp

by tyxiumud

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PERSONAL_MEMORY_DBNoPath to the SQLite database file. If unset, defaults to `%LOCALAPPDATA%\personal-memory-mcp\memory.sqlite3` on Windows or a user data directory elsewhere. The `--db` command-line argument takes precedence over this environment variable.

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
memory_searchA

Search active memories with FTS5. Default global only; project/domain may include global.

query is plain text (all terms must match), not SQL/FTS syntax. as_of filters validity, not historical revisions. Forgotten records are always excluded. Paginate with offset.

query_variants (max 5, each max 100 chars) runs each keyword set as its own strict FTS query and merges the ranked lists by reciprocal rank fusion, score = sum(1/(60+rank)). This is lexical keyword fusion, NOT vector or semantic search: a variant only helps if its characters actually occur in the record. Each variant gets at most 100 candidates before fusion, so offsets past that pool return fewer or no rows. Every variant still passes the same scope, type, validity and forgotten filters. With variants present the original query is fused too; an empty query is skipped instead of browsing everything.

The response keeps the memories array and adds a retrieval object so an empty page can be read correctly. reason is "empty_scope" (no current record passes the scope, type, as_of and forgotten filters), "no_lexical_match" (records exist in scope but none match the keywords), "offset_beyond_pool" (the page starts past the available candidates), "relaxed_match" (search_mode="auto" widened the search; see below) or "matched". None of these means that the user never recorded anything: scope/type/as_of filters and lexical matching both narrow the result. scoped_active counts records before any keyword match; candidate_pool counts the candidates this strategy actually collected, so when candidate_limit_reached is true it is a floor, not the total; for the multi-query strategy per_query_matches holds the exact per-query counts instead.

search_mode defaults to "strict", which is the historical keyword behaviour and is unchanged. search_mode="auto" runs the same strict queries first and, only when the candidate pool is empty and no page has been skipped, makes one bounded relaxed pass: it splits the query and the variants into keyword fragments, measures the in-scope document frequency of every one of them, drops the fragments that match nothing and the ones too common to discriminate, then keeps the most discriminative dozen (lowest frequency first, original order for ties, dropped ones listed in fallback.dropped_by_cap_fragments), recalls candidates with OR over those fragments, discards candidates covering too few of them, and ranks the rest by coverage. Scope, type, validity and forgotten filters always apply, and a pagination overflow never triggers it. Records from that pass carry match_quality="relaxed" and retrieval.fallback reports the method, trigger, keywords used and dropped, the coverage requirement, how many candidates were recalled, rejected and survived, and whether the recall cap was hit; such results need their relevance checked and their confidence is never rewritten. candidate_pool and has_more_in_pool describe the pool that survived coverage filtering, so a rejected candidate is never implied on a later page; when fallback.candidate_limit_reached is true there may be uninspected candidates and the pool is a floor, not the number of matching records. A relaxed pass can still return nothing: an empty result stays a valid answer, and fallback.coverage_required == 1 marks the weakest single-keyword tier.

memory_contextA

Get bounded reference memories for the current task, respecting scope and validity.

max_chars bounds the serialized memories array, not the small response wrapper. Whole records that do not fit are omitted; omitted_from_page reports how many, and returned_after_budget is how many survived. retrieval.returned is what retrieval found before the budget, so a record dropped for size is never reported as no hit.

view="full" (default) returns complete records. view="compact" keeps id, revision, title, content, scope, scope_id, type, validity, updated_at, confidence, importance and a deterministically extracted source summary; it never truncates the body and never invents missing provenance. source_summary keeps verification and epistemic_status unshortened, because a trailing caveat like "未逐项外部核实" must not be cut off. Use memory_history when full evidence is needed. Suggested startup read: view="compact", max_chars=6000, limit=8.

memory_storeA

Store a durable memory with provenance. Return id and revision.

Explicit user requests must be handled; autonomous writes require confirmed, durable, future-useful information. Search first. Prefer source.trigger=explicit|autonomous. Never store secrets, speculation, raw logs, or short-lived conversational details. For a changed fact create a new memory with supersedes=old_id; its valid_from closes the old memory's validity atomically. Scope and scope_id must match the old memory. An exact active duplicate in the same scope/type is returned without another insert.

memory_updateA

Correct content/metadata with optimistic concurrency and a full audit snapshot.

Editable fields: title, content, type, confidence, importance, source, tags. Scope, validity and supersedes are immutable; use memory_store for changed facts.

memory_forgetA

Soft-delete one memory from retrieval. History and database content are retained.

This is NOT secure erasure. Read the current revision via history before forgetting.

memory_historyA

Read revision snapshots newest first, including forgotten memories; supports pagination.

memory_statusA

Report database location, counts, the scope inventory, schema and capabilities.

scopes lists every existing (scope, scope_id) pair with scope, scope_id, total_count, active_count and newest_updated_at kept as separate fields. Check it when the task scope is unclear or changes, then choose the relevant scope: knowing that a scope exists is not a reason to read every project. active_count follows the same rule as retrieval (not forgotten, valid at as_of), while total_count and newest_updated_at include forgotten and expired records.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.6/5.0

Scored across 7 tools

Disambiguation5/5

Each tool targets a distinct operation: search for query-based retrieval, context for bounded task-relevant retrieval, store for creation, update for modification, forget for soft deletion, history for revision snapshots, and status for database metadata. There is no functional overlap between any pair.

Naming Consistency5/5

All tool names share the `memory_` prefix and follow a mostly verb-oriented pattern: search, store, update, forget, history, status. `memory_context` is the only noun-based name, but it clearly signals retrieving context and does not break the overall consistent naming convention.

Tool Count5/5

Seven tools is well within the ideal scoped range for a personal memory server. Each tool covers a necessary capability without redundancy or bloat, and none feel superfluous.

Completeness5/5

The tool surface provides full CRUD coverage (store/create, context+search+history/read, update/update, forget/delete) plus lifecycle extras like history, status, and scoped context retrieval. The soft-delete design is deliberate and well documented, leaving no obvious dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues