Skip to main content
Glama
H1an1

mem-universe

by H1an1
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

mem-universe

A self-hosted MCP memory server that gives a personal multi-agent fleet (Claude Code, ChatGPT, Codex, Cursor, and any other MCP client) one shared, git-backed memory. Agents install nothing. They connect over MCP and search / read / write.

The problem it solves: "Claude on one machine figured out how to do X, but Codex on another machine has no idea." One memory, every agent, instantly.

The idea

Most "give your agent memory" setups sync skill files into each tool, in each tool's own format. That does not scale across a fleet: every new agent needs a converter, and knowledge learned in one place is invisible everywhere else.

mem-universe flips it: keep one plain-text store, and let every agent read and write it at use time over MCP. A skill is just markdown any agent can follow, so there is nothing to convert. Learn something once, and the whole fleet can recall it on the next task.

Related MCP server: tartarus-mcp

Architecture

flowchart LR
  subgraph agents [Your agent fleet]
    A1[Claude Code]
    A2[ChatGPT]
    A3[Codex / Cursor]
    A4[Other MCP clients]
  end

  A1 -- "Bearer token" --> S
  A3 -- "Bearer token" --> S
  A4 -- "Bearer token" --> S
  A2 -- "token in URL path" --> S

  subgraph server [mem-universe server  ·  FastMCP over HTTP]
    S[auth + path validation]
    S --> T["tools: search / read / write / list / delete<br/>put_skill / get_skill / list_skills"]
    T --> IDX[("BM25 index<br/>local, rebuildable")]
    T --> ST[git working copy]
  end

  ST -- "commit, then async push" --> GH[("private store repo<br/>on GitHub")]
  ST --> L1["shared/  ·  skills, lessons, rules"]
  ST --> L2["personal/  ·  owner profile, notes"]

Key design decisions

  1. MCP is the integration layer, not file-syncing. Knowledge is stored once as plain text and retrieved on demand. Add one entry and the whole fleet sees it, with no per-agent format conversion.

  2. Git is the database. The store is a git repo of markdown files. Every write is a commit, then an async push to GitHub. You get version history, recoverable deletes (delete is also a commit), human-readable data, and "backup" for free. Writes are serialized by a single-writer lock; reads come from the local clone, so they never wait on the network. Last write wins, so there are no merge conflicts by design.

  3. Code and data live in two separate repos. This server (code) is one repo. Your memory (data) is a separate, private store repo that the server clones and writes to. That split is why this codebase can be public while your memory stays private. Never put the store in this repo.

  4. Two layers, one permission. shared/ is cross-agent knowledge (skills, lessons, rules). personal/ is the owner's own content. Any valid token can read and write everything: tokens gate who connects, not which layer. For a single owner's fleet on a private network, scoped permissions are over-engineering. Anything truly secret should not go in the store at all.

  5. Retrieval, not installation. Agents install nothing. To make an agent use the library, drop a one-line "recall first" marker into its existing instruction file (CLAUDE.md, AGENTS.md, ...) telling it to search before acting. Multi-file, runnable skills travel as packages (put_skill / get_skill).

  6. Two ways to authenticate, so Claude and ChatGPT both connect. Clients that can send headers use Authorization: Bearer <token>. Clients that cannot set custom headers (such as a ChatGPT connector) put the token in the URL path: https://<host>/<token>/mcp. Same server, both worlds.

  7. Hand-rolled, bilingual BM25 search. No external embedding service. It is light, works offline, and tokenizes mixed CJK + English. The index lives locally and is never committed (it rebuilds from the store).

The tools

Tool

What it does

search

BM25 search across the store; returns ranked {path, score, snippet, type}

read

Read one entry by store-relative path

write

Write an entry (also indexes it); layer inferred from the path

list

List entries under a layer / prefix

delete

Delete an entry (git keeps history, so it is recoverable)

put_skill

Store a multi-file skill package under shared/skills/<name>/

get_skill

Fetch a skill package to install locally

list_skills

List available skill packages

Layers

<store>/
├── shared/      # cross-agent knowledge: skills / tools / lessons / rules
└── personal/    # the owner's own content: profile, notes, imports

A write path starts with the layer name (shared/... or personal/...); the layer argument is optional and inferred from the path.

What happens on one write

write(path, content)
  -> validate path (must stay in-layer; reject ../ and cross-layer symlinks)
  -> acquire single-writer lock
  -> write file + stamp frontmatter
  -> git commit
  -> return ok
  -> (background) async push to the private store repo
  -> update the local BM25 index

Reads and searches always hit the local clone, so they do not block on git.

Deploy

Full steps are in DEPLOY.md. The short version (Docker):

git clone https://github.com/H1an1/mem-universe && cd mem-universe/deploy
cp mem.env.example mem.env     # set MEMORY_TOKEN and MEM_STORE_REMOTE (your private store repo)
# edit Caddyfile: point your domain at this VPS
docker compose up -d --build

This runs the server behind Caddy (automatic TLS). Agents reach it at https://<your-domain>/mcp. Generate a token with openssl rand -hex 32. A Tailscale-only (no public exposure) compose file is also included.

Connect your agents

All clients need the URL plus a token.

Claude Code

claude mcp add --transport http mem-universe https://<your-domain>/mcp \
  --header "Authorization: Bearer <YOUR_TOKEN>"

Claude Desktop / claude.ai (custom connector): add an HTTP MCP server with URL https://<your-domain>/mcp. If the client supports a header, use Authorization: Bearer <YOUR_TOKEN>; otherwise use the path-token URL below.

ChatGPT (custom connector): ChatGPT connectors cannot set custom headers, so put the token in the path:

https://<your-domain>/<YOUR_TOKEN>/mcp

Cursor / Codex / others: add an HTTP MCP server with the same URL and an Authorization: Bearer <YOUR_TOKEN> header (see your client's MCP docs).

Every agent uses the same token. To make agents actually recall before acting, add a short "recall first" marker to each agent's instruction file.

Security model

  • One token unlocks every layer; tokens gate connection, not content. A read-only token variant exists for untrusted external readers.

  • The server rejects path traversal (../) and cross-layer symlinks at the filesystem level, independent of auth.

  • Run it on a private network (such as Tailscale) or behind TLS with a strong token. Anything that truly must never be read by any agent does not belong in the store.

  • Secrets live only in deploy/mem.env (gitignored). Never commit them.

How it was built

Built with a maker/checker loop: each feature was written, then reviewed by a separate pass plus an adversarial verifier whose job was to break it. That caught real bugs before release, including a cross-layer symlink that let a read-scoped token reach another layer, and an rmtree that followed symlinks. The suite has 100+ tests and is linted clean.

Develop

uv sync           # create venv (Python 3.12) + install deps
uv run pytest     # tests
uv run ruff check .
uv run mem-server # run the MCP server over stdio

License

MIT

Available Tools

8 tools
deleteC

Delete a memory file. Git keeps history, so it's recoverable. Returns {ok, deleted}.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
reasonNo
author_agentYes

TDQS

C2.7/5.0
Behavior3/5

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

With no annotations, the description partially discloses behavior: 'Git keeps history, so it's recoverable' indicates non-permanence, but doesn't specify side effects, authorization needs, or return format details beyond the stated return object.

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

Conciseness4/5

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

The description is extremely concise (two short sentences) with no extraneous text. However, it may be too minimal, missing critical details, but within the conciseness dimension it scores well for brevity.

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

Completeness2/5

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

Given three parameters, no output schema, and no annotations, the description is incomplete. It fails to explain the 'reason' and 'author_agent' parameters, and doesn't specify behavior for non-existent files or confirmation requirements.

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

Parameters1/5

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

Schema has 0% parameter description coverage, and the description adds no information about the three parameters (path, reason, author_agent). The agent must rely solely on parameter names, which is insufficient for correct invocation.

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

Purpose4/5

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

The description clearly states 'Delete a memory file.' which identifies the verb and resource. It distinguishes from siblings like read, write, list by indicating a destructive action, though not explicitly contrasting them.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like write or search. The description lacks context about prerequisites or conditions, leaving the agent to infer.

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

get_skillA

Fetch a whole skill package as {name, files: {relpath: content}}. To install it, write each file into your local skills dir (e.g. ~/.claude/skills//). Any agent can fetch + run a package; Claude-family agents additionally get native auto-invocation.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes

TDQS

A4.2/5.0
Behavior4/5

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

Returns format details ({name, files: {relpath: content}}) and post-fetch behavior (installation, auto-invocation) despite no annotations. No side-effect or permission disclosure needed for a read-only fetch.

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

Conciseness5/5

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

Two concise sentences, no redundancy, front-loaded purpose, efficient and clear.

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

Completeness4/5

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

Covers return structure, installation steps, and agent-specific behavior. Could mention how to obtain valid skill names, but overall adequate for a simple tool.

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

Parameters3/5

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

Single parameter 'name' has no description in schema (0% coverage) and description adds no further guidance on valid names or sources. However, its purpose is straightforward.

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

Purpose5/5

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

Clearly states 'Fetch a whole skill package' with specific verb and resource. Distinguishes from siblings like list_skills and put_skill by focusing on retrieval.

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

Usage Guidelines4/5

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

Provides installation instructions and mentions agent applicability (any agent vs Claude with auto-invocation), giving context for when to use. Lacks explicit exclusion of alternatives.

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

listC

List entries under a layer (optionally a prefix within it).

ParametersJSON Schema
NameRequiredDescriptionDefault
layerYes
prefixNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

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

No annotations provided, and the description lacks behavioral details like read-only nature, pagination, or rate limits. It does not disclose if it is limited or has side effects.

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

Conciseness4/5

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

Single sentence of 11 words, front-loaded with key action and resource. Efficient but could be more structured with explicit sections.

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

Completeness2/5

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

With no parameter descriptions in schema, the description does not fully cover return value semantics, pagination, or data format. Output schema exists but is not referenced, leaving gaps.

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

Parameters3/5

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

Schema description coverage is 0%, so description must compensate. It explains that 'layer' is the container and 'prefix' is an optional filter, adding meaning beyond the schema, but does not elaborate on parameter formats or constraints.

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

Purpose4/5

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

Description clearly states the verb 'list' and resource 'entries under a layer', with optional prefix. It distinguishes from sibling tools like 'list_skills' which lists skills.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as 'read' or 'search'. The description only states what it does without context for selection.

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

list_skillsA

List stored skill packages as [{name, description}] (description from each SKILL.md).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions the output format but does not disclose any behavioral traits such as ordering, pagination, error states, or side effects. The simplicity of the tool mitigates this somewhat, but more context would be helpful.

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

Conciseness5/5

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

The description is a single, efficient sentence that conveys the purpose and output format without any redundancy. It is well-structured and front-loaded.

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

Completeness4/5

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

Given zero parameters and the presence of an output schema, the description adequately covers the main functionality. However, it could be slightly improved by noting that it returns all packages (no filtering) or mentioning the default order.

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

Parameters4/5

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

There are no parameters, so the schema coverage is 100%. The description does not need to add parameter information. Per guidelines, zero parameters yields a baseline of 4.

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

Purpose5/5

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

The description clearly states the verb 'List' and the resource 'stored skill packages', specifying the output format as an array of objects with 'name' and 'description'. This distinguishes it from sibling tools like 'get_skill' (single skill) and 'search' (different verb).

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

Usage Guidelines3/5

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

The description implies usage for listing all skill packages, but does not provide when to use this tool over alternatives like 'search' or 'list'. No when-not-to-use or explicit guidance is given.

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

put_skillA

Store a runnable skill PACKAGE (a SKILL.md + its scripts/templates) byte-exact under shared/skills//. files maps package-relative paths to text content and MUST include a SKILL.md. Files are stored verbatim — no frontmatter, no template check (unlike write, which is for single markdown notes). The SKILL.md is indexed so search finds the package; any agent can later get_skill to install it. Returns {name, paths, commit}.

To push your local package: read every file under your skills dir (e.g.
~/.claude/skills/<name>/) into `files`, then call this. Text files only (v1).
ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
filesYes
reasonNo
author_agentYes

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses key behavioral traits: files stored byte-exact, verbatim, no frontmatter or template check, SKILL.md indexed for search, return format ({name, paths, commit}), and that it's for text files only. It does not explicitly mention whether the operation is destructive (overwrites existing?) or error conditions (e.g., missing SKILL.md), but given the constraints, the coverage is good.

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

Conciseness4/5

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

The description is concise, about 150 words split into two paragraphs. The first sentence immediately conveys the core action. Every sentence adds value: behavior details, comparison to write, usage instructions. No redundant or filler content. Could be slightly tighter, but overall efficient.

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

Completeness3/5

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

Given the complexity (4 params, nested object, no output schema, no annotations), the description is fairly complete: it explains the required file structure, indexing, return format, and usage steps. However, it fails to cover the 'author_agent' and 'reason' parameters, and does not mention overwrite behavior or error handling. This leaves gaps for an agent to use the tool correctly in all scenarios.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must add meaning. It does well for 'name' (implied in path) and 'files' (package-relative paths, must include SKILL.md). However, it entirely omits 'author_agent' and 'reason', leaving two out of four parameters unexplained. This significantly reduces the value added over the raw schema.

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

Purpose5/5

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

The description clearly states the tool's purpose: storing a runnable skill package (SKILL.md + scripts/templates) verbatim under shared/skills/<name>/. It specifies the required content (must include SKILL.md) and distinguishes it from 'write' which handles single markdown notes. The verb 'Store' and resource 'skill PACKAGE' are specific and unambiguous.

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

Usage Guidelines4/5

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

The description provides explicit usage guidance: it contrasts with 'write' (no frontmatter, no template check), explains the scenario (pushing a local package), and mentions that 'get_skill' can later install it. It also notes 'text files only'. However, it does not cover when to use this over other siblings like 'search' or 'list', which are less related but could be referenced. Still, the differentiation from the most similar sibling is solid.

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

readB

Read a single memory file by store-relative path.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, and the description only states it is a read operation without confirming idempotency, error conditions, or return format. It implies non-destructiveness but offers minimal behavioral detail beyond the obvious.

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

Conciseness5/5

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

The description is a single sentence that is front-loaded with the action and resource. Every word is functional, and there is no redundancy or filler.

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

Completeness2/5

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

For a simple read operation with one parameter and no output schema, the description lacks key details such as what is returned (file content, metadata, etc.) and any constraints on the path. An agent would need to infer the return value, which is a significant gap.

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

Parameters3/5

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

The description adds the qualifier 'store-relative' to the 'path' parameter, which gives semantic context beyond the schema's basic type string. However, it does not describe format constraints, examples, or the relationship to the store root. Schema coverage is 0%, so the description partially compensates.

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

Purpose5/5

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

The description clearly states the verb 'Read', the resource 'single memory file', and the method 'by store-relative path'. It is concise and distinguishes from siblings like 'search' or 'list' which involve multiple files or content-based retrieval.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as 'search', 'list', or 'get_skill'. The description does not mention prerequisites, context, or exclusion criteria.

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

writeA

Write a memory file (also indexes it). Returns {ok, path}.

There are exactly two layers. `path` is store-relative and starts with one:
  - `shared/...`    — the cross-agent knowledge base (skills/tools/lessons/rules)
  - `personal/...`  — the owner's personal space (free-form)

`layer` is OPTIONAL — leave it out and it's inferred from the path. If you do
pass it, the only valid keys are "shared" and "personal".

Layers are SHARED spaces, not per-author: every connected agent reads and
writes the same paths. `author_agent` only records who wrote an entry
(provenance); it does not partition or hide anything. So `personal/` is "the
owner's personal layer", visible to all connected agents — NOT "this agent's
private space". Truly secret material should not be put in this store at all.

`type` is one of skill|tool|lesson|rule|conversation|note (inferred from the
path if omitted). An explicit type="skill" must include the 5 template
sections, each headed in Chinese OR English: 目标/Goal, 何时用/When to use,
前置/Preconditions, 步骤/Steps, 验证/Verify.
ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
tagsNo
typeNo
layerNo
reasonNo
sourceNo
contentYes
author_agentYes

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description fully discloses indexing behavior, shared space semantics, type constraints for skills, and privacy warnings. All behavioral traits are clearly explained.

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

Conciseness5/5

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

Every sentence adds value; structured logically from core purpose to layer explanation to parameter details. No wasted words.

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

Completeness4/5

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

Comprehensive for 8 parameters with no output schema. Explains return value, layer inference, type requirements, and sharing model. Minor gaps in tags/reason/source descriptions, but these are optional.

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

Parameters4/5

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

Despite 0% schema coverage, the description adds meaning for path, layer, type, author_agent, and content. Tags, reason, and source are not described but are optional. Compensates well.

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

Purpose5/5

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

The description clearly states 'Write a memory file (also indexes it). Returns {ok, path}.' This specifies the action and resource, directly distinguishing from siblings like delete, read, and list.

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

Usage Guidelines4/5

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

Explains the two layers (shared/personal) and when each is appropriate, and notes that author_agent is for provenance only. However, does not explicitly contrast with other tools or state when to avoid using it.

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

Tool Schema Changelog

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

  1. 8 tool updatesv0.0.1
    • First observeddelete
    • First observedget_skill
    • First observedlist
    • First observedlist_skills
    • First observedput_skill
    • First observedread
    • First observedsearch
    • First observedwrite
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation5/5

Each tool serves a distinct purpose: file operations (delete, read, write), skill management (get_skill, put_skill, list_skills), and discovery (list, search). No two tools have overlapping functionality.

Naming Consistency4/5

Names are lowercase with underscores for multi-word tools (e.g., get_skill), but single-word names like delete and read break the pattern slightly. Still, the naming is predictable and readable.

Tool Count5/5

8 tools cover core operations for memory files and skills without bloat. The set is well-scoped for the stated purpose.

Completeness4/5

Covers create/read/delete for files and CRUD for skills except delete_skill. Write presumably overwrites, acting as update. Minor gap: no dedicated skill deletion tool.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • tartarus-mcp

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

  • Engram

    rwnalds
    A
    license
    A
    quality
    A
    maintenance
    A self-hosted MCP server that gives AI agents shared, long-term memory over a git-backed folder of markdown, enabling persistent knowledge search, read, and write without a database.
    16
    21
    11
    MIT

  • memory-mcp

    credp
    A
    license
    B
    quality
    A
    maintenance
    A local MCP server that provides agents with tools to list, read, search, inspect history and diffs, and capture unstructured text in a user-owned Git repository of durable memory.
    5
    MIT

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/H1an1/mem-universe'

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