What can you do with this server?

Trailmem is a persistent, local-first graph memory system for AI agents, allowing them to store, retrieve, edit, and link structured knowledge across sessions. * trailmem_welcome – Get a session-start briefing with pinned rules, recent activity, open tasks, and stats. Repeat calls return a short form unless forced; supports filtering by project/agent type. * trailmem_store – Save new memories (decisions, lessons, tasks, constraints, etc.) with title, content, event/work/agent type, project, source URI, and optional links to existing memories. Built-in duplicate detection prevents junk entries. * trailmem_query – Search memories using combined semantic and keyword matching, with filters for project, memory type, agent type, and archived status. Returns IDs, types, edge counts, and previews. * trailmem_show – Fetch the full content of a single memory, including all typed edges, supersede chains, and edge IDs needed for link management. * trailmem_edit – Update a memory's title, content, type, or pin status, or archive it (archiving requires a reason of 20+ characters and at least one edge). Content edits automatically refresh the hash, embedding, and search index. * trailmem_link – Create or remove typed edges between memories. Supported relationship types: related, derived_from, supersedes, contradicts, and evolves.

Which integrations are available for this server?

Integrates with Windsurf (a Codeium product) as an MCP host, providing persistent local-first graph memory for AI coding agents across sessions.

How do I use trailmem?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@trailmem store that the database connection string is in secrets.toml" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

trailmem

by amitnexTech

Overview Schema Related Servers Score Discussions

Python

Local

trailmem

PyPI Python License: MIT

Persistent, local-first graph memory for AI coding agents.

Trailmem gives agents durable cross-session memory without provider lock-in: a local SQLite knowledge graph, typed relationships, explicit knowledge evolution, and token-disciplined briefings. It is designed for multiple local agents—Claude, Kiro, Codex, OpenCode, Kilo, and Gemini—to share useful project knowledge without silently creating junk memories.

Quick start

Same commands on Windows, macOS, and Linux.

Install (recommended: `uv` — no Python needed)

trailmem is a command-line tool, so install it as one — this puts trailmem on your PATH in every terminal. The cleanest way is uv, a standalone binary that needs no pre-installed Python (it fetches one for you):

# 1. Install uv (standalone — does NOT require Python):
curl -LsSf https://astral.sh/uv/install.sh | sh          # Linux / macOS
# Windows (PowerShell):  powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

# 2. Install trailmem (uv downloads a Python for it if you don't have one):
uv tool install trailmem

Already have Python and prefer pipx? pipx install trailmem then pipx ensurepath works the same way (pipx needs an existing Python).

pip install trailmem

pip install drops the trailmem command into the current Python's bin/Scripts folder, which is often not on your PATH — a global pip install --user or a system Python will leave you with zsh: command not found: trailmem (and on Debian/Ubuntu, a PEP 668 "externally-managed" error). Use uv/pipx above unless you're deliberately working inside an activated virtualenv. If you already ran pip install and hit command not found, either activate the venv you installed into or run it as python -m trailmem — or just switch to uv tool install trailmem.

Set up and register

trailmem setup          # creates ~/.trailmem/, inits DB, downloads the default embedding model (~130 MB, one time)
trailmem doctor         # health check

# Register the MCP server with your agent host(s):
trailmem integrate      # detects installed agent hosts, asks before writing any config

trailmem integrate auto-detects nine hosts: Claude Code, Codex, Kiro, Kilo, OpenCode, Antigravity, Zed, Cursor, Windsurf. It shows what it found, asks once (y/N), backs up every config it touches (.bak-trailmem), and skips hosts that are already registered. Configs are auto-written only for hosts whose format is verified against the live binary — Claude Code (via its own claude mcp add), Codex, Kiro, Kilo, OpenCode, Antigravity. For the other detected hosts it prints the exact entry to paste instead of editing their config (hand-written entries have corrupted host configs before; a host is promoted to auto-write once its format is verified). It also never rewrites a config it can't parse losslessly (JSONC with comments gets the manual entry printed too). On Claude Code, Kilo, and OpenCode it installs a /tm-save slash command; on Codex a /prompts:trailmem-save prompt and a SessionStart hook (~/.codex/hooks.json — trust it via /hooks after restarting Codex); on Kiro a SessionStart hook (~/.kiro/hooks/ — user-level, one install covers every workspace); on Antigravity a deduped PreInvocation welcome hook (~/.gemini/config/hooks.json — injects the briefing once per conversation, restart agy after install). On hosts that read Agent Skills it installs a lazy-loaded trailmem usage skill so agents learn the tool semantics without reading source — user-level on Claude Code, Codex, Kilo, OpenCode; per-workspace on Antigravity (<workspace>/.agents/skills/, the only non-builtin skills dir agy reads — re-run integrate per workspace).

Windows note: the MCP server is registered as python -P -u -m trailmem.mcp_server — never as a generated .exe. Windows Smart App Control silently blocks unsigned per-install launcher .exes (the kind pip/uv generate), which kills a host-spawned server with no error anywhere. If the trailmem CLI itself is blocked by SAC, run it as python -m trailmem from the environment it's installed into.

Saving a session before you exit

An agent that forgets to record memory (or a hard /exit) can drop a session's context — a host end-of-session hook can't help, because it runs after the agent is gone and never sees the conversation. Only the live agent, mid-session, can capture. trailmem gives it a portable trigger plus reminders.

Trigger a save — use whichever your client supports (they all end in the same instruction: extract this session's decisions/lessons/tasks and call trailmem_store):

How	Works in	Invoke
MCP prompt `save_session` (zero-config, portable)	Any client that surfaces MCP prompts	Claude Code `/mcp__trailmem__save_session` · VS Code `/mcp.trailmem.save_session` · Cursor & Windsurf: slash/prompt list · Zed: text threads only
`/tm-save` command (installed by `integrate`)	Claude Code	`/tm-save`
Plain text (always works)	Every client — the `trailmem_store` tool is universal	Type "save this session to trailmem"

Clients with no prompt support (e.g. Codex, aider) use the plain-text path — nothing is lost, the tool is always available. If your agent supports custom slash commands, you can point one at the same instruction yourself; formats differ per host, so check that agent's command-file docs (and avoid the config landmines below).

Reminders so you remember to trigger it:

Statusline — trailmem statusline reports successful creates and edits for the authoritative session ID from hook stdin or env. Without a real session ID it prints nothing.
Welcome tip — the briefing ends with a save reminder (shown by hosts that surface the session-start output, e.g. Codex, Kilo).
Next-session flag — if the previous session stored nothing, the next welcome opens with a loud reminder.

Wiring an unlisted agent yourself? MCP config formats are not uniform, and a wrong guess can break the agent's launch. Known landmines: VS Code / Copilot uses the key servers (not mcpServers); Continue and Goose use YAML (a JSON writer corrupts them); aider has no MCP support at all. Always follow the agent's own current docs. The one thing that works everywhere without any of this is the plain-text path above.

Prefer manual MCP registration? Each host has its own mechanism:

The server launch command everywhere is <python> -P -u -m trailmem.mcp_server, where <python> is the interpreter trailmem is installed into (print it: trailmem doctor shows the home; or python -c "import sys; print(sys.executable)" inside that environment). Add TRAILMEM_AGENT_TYPE=<host> to the entry's env so memories are attributed correctly.

Host	Manual registration
Claude Code	`claude mcp add trailmem -e TRAILMEM_AGENT_TYPE=claude -- <python> -P -u -m trailmem.mcp_server`
Codex	add an `[mcp_servers.trailmem]` table to `$CODEX_HOME/config.toml` (default `~/.codex`)
Kiro	add `trailmem` under `mcpServers` in `~/.kiro/settings/mcp.json`
Kilo	add `trailmem` under `mcp` in `~/.config/kilo/kilo.jsonc` as `{"type":"local","command":["<python>","-u","-m","trailmem.mcp_server"]}` (kilo 7.x format)
OpenCode	add `trailmem` under `mcp` in `~/.config/opencode/opencode.json`
Antigravity	add `trailmem` under `mcpServers` in `~/.gemini/config/mcp_config.json` (no `agy mcp` CLI — file edit only; restart agy)
Zed	add `trailmem` under `context_servers` in `~/.config/zed/settings.json`
Cursor	add `trailmem` under `mcpServers` in `~/.cursor/mcp.json`
Windsurf	add `trailmem` under `mcpServers` in `~/.codeium/windsurf/mcp_config.json`

Any other MCP agent

Trailmem works with any agent that speaks MCP — Cursor, Windsurf, Cline, Zed, Gemini CLI, or anything newer. trailmem integrate only automates the hosts above; for everything else, register it yourself. You need exactly three facts:

Transport: stdio (no URL, no port, no HTTP).
Command: <python> -P -u -m trailmem.mcp_server — the interpreter trailmem is installed into, launched as a module. There is deliberately no trailmem-mcp executable: Windows Smart App Control silently blocks per-install unsigned launcher .exes, which killed host-spawned servers with no error. python -m needs no launcher and works on every OS.
Identity: set TRAILMEM_AGENT_TYPE=<lowercase-agent-slug> for attribution. If the host can expose a stable conversation ID to child processes, also set TRAILMEM_SESSION_ID=<real-id>.

Most agents use a JSON block shaped like this (key name varies — mcpServers, mcp, servers):

{
  "mcpServers": {
    "trailmem": {
      "command": "/path/to/python",
      "args": ["-P", "-u", "-m", "trailmem.mcp_server"],
      "env": {
        "TRAILMEM_AGENT_TYPE": "myagent",
        "TRAILMEM_SESSION_ID": "the-hosts-real-session-id"
      }
    }
  }
}

Print the right interpreter path from inside the environment trailmem is installed into:

python -c "import sys; print(sys.executable)"

TRAILMEM_SESSION_ID is optional. Without it, all six tools still work with agent/project attribution, but welcome is stateless: no boundary, anti-bloat, or zero-save claims. A host can instead pass the optional session_id MCP argument on each call. Never invent a PID as a session ID.

Native host fields do not belong in TrailMem core. Each integration module in trailmem/hosts/ owns detection, native session/project fields, hooks, and config lifecycle, then emits one versioned session_context:

{
  "schema_version": 1,
  "agent_type": "myagent",
  "session_id": "the-hosts-real-session-id",
  "project": "/absolute/project",
  "event": "tool-context",
  "source": "myagent-adapter"
}

Host modules are auto-discovered, so adding a verified integration requires one new trailmem/hosts/<host>.py file. Unknown MCP hosts still work through the generic TRAILMEM_AGENT_TYPE / TRAILMEM_SESSION_ID contract; without a real session ID they intentionally remain stateless.

Then restart the agent and check the wiring: the agent should see six trailmem_* tools, and calling trailmem_welcome should return a briefing. trailmem doctor verifies the database side.

Updating

trailmem update   # checks PyPI, upgrades in place using however you installed it

trailmem update detects whether this copy was installed with uv / pipx / pip and runs the right upgrade command (uv-tool installs need uv tool install trailmem@latest --force — a bare uv tool upgrade is a no-op on a pinned tool, which trailmem update handles for you). Editable/dev installs are refused (upgrade via git). After upgrading, run trailmem integrate once to refresh host configs (it upgrades old entries in place — e.g. the pre-0.1.7 trailmem-mcp launch to the current python -m shape), then restart your agents so their MCP servers reload — a schema migration runs on first start of the new code, and a still-running old server must not keep writing.

Prefer to do it by hand:

uv tool install trailmem@latest --force   # if installed with uv
pipx upgrade trailmem                      # if installed with pipx
pip install --upgrade trailmem             # if installed with pip (inside the venv)

There is no in-app "update available" notice — trailmem sends no telemetry, by design. trailmem update only checks PyPI when you run it.

Uninstalling

trailmem uninstall           # remove trailmem from agent configs — memories are KEPT
trailmem uninstall --purge   # ALSO delete ~/.trailmem (every memory, irreversible)

trailmem uninstall surgically reverses everything integrate (this or any older release) wrote — the trailmem MCP entry in each host's config, the usage skills, /tm-save, the Codex prompt and SessionStart hook — and leaves the rest of every config untouched. Your memories at ~/.trailmem are kept by default: reinstalling trailmem later brings them all back automatically. Only --purge (with a typed confirmation) deletes them. At the end it prints the command to remove the package itself (uv tool uninstall trailmem / pipx uninstall trailmem / pip uninstall trailmem, matching how you installed).

The agent then gets six tools: trailmem_welcome (once-per-session briefing), trailmem_store, trailmem_query, trailmem_show, trailmem_edit, trailmem_link. Everything is also available to humans via the trailmem CLI (store, query, show, list, stats, link, archive, ...).

Try it from the CLI (note: content is positional; --agent user for your own notes):

trailmem store --title "First note" --type lesson --agent user "Something worth remembering."
trailmem query "what did I note earlier"
trailmem list
trailmem help                # or: trailmem <command> --help

Related MCP server: code-recall

Why

Local-first. One SQLite file (~/.trailmem/trailmem.db), WAL mode, no cloud, no daemon. Embeddings run locally via ONNX (default: bge-small-en-v1.5, user-swappable with trailmem model use).
A graph, not a list. Typed edges (related, supersedes, evolves, contradicts, derived_from), orphan warnings at store time, supersede chains instead of destructive overwrites.
Token discipline. Context is injected exactly once per session (welcome, ~600–800 tokens). No per-turn injection, ever. Repeat welcomes return a short form.
No junk memories. 4-band duplicate detection (exact hash reject → >0.92 block → 0.85–0.92 warn → accept), mandatory titles, hard-reject on unattributed stores, no auto-store lifecycle hooks.
No telemetry. The server writes only what the user needs (e.g. a local hooks.log diagnostic); it never emits analytics — a deliberate anti-goal, not an oversight.

Status

v0.1.13 is live on PyPI. Core implemented and tested: schema, store/dedup, query/show, welcome, MCP server, CLI, hooks, model management, loopback dashboard, and host integration. The design contract lives in docs/ — schema, welcome lifecycle, duplicate policy, evolution rules, CLI/MCP surfaces, hooks, seeding playbook, and the dashboard contract.

Community

Please read CONTRIBUTING.md before opening a pull request, CODE_OF_CONDUCT.md for community expectations, and SECURITY.md for private vulnerability reporting.

License

MIT

Available Tools

6 tools

trailmem_editB

Update a memory's content/title/type/pin, or archive it (status='archived' needs archive_reason >=20 chars AND at least one edge). Content edits refresh hash + embedding + search index automatically.

ParametersJSON Schema

Name	Required	Default
`ref`	Yes
`title`	No
`pinned`	No
`status`	No
`content`	No
`link_to`	No
`edge_type`	No	related
`event_type`	No
`archive_reason`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

The description mentions automatic refresh of hash, embedding, and search index upon content edits, which is a useful behavioral detail. But it does not discuss other side effects, idempotency, or required permissions, leaving gaps given no annotations.

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 that front-load the primary function and special conditions. Every sentence adds value without redundancy.

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 9 parameters and no annotations, the description covers only the core operation and one special case. It lacks parameter details, error conditions, and return value context, making it incomplete for a complex tool.

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?

With 0% schema description coverage, the description names a few parameters (content, title, pin, archive_reason) but does not explain their semantics or the full set of 9 parameters. It adds minimal value beyond the schema itself.

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 the tool updates a memory's content/title/type/pin or archives it. It distinguishes itself from sibling tools like trailmem_show and trailmem_store by being the only editing tool, but does not explicitly name alternatives.

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 use for modifying existing memories, and provides specific archiving conditions. However, it lacks explicit guidance on when not to use this tool or comparisons with sibling tools.

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

trailmem_linkB

Create (action='add': source, target, edge_type) or remove (action='remove': edge_id from trailmem_show) a typed edge between memories. Types: related / derived_from / supersedes / contradicts / evolves.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`source`	No
`target`	No
`edge_id`	No
`metadata`	No
`edge_type`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/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 discloses the creation/removal actions and edge types, but lacks details on side effects, idempotency, permissions, or behavior when edges already exist.

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?

Two sentences front-load the core functionality and list edge types. It is efficient but could be slightly more compact by integrating the type list into the first sentence.

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 6 parameters and moderate complexity, the description lacks details on return values, error handling, and validation. It assumes prior knowledge of trailmem_show for removal, leaving gaps in completeness.

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 has 0% description coverage. The description explains the roles of action, source, target, edge_type, and edge_id, but omits metadata. It adds meaningful semantics beyond the schema for most parameters, though not comprehensively.

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 it creates or removes a typed edge between memories, specifying verb and resource. It distinguishes between two actions and mentions a sibling tool (trailmem_show) for removal, but lacks explicit differentiation from all siblings.

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 explains when to use 'add' vs 'remove' and references trailmem_show for removal, but does not provide when-not-to-use guidance or contrast with other siblings like trailmem_edit or trailmem_store.

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

trailmem_queryA

Search memories (semantic + keyword). Returns #id, type, status, edge count [↔N] and a 200-char preview per hit. Use trailmem_show(ref) for full content + edges.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`limit`	No
`project`	No
`type_filter`	No
`agent_filter`	No
`include_archived`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the return fields (#id, type, status, edge count, preview) but does not mention mutation, authentication, rate limits, or safety. The name and purpose imply a read-only search, but this is not explicitly stated.

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 extremely concise: two sentences that front-load the purpose and return format, with no redundant or extraneous words. Every sentence serves a clear function.

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?

Despite having an output schema, the description only briefly mentions return content (e.g., 200-char preview). It does not explain the semantics of 6 parameters, required vs. optional usage, or how filters work. A search tool with this many parameters needs more guidance.

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?

The input schema has 6 parameters with 0% description coverage, and the tool description adds no information about any parameter. The agent must infer meaning from parameter names alone (e.g., text, limit, project), which is insufficient for correct invocation.

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: 'Search memories (semantic + keyword).' It specifies the verb ('Search') and resource ('memories'), and distinguishes itself from sibling tools by noting what it returns and that trailmem_show provides full content.

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 explicitly guides the agent to use trailmem_show for full content, implying when this tool is insufficient. However, it does not provide explicit when-not-to-use scenarios or alternative tools for related tasks like editing or storing.

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

trailmem_showA

Fetch one memory in full: content, all edges (with [eN] ids), supersede chain. The only tool that returns edges — edge ids here are what link remove needs.

ParametersJSON Schema

Name	Required	Description	Default
`ref`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Discloses that it returns edges and that edge IDs are used by other tools (link remove). No annotations provided, so description carries burden; it implies read-only behavior but does not state explicit 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.

Conciseness5/5

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

Two sentences, no fluff. Front-loaded with core purpose and key differentiator.

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?

Describes output well (content, edges, supersede chain), but lacks parameter description. With output schema existing, return values are covered, but input parameter 'ref' is unexplained.

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 coverage is 0% and description does not explain the 'ref' parameter. The agent cannot infer what value to provide (e.g., memory ID, reference string).

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 it fetches a full memory with content, edges, and supersede chain. Distinguishes from siblings by being the only tool that returns edges, which are needed for link remove.

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?

Implies use when you need to retrieve a full memory with edges. Does not explicitly state when not to use, but differentiates from siblings by mentioning edge retrieval.

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

trailmem_storeA

Save a new memory (decision/lesson/task/constraint/...) with optional linking. Store the ENGLISH version of the content; title 3-60 chars, content 50+ chars. Duplicates are rejected/blocked with the existing #id — edit that instead.

ParametersJSON Schema

Name	Required	Default
`force`	No
`title`	Yes
`pinned`	No
`content`	Yes
`link_to`	No
`project`	No
`edge_type`	No	related
`work_type`	No
`agent_type`	No
`event_type`	Yes
`source_uri`	No
`supersedes`	No
`archive_reason`	No
`modified_files`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Discloses memory storage behavior, character limits, and duplicate rejection. With no annotations provided, the description carries the burden; the output schema likely covers return values. No contradictions.

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?

Four sentences, front-loaded with purpose, then constraints and error behavior. No redundant information; each sentence adds value.

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?

Despite good purpose clarity, the high parameter count (14) and 0% schema coverage require much richer description. Missing explanations for optional linking, edge types, force, pinned, etc. Output schema exists but description does not reference it.

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?

Only explains constraints for two parameters (title, content) among 14. Schema coverage is 0%, so description must compensate but fails for most parameters (force, pinned, link_to, etc.). Detailed param semantics are missing.

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 action 'Save a new memory' and specifies the resource types (decision/lesson/task/constraint) with optional linking. It distinguishes from siblings like trailmem_edit (edit) and trailmem_query (query) by focusing on creation.

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 explicit constraints (title 3-60 chars, content 50+ chars, English version) and duplicate handling ('rejected/blocked with existing #id — edit that instead'). Lacks explicit comparison to alternatives beyond duplicates.

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

trailmem_welcomeB

Session-start briefing: pinned rules, recent activity, open tasks, stats. Call once at session start; repeat calls return the short form unless force=true.

ParametersJSON Schema

Name	Required	Description	Default
`force`	No
`project`	No
`agent_type`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses stateful behavior (repeat calls return short form, force=true resets) and output contents. However, it does not mention side effects, auth requirements, or confirm read-only nature.

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 sentences, no wasted words. First sentence front-loads purpose and contents; second sentence adds critical behavioral nuance. Perfectly concise and well-structured.

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?

Covers the core behavior and statefulness, aligning with the simple tool complexity. However, missing parameter documentation (project, agent_type) and lack of any annotations make it incomplete for full autonomous use.

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 coverage is 0% with 3 parameters. Description only explains 'force' partially (for repeat calls). 'project' and 'agent_type' are completely undocumented, leaving the agent without guidance on their purpose or allowed values.

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 the tool's purpose as a 'Session-start briefing' and lists the contents (pinned rules, recent activity, open tasks, stats). This is specific and distinct from siblings like trailmem_query or trailmem_show, though not explicitly differentiated.

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 clear usage guidance: 'Call once at session start' and explains behavior on repeat calls (short form unless force=true). Does not explicitly mention when not to use or alternatives, but the instruction is actionable.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: store creates, edit updates, show retrieves full details, query searches, link manages edges, and welcome initializes sessions. No overlap in functionality.

Naming Consistency5/5

All tools follow the consistent pattern 'trailmem_verb' (e.g., trailmem_edit, trailmem_link), using clear action verbs that directly indicate the tool's operation.

Tool Count5/5

With 6 tools, the set is well-scoped for a memory management system, covering creation, retrieval, search, editing, relationship management, and session start without being overly numerous or insufficient.

Completeness4/5

Covers core CRUD, search, and edge management. Minor gap: no dedicated tool to list all memories or permanent deletion (only archiving), but the toolset is still largely complete for the domain.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Penfield Memory AOAuth
io.github.penfieldlabs
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Knowledge & Memory RAG Systems Vector Databases
26
Ace Memory B
io.github.rudedoggg
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Knowledge & Memory RAG Systems Autonomous Agents
4
AiAkiv Memory
com.aiakiv
Shared long-term memory for AI agents: save and recall context as a searchable knowledge graph.
Knowledge & Memory Autonomous Agents
2
recordari A
io.recordar.api
Persistent knowledge graph for AI-augmented teams. Store decisions, findings, and standing rules across agent sessions with semantic search and typed connections. Includes cross-session memory, audit trail, workspace isolation, and secret detection. Built for teams running agents that need to remember. Free until launch with team tier as default, anon trial available.
Databases Knowledge & Memory Security
162

Related MCP Servers

DevFlow MCP
Knowledge & Memory Developer Tools Autonomous Agents
Takin-Profit
A
license
Not graded
quality
D
maintenance
Provides AI agents with persistent, searchable memory using a knowledge graph stored in SQLite. Features semantic search, temporal awareness, and workflow-aware prompts for development projects.
Updated 10 months ago (2025-11-03 16:28 UTC)
16
MIT
code-recall
Knowledge & Memory Developer Tools
AbianS
A
license
Not graded
quality
C
maintenance
Gives AI coding agents persistent memory by storing observations, decisions, and learnings in a local SQLite database with vector search, full-text search, and a rules engine.
Updated 7 months ago (2026-01-31 12:30 UTC)
4
MIT
Turbo Quant Memory MCP Server
Knowledge & Memory RAG Systems Autonomous Agents
Lexus2016
F
license
Not graded
quality
A
maintenance
Provides persistent, local-first memory with knowledge graph and hybrid search for AI coding agents, reducing token usage by storing decisions, patterns, and codebase context.
Updated 10 days ago (2026-08-25 16:35 UTC)
8
dejaview-mcp
Knowledge & Memory Search
JakeC77
A
license
Not graded
quality
D
maintenance
Provides persistent knowledge graph memory for AI agents, enabling them to store, recall, and query facts about people, projects, and relationships across sessions.
Updated 6 months ago (2026-03-05 08:23 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/amitnexTech/trailmem'

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

trailmem

Quick start

Install (recommended: uv — no Python needed)

Set up and register

Saving a session before you exit

Any other MCP agent

Updating

Uninstalling

Why

Status

Community

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Install (recommended: `uv` — no Python needed)