Claude Memory MCP is a local daemon that gives Claude persistent memory, task/backlog management, and an AI agent team via MCP tools and a web UI.
Persistent memory: store, semantically search, update, delete, or recall memories (decisions, architecture, devops, etc.) per project, with provenance and edit history
Rules enforcement: add mandatory/forbidden rules, bulk-add rules, enforce them via hooks/instructions/tool responses, and block edits when no task is in progress
Task management: add, list, start, update, comment, stop, archive, attach files to, and delete tasks; plan multi-part requests; claim tasks across sessions; track time
AI team management: installed agents (pm, backend, frontend, designer, test, reviewer, devops, docs, and stack experts) that the lead session dispatches
Project management: create, list, rename, load, link folders, switch active project, and get project info
Templates & imports: create/apply rule templates, import rules from other projects (as pending), import CLAUDE.md, and export/import memories as Markdown
Git-synced memory: bind a project to a folder so rules/decisions sync to a committable .claude-memory/ snapshot, with merge-driver support
Digest & cleanup: analyze memory drift, propose operations (merge/rewrite/recategorize/archive), apply only approved changes, and revert
Sessions: start/end sessions that load rules, tasks, summaries, and recent decisions, and store session summaries
Model management: check embedding model info, switch between English/multilingual presets, and re-embed memories
Board mirroring (asoode): attach/link projects to asoode boards, sync tasks/attachments/comments, import/reconcile, and manage credentials
Portability & sync: attach project directories, make the DB portable, and sync after git pull
Management UI: browse/search memories, manage rules/templates, work tasks, inspect sessions/provenance, and use command palette
Enables sharing of project memory across devices and teammates through git sync, with committable JSON snapshots in the project folder.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Claude Memory MCP Remember that we chose Postgres for the database"
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.
Claude Code forgets everything between sessions. This gives it a brain, a backlog, and a team.
One local daemon, three things:
🧠 Memory for Claude | Decisions, rules and architecture notes per project — searched by meaning, reloaded every session, re-injected every turn. |
✅ Task management | A real backlog with states, sub-tasks, comments and a stopwatch — parked mid-session, mirrored to a live board. |
👥 AI team management | Sixteen specialised agents on one shared contract, so the lead session delegates instead of doing everything itself. |
Everything is local: your own DuckDB files, your own embedding model, nothing leaving the machine.
1. Run the daemon. Pick one:
docker run -d --name memory-mcp \
-p 8765:8765 \
-v memory-mcp-data:/data \
kianfar/claude-memory-mcp:latestOr docker compose up -d.
brew tap navid-kianfar/tap
brew install claude-memory-mcp
brew services start claude-memory-mcpSee packaging/homebrew/ for tap setup details.
Requires uv and (for the UI) Node 20+.
git clone https://github.com/navid-kianfar/claude-memory-mcp.git
cd claude-memory-mcp
./install.shinstall.sh installs dependencies, builds the UI, downloads the embedding
model, installs a launchd agent so the daemon auto-starts, points Claude Code at
the daemon, installs the rule-enforcement hooks, and installs the sixteen agents.
It prints a one-time sudo command to add a claude-memory-mcp entry to
/etc/hosts so the UI resolves at http://claude-memory-mcp:8765/.
2. Connect Claude Code:
claude mcp add --transport http memory http://localhost:8765/mcp3. Open the UI at http://localhost:8765/ and create a project — or do it from Claude:
memory_init_project("my-app", "My App") # create a project
memory_session_start("my-app") # loads rules, tasks, last summary4. Use it. From here Claude stores decisions and rules as they are made, and recalls them by meaning:
"Always use pnpm, never npm" -> memory_add_rule(...) a mandatory rule
"We're going with Postgres because ..." -> memory_store(...) a decision
"What database did we pick?" -> memory_search(...) finds it next month
"Add a task to rewrite the CSV exporter" -> memory_task_add(...) queued, not startedEvery later session starts by loading that project's rules, open tasks, last summary and recent decisions. Nothing to re-explain.
flowchart LR
subgraph clients[Claude Code]
CLI[Terminal CLI]
APP[Desktop app]
end
UI[Management UI<br/>React + command palette]
subgraph daemon[memory-mcp daemon · port 8765]
MCP[/MCP endpoint /mcp/]
API[/JSON API /api/]
EMB[Embedding model<br/>loaded once]
end
DB[(Per-project<br/>DuckDB + vector index)]
CLI -->|HTTP| MCP
APP -->|HTTP| MCP
UI -->|HTTP| API
MCP --> DB
API --> DB
MCP --- EMBBoth Claude Code clients and the UI talk to the same daemon, which is the sole owner of the DuckDB files — the embedding model loads once, and there are no database lock conflicts between clients.
Each project gets an isolated DuckDB database with an HNSW cosine vector index. Memory never leaks between projects, and searching is semantic: ask "what database did we pick?" and it finds the Postgres decision even if you never typed "Postgres".
Memories are categorised — decision, architecture, devops, feedback,
sprint, reference, developer_docs, project_plan — and every one carries
provenance and edit history.
Related MCP server: Claude Persistent Memory
Rules you set (mandatory_rules / forbidden_rules) are enforced three ways,
because one is not enough:
Hook injection — a UserPromptSubmit hook injects the actual rule text
into context every turn, so rules survive context compaction.
Server instructions — the MCP server tells Claude to load and honor rules.
Tool responses — search/store responses carry a compact rules reminder.
Those three all do the same thing: they tell Claude. That is enough for a rule that shapes judgement, and demonstrably not enough for one that must happen every single time — a rule saying "put the work on the board before doing it" held about 70% of the time. So there is a fourth, different in kind:
A PreToolUse gate that can REFUSE. On Edit, Write and NotebookEdit
it asks the daemon whether a task is in progress, and blocks the tool call when
an asoode-bound project has none — replying with the exact calls to make
(memory_task_plan, or memory_task_add + memory_task_start). It is the only
hook here whose exit status decides whether the tool runs.
It fails open on every path: not a memory project, not bound to a board, daemon unreachable, timeout, unreadable answer, or any unexpected error. A gate that stopped you editing a file because a board was down would be worse than the problem it fixes.
To switch it off, set MEMORY_MCP_NO_GATE=1. Reads are never gated, so
exploring, searching and diagnosing are untouched either way.
Hooks stay silent in directories that are not registered memory projects, so they can be installed globally without noise.
Define a baseline rule set once, then start every new project from it — picking exactly which rules with checkboxes — instead of retyping them.
A new project can also import selected rules from any existing project:
Rules written for one project carry that project's specifics — its component
names, its paths, its stack. Copied verbatim into another project they read as
authoritative and quietly steer the agent wrong. So memory_import_rules (and
the UI's Import dialog) brings them in as pending:
stored and visible in the Pending tab, but not in force — kept out of the injected rule block, out of search, out of session context, and out of the git snapshot;
surfaced at the next memory_session_start with a brief telling the agent to
rewrite each one for this codebase, and to ask you rather than guess when
a rule cannot be translated without knowing something only you know;
activated by memory_adapt_pending(memory_id, title, content) — which clears
the flag, puts the rule in force from that moment on, and lets it sync — or
dropped with memory_discard_pending(memory_id, reason).
Pass pending=False to import text you already know is project-neutral.
A corpus written to for months drifts. Two rules end up saying the same thing in
different words and both are in force, so whichever the agent reads last
effectively wins. A rule names a file that was deleted. A standing instruction
sits in a decision memory where nothing enforces it. A note nobody has recalled
in a year costs tokens in every session that touches its topic.
memory_digest is the pass that fixes that, on any project this server holds:
memory_digest() # analyse — read-only, changes nothing
memory_digest_propose(operations) # validate + diff, still changes nothing
memory_digest_apply(digest_id, approve=[...]) # only what you approved
memory_digest_revert(digest_id) # exact undoThe three stages exist because of who is good at what. The store measures what it can measure exactly: embedding distance between every pair, paths that no longer exist on disk, expired TTLs, rules written as records and records written as rules, notes never once recalled. The agent does the judgment — which overlapping rules are really one rule, whether a missing path moved or died — and it is told to verify anything the signals claim about the code before trusting it. You decide what actually gets written.
Operations: keep, rewrite, merge, split, recategorize, retag,
reprioritize, archive. merge is the one that earns the feature — several
memories unified into one, the sources archived and stamped with where they went.
recategorize is how a rule filed as a decision starts being enforced, and how a
one-off record filed as a rule stops costing rule-block tokens.
A digest never hard-deletes. Its strongest operation is archive: the row
stays, its provenance stays, memory_digest_revert brings it back. Every write
saves the row it overwrote first, so the undo restores the old text exactly
rather than re-deriving it.
No clause disappears quietly. "Unify these and write them better" is where a
business rule actually gets lost — and mostly not by deletion. So every
rewrite, merge and split is checked clause by clause against its sources,
for the four different ways a rule goes missing:
what it catches | |
| a clause the replacement does not account for at all |
| a clause still there, but no longer making the same kind of statement — a threshold, a deadline, a quantifier, |
| a clause that came back inverted, in either direction |
| an obligation in the replacement that no source memory contains — a rule the digest wrote rather than you |
Each comes back with the offending text verbatim. approve_all refuses all four;
they need approving by op id.
The altered check is the one that earns its keep, and it exists because a
threshold cannot be caught by a similarity score. "must come back in under 200ms
at the 99th percentile, measured at the load balancer" is sixteen significant
words, so changing 200ms to 500ms still scores 75% word overlap. The number is one
token however long the sentence is, so the words a rule turns on — figures,
modals, only, every, deadlines — are checked one by one instead of averaged.
They are compared as classes, not as exact words, so a merge may rewrite
always run the tests as run the tests before every commit without being
flagged, while must becoming should is.
Polarity is watched separately because similarity is blind to it: always deploy on Friday and never deploy on Friday sit 0.05 apart in embedding space, closer than two honest paraphrases of the same rule. A pair of memories that contradict each other is therefore never offered as a duplicate — the agent is told to show you both and ask which one is current.
Nothing is applied without a per-operation decision, the whole apply is one
transaction, and each write records provenance naming the digest that made it.
memory_digest_list shows past digests and any proposal still waiting on you.
memory_import_claude_md("/path/to/project") # import into memory
memory_import_claude_md("/path/to/project", stub_rewrite=True) # + slim the fileHeadings map to categories (rules, architecture, decisions, devops, docs); rule
sections are split per bullet. With stub_rewrite, CLAUDE.md is replaced by a
short pointer at memory MCP, and the original is backed up.
Bind a project to its source folder and its memory travels with the code — across your devices and your teammates:
memory_link_folder("/path/to/project")You can also set the folder when creating a project: the New Project dialog has
a Project folder field, and memory_load_from_folder binds it automatically.
Once bound, the project's rules and decisions mirror to a committable
.claude-memory/ snapshot in the project folder — a memory.duckdb
carrying the memories, both rule kinds and the audit trail, alongside a small
manifest.json. A git push carries the latest memory; a teammate's git pull
plus their next session imports it back. Export runs at the end of each turn and
import at session start (both via hooks); the central database stays the daemon's
fast working copy.
It used to be one JSON file per category. Those grew without bound — one project here reached 1.1MB, rewritten in full on every export, so every session added another large blob to git history. A migration is automatic: the first import in a project that still has JSON reads it, writes the database, verifies the rows came back, and only then deletes the JSON.
manifest.json deliberately stays JSON. context reads it on every project
detection, walking up from the working directory, and putting a DuckDB open and
its file lock on that path would be a real regression. It is ~300 bytes and does
not grow.
On size: the win arrives with scale, not immediately. On this repo, 8 JSON files were 131KB raw / 39KB compressed and the database is 291KB / 48KB — slightly worse. At roughly eight times the data it is 1.08MB / 223KB versus 668KB / 96KB. The consistent win is in git history, where a small binary delta replaces a full rewrite of several large text files every session.
Import is safe by design: absence is never deletion. It adds new entries and applies edits that are strictly newer, and it never reverts a more recent local change. The one exception is an explicit tombstone — the record of somebody running a hard delete — which is a different thing from a row simply being missing, and without which a delete could never reach another machine. Even then a local edit newer than the tombstone wins. Each project's memory is separate, so sharing one never exposes the others.
A DuckDB file is a binary blob to git, so memory-mcp-setup registers a git
merge driver and a .gitattributes entry for it. When two machines both add a
rule, the driver merges them with SQL — union what each side added, last write
wins on a genuine conflict, union the audit trail — instead of git's default of
taking one side and silently discarding the other's memories. Install
memory-mcp-setup on every machine that clones the repo: without the driver
registered locally, git falls back to that default.
The snapshot's manifest.json carries a project_id, the project's stable
identity. Because it is committed with the code, moving or renaming the project
folder re-binds the existing project instead of registering a duplicate, and a
teammate's clone resolves to the same project on their machine.
If memory is not reaching the snapshot, look at
~/.claude-memory-mcp/sync.log. The hooks discard the sync command's stderr so it can never disturb a Claude turn, so every failure writes a dated traceback there instead. Export also warns when.claude-memory/is gitignored, since an ignored snapshot never reaches your teammates.
A task is a queued requirement, not an instruction. That is the whole point: you can record something mid-session without derailing the work in progress.
memory_task_add("Rewrite the CSV exporter") # queued; Claude keeps doing what it was doing
memory_task_list() # what is waiting, open work first
memory_task_start(task_id) # claims it, clocks on, moves it to in_progress
memory_task_update(task_id, state="blocked") # stops the clock and says why
memory_task_done(task_id, note="shipped") # closes it and stops the clockmemory_session_start returns the open tasks with a brief telling Claude to
report them and start none of them unless you ask. Work Claude notices but
is not doing goes in with source="claude".
Tasks have states, priorities, labels, due dates, sub-tasks, comments, attachments and a stopwatch, and they live in their own DuckDB tables — never in the committed memory snapshot, however long the list grows.
The clock is symmetric. memory_task_start opens a time entry stamped with
the session that started it; every path that ends the work closes it — done, an
update to any state other than in_progress, stop, release, archive, and
memory_session_end, which reports any clock it had to stop for a session that
forgot. A lease a session never refreshed for an hour is swept at the next
session start, so a crashed session cannot leave a task clocking.
When several Claude sessions share one project, a task is taken by claiming it:
memory_task_claim_next(session_id) — which a session calls only when it has
finished what it was doing, never mid-task. The claim is a conditional UPDATE
whose rowcount decides the winner, held on a 30-minute lease that renews as the
task is worked on, and released by memory_session_end.
memory_task_plan(request, tasks) records a request with several separable
deliverables as an ordered set of tasks — your wording kept verbatim on each one
— which are then worked top-down. If the session ends after the first, the rest
are still in the queue rather than only in the transcript.
The boundary is one task per deliverable, not per step: a question, or a
single change described in several clauses, is not a plan. Fewer than 2 tasks is
rejected (that is memory_task_add), more than 20 is over the cap, and a task
with no description is refused — over-decomposition buries a board in rows
nobody would plan around.
memory_task_attach(task_id, path) copies a file into the task store and mirrors
it to the remote task — a screenshot proving a fix, a failing log, a generated
report. Content-addressed, so the same file on two tasks is one blob; sent once,
because no platform gives an attachment an idempotency key. Attaching bytes a
task already holds returns the existing attachment instead of uploading it
twice, and memory_task_detach(attachment_id) removes one — locally and from
the remote card.
Files pasted into the Claude compose box. The client keeps a pasted image
only as base64 inside the session transcript — there is no file path. The hooks
hand the transcript to the daemon, which copies each image you pasted into the
store and parks it; images the model produced itself (screenshots, rendered
PDF pages) are never taken. Nothing is attached without asking: the session is
told which task is in progress and asks you, and on a yes calls
memory_task_attach(task_id, pending_id=...).
Mirror a project's task list onto an asoode board so the work is visible outside the terminal. The endpoints default to the hosted service, so on-premise is the only case that needs configuring.
The access token is stored once per machine, not per project — every project that talks to the same asoode reuses it:
memory-mcp asoode set-pat # prompts; the input is not echoed
memory-mcp asoode check # prove it reaches the server
memory-mcp asoode boards # list boards you can attach to
memory-mcp asoode attach <slug> --ref <ref> # link an EXISTING board
memory-mcp asoode link <slug> # CREATE a project + board
memory-mcp asoode import <slug> # pull board tasks into the local list
memory-mcp asoode push <slug> # full reconciliation (rarely needed)
memory-mcp asoode open <slug> # open that board already signed inUse attach when the boards already exist, which is the normal case — link
creates one, so running it on a set-up workspace adds a duplicate beside the
real boards.
These commands ask the running daemon to do the work rather than opening the
project database themselves. DuckDB allows one writer per file across processes
and the daemon holds that lock, so doing it in-process used to fail — and fail
late, after the remote calls had already gone out, leaving tasks on the board
the local store had no record of. With no daemon running they fall back to direct
access, and any other path that hits the lock says so and offers both ways out
instead of raising a DuckDB IOException.
The token lives in the local registry (~/.claude-memory-mcp/registry.db), never
in the committed .claude-memory/ snapshot, and is never printed back — status
shows only a prefix…last4 fingerprint. Pass --api-url to store one for a
second server.
open uses asoode's /auth/token deep link, which carries the token in the URL
fragment — never sent to the server, never in an access log, never leaked
through a Referer, and stripped from the address bar on arrival. The link goes
straight to the browser and is printed redacted; no HTTP route returns or
redirects to it, which would put the token in a response body or a Location
header.
A project links to work packages, never to an asoode project. asoode has no
route attaching a task to a project — project → work package → list → task is
the only path — so a monorepo links to one board per app:
memory-mcp asoode attach myrepo --ref myrepo:backend # the default
memory-mcp asoode attach myrepo --ref myrepo:frontend --not-defaultmemory_task_add(title=..., target="myrepo:frontend") names the board a task
belongs to; a task with no target routes to the default link. A wrong name
fails the create rather than landing on the wrong board.
Out — everything, the moment it changes. State (including
memory_task_start moving a card to In Progress), title, description, priority,
assignee (matched to a member by email, username or full name), labels, dates,
estimate, comments with their kind and author, attachments and their removal,
sub-task parents, archive, delete (the card is archived — asoode has no delete —
and a local tombstone stops it re-importing) and every closed time entry.
Each mutation queues to an outbox and flushes off-thread, so a local write never waits on the network. A card the flusher creates gets every field the task already has. An unreachable asoode is a delay, not a lost edit: an outage never counts against a row, only a rejected call does, and a row is abandoned after five of those so a poison row cannot loop forever repeating a side effect. A nudge landing mid-flush makes it go round again; the daemon sweeps every linked outbox on start and once a minute; a short-lived process waits for its own mirrors before exiting.
In — creates only. The daemon holds a Socket.IO subscription, so a task added
on the board reaches the session within seconds. That is an optimisation, not a
correctness requirement: reconcile also runs after every mirror, so a dropped
socket degrades to polling. asoode replays nothing, so every connect (the first
one included — the daemon was deaf before it started) drains each linked outbox
and reconciles each linked project once, floored at five minutes so a flapping
socket cannot spend its life sweeping; the catch-up asks the change feed which
boards moved and advances its watermark only after every reconcile it covers
succeeded. GET /api/asoode/socket reports connection, events, reconciles,
catch-ups and suppressed echoes.
A task that exists on both sides is left alone, because resolving a two-sided
edit needs a conflict policy that has not been decided.
memory_asoode_import is the explicit path that does overwrite local title and
state. Say what each direction carries rather than calling the two sides "in
sync".
The socket needs a ticket, not the PAT. asoode's gateway keeps no database
and verifies signed JWTs only, so the PAT is exchanged at
POST /account/socket-token on each connect. A raw PAT is accepted and then
dropped with transport error.
Our own writes are not reacted to. asoode broadcasts every change to every member, deliberately does not exclude the actor, and drops the actor id before the client sees it — so the payload cannot be used to tell. The writer records what it wrote and the listener consults it: a push of 29 tasks now produces 29 suppressed echoes and zero board reads, where it used to cost seven.
A bound project's memory_session_start returns the board's open tasks and a
brief telling the agent to work them one at a time — start (which claims,
clocks on and moves the card), comment as it goes, mark done or pause with the
reason (both stop the clock), next. An unbound project keeps the opposite
contract: its queued tasks are surfaced and never started, so parking a
requirement mid-session cannot derail the session. The loop binds the lead
session; a dispatched agent works the task it was briefed on.
The binding is the whole opt-in — nothing is configured per project. If the board cannot be reached, the session still starts and is told to work the local list, which is the same queue mirrored.
memory-mcp asoode set-url --api https://api.asoode.internalThe sibling app./socket. URLs are derived when the host looks like
api.<domain>; otherwise pass --app and --socket too. reset-url returns to
the hosted defaults.
link and push are idempotent: the board carries the project's stable uid as
its externalRef and each task carries its local id, so asoode returns the
existing row instead of creating a duplicate. Re-running pushes changes.
The bridge is provider-agnostic: TaskProvider (a Protocol), a registry that
resolves a link's provider column, per-(provider, account) credentials, and a
conformance suite any implementation must pass. asoode is the only provider
shipped, because an integration written from published docs and tested against a
fake written in this repo is not a verified integration.
memory-mcp-setup installs sixteen specialised agents to ~/.claude/agents/
from agents/ — eight roles, and eight stack experts that extend a
role:
Roles | Stack experts |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The first six experts extend backend, the last two extend frontend. An expert
is consulted before its role to decide the layout, and dispatched instead of
it when the work is that stack through and through.
kotlinandappare not interchangeable —appowns Kotlin Multiplatform for phones,kotlinowns Kotlin on a server. Both say so in their own definition, because a brief sent to the wrong one wastes a whole dispatch.
Every definition carries three sections, and a test asserts all sixteen do: Non-negotiables (the opinions it will not re-litigate per task, each with its reason), Currency without hallucination (read the target's own versions, name the release a feature arrived in, mark unverified what cannot be confirmed), and What you produce (exactly what the hand-off contains, so the next agent does not need a second dispatch).
The session talking to you is the lead. It orchestrates directly and
dispatches specialists; it never dispatches a pm to do that, because a
subagent's output is never shown to you and cannot be redirected once running.
Every definition extends: the shared base agents/_base.md,
composed at install time, so the contract that makes the three modules complete
each other is stated once:
brain — session start, the binding rules, search before deciding, store
what outlives the task, project= on every write;
tasks — start claims and clocks on, comment as you go, stop the clock on
every finish, session end last, each with the agent's own session_id
(subagents share the lead's MCP connection, so a borrowed id displaces it);
team — cross-boundary changes are reported to the lead, not made; test
verifies a change on the running product before it is committed.
A dispatch costs roughly 60k tokens at the floor, so the lead does one-file work
itself and delegates genuine specialisms or genuinely parallel work (frontend
and backend can run at once; they share the one checkout unless the user turns
on worktree isolation in the Claude interface, so each gets a disjoint file set).
See agents/README.md for the composition rules and
docs/bridge/06-agent-team.md for the design and
what was verified by dispatch.
A React single-page app served by the daemon at /:
Browse, search, create, edit and archive memories in every category
Manage mandatory/forbidden rules, templates, and pending imported rules
Work the task list: grouped by state, drag to reorder, inline add per group, and a task dialog with sub-tasks, comments, an activity trail and a stopwatch
Inspect sessions and per-memory provenance/history
Switch and set the active project
Cmd+K command palette for fast navigation and actions
All 74 tools:
Area | Tools |
Projects |
|
Memories |
|
Rules |
|
Governance (server mode) |
|
Templates |
|
Imported rules |
|
Digest |
|
Tasks |
|
Task claims (multi-session) |
|
Planning |
|
Sessions |
|
Portability |
|
Import/Export |
|
Model |
|
asoode bridge |
|
Attachments |
|
Misc |
|
memory-mcp serve # run the shared HTTP daemon (MCP + UI)
memory-mcp stdio # run the MCP server over stdio (legacy / fallback)
memory-mcp setup # interactive setup (hooks, agents, launchd, MCP)
memory-mcp update # rebuild the runtime from source and reload the daemon
memory-mcp rules # print the current project's rules (used by hooks)
memory-mcp sync ... # export/import the memory snapshot (used by hooks)
memory-mcp asoode ... # board endpoints and the machine-wide PAT
memory-mcp provider ... # task platforms and their credentials
memory-mcp bind ... # route a project to a local or remote backend
memory-mcp user ... # server-mode users: create, list, rotate tokensEnvironment variables (prefix MEMORY_MCP_):
Variable | Default | Purpose |
|
| Where databases are stored |
|
| Daemon bind address ( |
|
| Daemon port |
|
| Hostname used in the UI URL |
|
| asoode REST base (on-premise override) |
|
| asoode web app, for links |
|
| asoode realtime origin |
Python + FastMCP — the MCP server and HTTP daemon (Starlette + uvicorn)
DuckDB + VSS — per-project memory storage with an HNSW cosine vector index
SQLite — the local registry (project list + app settings); stdlib, no extra dependency
sentence-transformers — local embeddings (all-MiniLM-L6-v2, 384-dim;
a 50+ language multilingual preset is also available)
Layered design — repositories → services → container → tool/HTTP layer
React + Vite + Tailwind — the management UI, with hand-built shadcn-style components
Tasks live in their own DuckDB tables (tasks, task_comments,
task_time_entries) rather than as a memory category — which is what keeps them
out of the git-committed .claude-memory/ snapshot however long the list grows.
Existing databases are migrated automatically on open, so older project databases keep working after upgrades.
uv sync --all-extras
uv run pytest -v # backend tests
cd frontend
npm install
npm run dev # UI dev server (proxies the API to the daemon)
npm run build # production build into frontend/distRun the daemon directly with uv run memory-mcp serve.
The Docker image is published only for tagged releases — never on ordinary commits. Cut a release with the helper script:
./scripts/release.sh # patch bump (0.7.0 -> 0.7.1)
./scripts/release.sh minor # 0.7.0 -> 0.8.0
./scripts/release.sh 1.2.3 # explicit versionIt runs the tests, bumps the version in pyproject.toml and the package,
commits, creates a vX.Y.Z tag, and pushes. The tag push triggers the workflow
that builds and publishes the multi-arch image to Docker Hub.
MIT — see LICENSE.
Add a project rule. rule_type is 'mandatory' (always do) or 'forbidden' (never do). The rule is enforced in every future session.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| content | Yes | ||
| project | No | ||
| priority | No | ||
| rule_type | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses that rules apply to future sessions, but omits details like overwriting behavior, duplicate handling, or limits. Adequate but not rich.
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?
Two concise sentences with front-loaded verb ('Add a project rule'). No wasted words; all information is relevant.
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 an output schema, the description lacks parameter explanations and usage context. For a tool with 5 parameters, this is insufficient for complete understanding.
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%, so description must compensate. It only explains rule_type ('mandatory'/'forbidden') and ignores title, content, project, and priority. Minimal added value for 5 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 states the tool adds a project rule, differentiating it from siblings like memory_add_rule_bulk and memory_update_rule. It specifies the two rule types (mandatory/forbidden), making the purpose unambiguous.
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., bulk add, update, delete). The description only implies that rules are enforced in future sessions, but does not clarify prerequisites or context for using the project parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one rule to many projects at once.
rule_type is 'mandatory' or 'forbidden'. projects=None adds it to every registered project; otherwise pass a list of project slugs. Lets you push a rule to all your projects without doing it one by one.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| content | Yes | ||
| priority | No | ||
| projects | No | ||
| rule_type | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains parameter behavior (rule_type values, projects=None meaning) but does not mention side effects, authorization, or error cases. Adequate but not comprehensive.
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?
Three sentences: purpose, parameter explanation, use case. No redundant information. Front-loaded main 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?
Given 5 params, no schema descriptions, but output schema exists. Describes key parameters and use cases. Misses priority semantics and constraints, but sufficient for typical usage.
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 0%, so description must compensate. Covers rule_type (mandatory/forbidden) and projects (null vs list). Missing details for title, content, priority beyond default. Partial coverage.
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 verb 'Add', resource 'rule', and scope 'many projects at once'. Distinguishes from sibling 'memory_add_rule' by specifying bulk behavior.
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?
Explicitly describes when to use (add rule to multiple projects, especially all) and alternatives (doing it one by one via memory_add_rule). Lacks explicit when-not-to-use but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a rule to a template (by template name). rule_type is 'mandatory' or 'forbidden'.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| content | Yes | ||
| priority | No | ||
| template | Yes | ||
| rule_type | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It explains rule_type values but does not mention whether the rule is appended or inserted, effects on existing rules, or required permissions. This leaves significant ambiguity for an agent.
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 two short sentences, front-loading the essential purpose and the key constraint on rule_type. Every word serves a purpose with no redundancy.
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 an output schema exists, return values need not be described. However, for a 5-parameter tool with 4 required fields, the description covers only two parameters adequately. Information on priority defaults (default 2) and formatting of content is missing, limiting completeness.
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 has 0% description coverage, so the description must compensate. It adds meaning to 'template' (by name) and 'rule_type' (mandatory/forbidden), but provides no explanation for 'title', 'content', or 'priority'. A baseline score of 3 is appropriate given partial value.
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 ('Add a rule to a template') and specifies the identifying field ('by template name'). It also clarifies the two permitted values for rule_type ('mandatory' or 'forbidden'), distinguishing it from sibling tools like memory_add_rule which add rules directly.
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 when adding a rule to a template, but provides no explicit guidance on when to prefer this tool over alternatives like memory_add_rule_bulk or memory_update_rule. 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.
Apply a template's rules/memories into a project (by template name).
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| template | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'apply a template's rules/memories into a project' but does not specify whether this merges or overwrites existing content, whether it is idempotent, or what permissions are required. The vague verb 'apply' leaves critical behavior unspecified.
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 brief sentence, which is efficient. However, it sacrifices necessary detail for brevity. It is front-loaded with the verb but lacks substantive 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?
Given the existence of an output schema (unknown content) and two parameters, the description is insufficiently complete. It does not explain return values, side effects, or how the template is applied. The tool is part of a large ecosystem, but the description provides minimal context.
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 0%, yet the description does not explain the parameters. The template parameter is mentioned only as 'by template name' with no format or constraints. The project parameter is completely ignored. This fails to add meaning beyond the basic schema definition.
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 'Apply' and identifies both the resource (template's rules/memories) and the target (project). It distinguishes from other memory tools like memory_add_template_rule or memory_list_templates. However, 'by template name' is slightly ambiguous—it could mean the template identifier is a name, but the schema confirms template is a string.
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., memory_add_template_rule, memory_create_template). There is no mention of prerequisites or context for application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach an existing project directory. Auto-activates on success.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | ||
| description | No | ||
| display_name | No | ||
| project_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions 'Auto-activates on success' but does not disclose side effects (e.g., what happens to previously attached projects), permissions, or error conditions. Behavioral transparency is poor.
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 concise with two short sentences. However, it sacrifices necessary detail for brevity. Structure is clean but incomplete.
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 an output schema, the description doesn't explain what the tool returns or what constitutes a successful attachment. No context about the project_path format, whether it's relative/absolute, or what 'attach' means in terms of state changes.
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?
Input schema has 0% description coverage, and the description adds no parameter details. The 4 parameters (slug, description, display_name, project_path) are not explained at all, leaving the agent to guess their meaning.
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 ('Attach an existing project directory') with a specific verb and resource. It implies the project already exists, distinguishing it from memory_init_project, but does not explicitly differentiate from siblings like memory_load_from_folder or memory_link_folder.
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. No context about prerequisites or scenarios where this tool is appropriate. The description lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a newer version of the Memory MCP server is available.
Queries GitHub Releases first, falls back to git commit comparison. Does NOT modify anything - it only reports. Returns step-by-step update instructions when a new version is available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it queries GitHub Releases first, falls back to git commit comparison, and asserts it does not modify anything. This gives the agent confidence in its read-only nature and the fallback logic.
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 concise with four short sentences. The main purpose is front-loaded, and every sentence adds value: purpose, method, side-effect clarification, and output description. No wasted words.
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 check tool with an output schema and zero parameters, the description provides complete context: purpose, method (two fallback sources), side-effect clarification (no modification), and output (update instructions). Nothing is missing.
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 tool has zero parameters and schema coverage is 100%. The description adds no parameter information (as none are needed) but explains the internal process and output. Baseline for zero params is 4, and the description meets that.
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 explicitly states the tool's purpose: 'Check if a newer version of the Memory MCP server is available.' This is a specific verb+resource pair, and it clearly distinguishes from siblings like 'memory_version' (which likely reports current version) and 'memory_update' (which likely performs the update).
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 explains when to use the tool ('Check if a newer version is available') and what it returns ('step-by-step update instructions'). It explicitly states that it does not modify anything, which implies it is safe for read-only checks. However, it does not explicitly mention when not to use it or list alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a reusable template - a named set of default rules/memories that can be applied when creating new projects so they need not be re-typed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It reveals the tool creates a named set of default rules/memories that are reusable. However, it does not disclose behavior on duplicate names, whether it modifies existing templates, or any side effects. Basic transparency but missing important 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?
The description is a single sentence that is front-loaded with the action and clearly states the tool's purpose. No unnecessary words.
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 there is an output schema, return value explanation is not needed. However, with 2 parameters and 1 required, the description does not address behavior on duplicate template names or any prerequisites. It is adequate for a simple creation tool but could add context about conflict handling.
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%, so the description should explain parameters. It only hints at the 'name' parameter (as a named set) but completely omits the optional 'description' parameter. It adds no value beyond the schema for either parameter.
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 gives a specific verb ('Create') and resource ('reusable template'), and clearly explains what a template is ('named set of default rules/memories') and its use case ('applied when creating new projects so they need not be re-typed'). This distinguishes it from sibling tools like memory_list_templates or memory_apply_template.
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 the tool should be used to create a template for new projects, but it doesn't explicitly state when to use this vs. alternatives like memory_add_template_rule or memory_apply_template. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Soft-delete (archive) or hard-delete a memory.
| Name | Required | Description | Default |
|---|---|---|---|
| hard | No | ||
| reason | No | ||
| project | No | ||
| memory_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It discloses the two deletion modes but omits details about reversibility, side effects, permissions, or return values. The output schema exists but is not referenced.
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 waste. However, it could be slightly longer to cover key aspects 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 has 4 parameters, no annotation, and no schema-level descriptions, the description is too sparse. It fails to explain the difference between soft and hard delete, and does not mention output or error conditions.
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%, and the description does not explain any of the four parameters (hard, reason, project, memory_id). The agent gains no insight into what these parameters control or their valid values.
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 (delete) and the two modes (soft-delete/archive and hard-delete), effectively distinguishing it from sibling tools like memory_update or memory_store.
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 soft vs hard delete, or when to choose this tool over alternatives. The description lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a rule by its id. Soft-deletes (archives) unless hard=True.
| Name | Required | Description | Default |
|---|---|---|---|
| hard | No | ||
| project | No | ||
| rule_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the key behavioral nuance: soft-deletes by default, hard deletes with hard=True. Lacks details on authentication 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?
Two sentences, front-loaded with primary action, no redundant text. Every clause adds value.
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?
Covers core delete behavior and soft/hard distinction, but misses documenting the project parameter. Given output schema exists, return format is not needed, but missing parameter info is a gap.
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?
With 0% schema description coverage, description must compensate. It only clarifies rule_id and hard behavior, ignoring the project parameter entirely, leaving its purpose ambiguous.
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 'Delete a rule by its id', specifying the action (delete) and resource (rule), distinguishing it from sibling tools like memory_delete which targets memories.
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 context by describing soft-delete vs hard delete ('unless hard=True'), but does not explicitly compare with alternatives like memory_delete or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export all active memories to human-readable .md files.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| export_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It does not disclose whether files are overwritten, if a directory is created, how memories are organized (e.g., one file per memory), or any side effects. Critical behavioral details are 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 concise sentence, which is efficient for a simple purpose. However, it lacks structure (e.g., bullet points) that could improve readability, but it does not contain unnecessary words.
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 presence of many sibling tools and the simplicity of the schema, the description is insufficient. It omits parameter details, output structure (though output schema exists, the description could still clarify), and usage context. An agent would struggle to determine if this is the right tool for a given task.
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 has 0% description coverage for parameters, and the description does not explain the 'project' parameter or the format of 'export_path'. An agent cannot infer that 'project' likely filters memories by project or that the path should point to a directory. Parameter meanings are entirely opaque.
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 that the tool exports all active memories to human-readable .md files, specifying the verb (Export), resource (active memories), and output format. This distinguishes it from other memory tools like import or load, but it could be more explicit about where the files are created (implied by export_path).
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 such as memory_make_portable or memory_load_from_folder. The description does not mention prerequisites, limitations, or scenarios where this export is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all mandatory and forbidden rules (direct SQL, cached).
| Name | Required | Description | Default |
|---|---|---|---|
| project | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 'direct SQL, cached' which implies performance characteristics and possible bypass of higher-level APIs, but lacks detail on safety or side effects for a read operation.
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 that front-loads the key action. No redundant words, but could include more detail without harming 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 one parameter and available output schema, the description is too sparse. It does not explain what 'mandatory and forbidden' rules mean, the effect of the optional 'project' parameter, or the structure of the output.
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 has one parameter 'project' with no description, and the tool description does not explain its purpose or effect. Schema description coverage is 0%, and the description fails to compensate.
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', the resource 'rules', and specifies 'mandatory and forbidden' with implementation details 'direct SQL, cached'. It distinguishes from sibling tools that add/update/delete rules.
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 does not explicitly compare with alternatives like 'memory_list' or provide when-not-to-use guidance. Usage is implied as the primary read for rule retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import memories from exported .md files.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| import_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose whether the import merges, overwrites, or appends memories, file format specifics, or error behavior.
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 (one short sentence) but achieves no wasted words. However, it is too brief for the complexity of the task; could add 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 has an output schema and many sibling import tools, the description lacks details on import behavior, what the output represents, and how it differs from related 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 coverage is 0%, so description must compensate. It does not explain the 'import_path' parameter's expected format or the optional 'project' parameter's role beyond the bare minimum.
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 verb ('import'), resource ('memories'), and source ('exported .md files'), distinguishing it from sibling tools like 'memory_export', 'memory_import_claude_md', and 'memory_import_rules'.
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 like 'memory_import_claude_md' or 'memory_import_rules'. Lacks context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a project's CLAUDE.md into memory as categorized entries.
path is the CLAUDE.md file or the directory containing it. Headings are
mapped to categories (rules, architecture, decisions, devops, docs...) and
rule sections are split per bullet. When stub_rewrite=True, CLAUDE.md is
replaced with a slim pointer at memory MCP (the original is backed up).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| project | No | ||
| stub_rewrite | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: heading-to-category mapping, bullet splitting, and stub_rewrite with backup. It covers the main side effects but lacks details on error handling or idempotency.
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?
Concise two-paragraph structure with clear first sentence and efficient bullet-like details. No redundant information; every sentence adds value.
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?
Covers main functionality and parameters well, but lacks information on prerequisites (e.g., file existence), error cases, or return value details (though output schema exists). Still fairly complete.
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 0%, but description explains 'path' (file or directory) and 'stub_rewrite' (replaces file with pointer). However, 'project' parameter is not described, requiring inference from default null.
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 states exactly what the tool does: import a CLAUDE.md file into memory with category mapping and optional stub rewrite. It distinguishes from siblings like memory_import and memory_load_from_folder by focusing on CLAUDE.md files.
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 importing CLAUDE.md files but does not explicitly state when to use this tool versus alternatives like memory_import or when not to use it. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy selected rules/memories from another project into this one. Use memory_get_rules(source_project) first to get the ids to import.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| memory_ids | Yes | ||
| source_project | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 basic behavior (copy/import) but does not specify whether existing rules are overwritten, whether the operation is reversible, or any side effects. The description is adequate but lacks depth on behavioral traits.
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?
Two sentences with no fluff: first sentence states the purpose, second provides a specific usage instruction. Every sentence earns its place.
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 moderate complexity (3 parameters, no annotations) and the existence of an output schema, the description covers the core functionality well. It explains the source_project and memory_ids, but does not clarify the optional project parameter or the meaning of 'this one.' Still, it is mostly complete for a copy/import tool.
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%, so the description must compensate. It explains that 'source_project' is the project to copy from and that 'memory_ids' should be obtained via memory_get_rules. However, the optional 'project' parameter (default null) is not explained, leaving ambiguity about its purpose. Overall, it adds significant meaning beyond the 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 action ('Copy selected rules/memories from another project into this one') and specifies the resource (rules/memories). It differentiates from siblings by mentioning a prerequisite step (use memory_get_rules to get ids), which is unique to this tool.
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 explicitly says when to use this tool (to import rules/memories from another project) and provides a step-by-step usage hint: 'Use memory_get_rules(source_project) first to get the ids to import.' This gives clear guidance on how to prepare the input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize a new project namespace (creates DuckDB + registers it).
Pass project_path (the project's source folder) to enable git-synced memory: rules/decisions mirror to /.claude-memory/.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| set_active | No | ||
| description | No | ||
| display_name | Yes | ||
| project_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: creates a database, registers it, and enables git-synced memory. However, it does not mention side effects like overwriting existing projects, permission requirements, or potential failures.
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?
Two sentences that are front-loaded with purpose and essential details. No fluff. Every sentence adds value.
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 an output schema, the description lacks completeness. It does not clarify required parameters (slug, display_name) or optional ones (description, set_active). The initialization process may have constraints or defaults that are undocumented.
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 0%, so description must compensate. It explains project_path's role in enabling git sync, but ignores slug, display_name, description, and set_active. Two out of five parameters are partially explained.
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 function: 'Initialize a new project namespace' and adds technical detail about creating DuckDB and registering it. It distinguishes from siblings like memory_rename_project or memory_list_projects by focusing on initialization.
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. The description implies it's for new projects but does not mention when not to use it or suggest other tools for related tasks (e.g., renaming or listing projects).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bind a project to a source folder for git-synced memory.
Once linked, the project's rules/decisions mirror to a committable /.claude-memory/ snapshot - so memory travels with the code across devices and teammates via git push/pull.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| project | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 that linking causes mirrors to a Git-committable snapshot and that memory syncs across devices. However, it does not mention potential side effects like overwriting existing links, required permissions, or whether the operation is reversible.
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 two sentences: one stating the action and one explaining the benefit. It is concise without fluff. However, it could be slightly more structured by separating the what from the why, but overall it is efficient.
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 (linking a project to a folder for Git sync) and the presence of an output schema, the description covers the core functionality. However, it lacks details about preconditions (e.g., folder must exist, project must exist) and any constraints (e.g., only one link per project). This leaves gaps for an AI agent to know all necessary context.
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 has 2 parameters (path required, project optional) with 0% description coverage. The description mentions 'source folder' and 'project' but does not map them to the parameter names or explain their types, formats, or constraints. This leaves ambiguity for an AI agent.
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 ('Bind a project to a source folder') and the purpose ('for git-synced memory'). It distinguishes from sibling tools by focusing on linking to a folder for Git sync, which is unique among the siblings.
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 indicates when to use this tool: to enable memory to travel with code via git push/pull. It implies the context of multi-device or team collaboration. However, it does not explicitly state when not to use it or compare it to sibling tools like memory_attach_project or memory_make_portable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List memories with filtering, sorting, and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| limit | No | ||
| offset | No | ||
| status | No | active | |
| project | No | ||
| sort_by | No | updated_at | |
| category | No | ||
| sort_order | No | desc |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should carry the burden of behavioral disclosure. It only states the basic functionality and does not mention side effects (expected none), rate limits, output details, or prerequisites like authentication or project scoping.
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, which is efficient but may be too brief given the tool's complexity. It front-loads the main action but lacks structure and additional context.
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 8 parameters, many sibling tools, and no annotations, the description is insufficient. It does not cover default behaviors, pagination limits, or how results are sorted by default. The existence of an output schema is not mentioned, though it partially compensates.
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 has 8 parameters with 0% description coverage. The description only vaguely groups parameters into filtering, sorting, and pagination but does not explain individual parameters or their semantics, leaving the agent to infer from names and defaults.
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 lists memories and mentions filtering, sorting, and pagination, which helps differentiate it from other tools like memory_search or memory_recall. However, it does not explicitly distinguish it from all sibling tools.
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 such as memory_search, memory_recall, or memory_list_projects. The description only states what it does, not when 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.
List all registered projects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly state that the operation is read-only or side-effect-free. While it implies a simple list, more transparency would be beneficial.
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 with no extraneous words. It front-loads the purpose effectively.
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 output schema handles return values, so the description is adequate for a simple list. However, it could mention scope (e.g., 'all projects in the current session') or edge cases.
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?
There are no parameters, so the baseline is 4. The description does not need to add parameter semantics.
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 'List all registered projects' uses a specific verb ('list') and resource ('projects'), clearly distinguishing it from siblings like 'memory_list' which lists memories.
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 such as 'memory_project_info' or 'memory_attach_project'. The description provides no context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List reusable rule/memory templates that can be applied to new projects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 describes a read-only listing operation without side effects, but it does not explicitly confirm that the tool is non-destructive or mention any other behavioral traits.
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, front-loaded sentence that conveys the purpose without extraneous words. Every part is essential.
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 parameters and a likely simple return value (list of templates). The description is sufficient for a basic understanding, though it could mention the output format. Since an output schema exists, the description is adequately complete.
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 has zero parameters, so no parameter explanation is needed. The description does not add parameter information, but with 100% schema coverage and no parameters, the baseline of 4 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 'List' and the resource 'reusable rule/memory templates', and it distinguishes from siblings like memory_create_template and memory_apply_template, which create or apply templates.
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 the tool is used to see available templates before applying them, but it does not explicitly state when to use it versus alternatives, such as before calling memory_apply_template. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a project from a local folder.
The project name is taken from the folder's package.json ("name") or the folder name. If the folder already contains a portable .memory-mcp.duckdb it is attached as-is; otherwise the project is created and a CLAUDE.md, if present, is imported into memory. The project is auto-activated.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and covers key behaviors: auto-activation, database attachment or creation, and CLAUDE.md import. It does not detail nondestructive assurance, permissions, or error handling, but the provided details are substantial.
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 three sentences, each serving a distinct purpose: stating the overall action, detailing name derivation and database handling, and noting auto-activation. No extraneous 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?
Given the single parameter and presence of an output schema, the description covers all essential aspects: load behavior, name logic, database state handling, CLAUDE.md import, and post-load activation. It is sufficiently complete for an agent to use 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?
Schema coverage is 0%, but the description fully explains the single 'path' parameter: it's a local folder, and the project name is derived from package.json or folder name. This adds significant meaning beyond the schema's bare type definition.
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 the specific verb 'Load' and resource 'project from a local folder', clearly stating the tool's function. It also implies differentiation from sibling tools like memory_init_project by noting that if a database already exists, it is attached as-is, and otherwise created with CLAUDE.md import.
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 explains what the tool does but does not explicitly state when to use it versus alternatives like memory_init_project or memory_link_folder. It provides no 'when-not-to-use' guidance or comparison to siblings, leaving usage context implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move the project's DB into the project directory for git sharing.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| project_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The description only says 'move' without explaining whether it copies or deletes the original, what 'project DB' refers to, or any side effects. This is insufficient for a mutating tool.
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 short sentence, but it lacks necessary detail. While front-loaded, it is too terse to be useful. Every sentence should earn its place, but this one omits critical 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?
Given no annotations, 0% schema coverage, and no explanation of return values (though output schema exists), the description is completely inadequate. It does not describe behavior, prerequisites, or consequences, leaving the agent unable 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?
Schema description coverage is 0%, but the description does not explain the parameters 'project' and 'project_path'. The optional 'project' parameter is not described at all, and 'project_path' is not clarified. The description adds no value 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 action: moving the project's DB into the project directory for git sharing. It specifies the verb 'move', the resource 'project DB', and the purpose, distinguishing it from other memory tools like memory_sync or memory_export.
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 like memory_sync or memory_export. The description does not provide context for appropriate usage or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current embedding model + available presets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the output content (model and presets) but does not mention that it is a read-only operation, any authentication needs, or potential side effects. The description is too 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?
The description is extremely short (one sentence), which is concise but at the cost of completeness. It is front-loaded but could benefit from a clearer verb and additional context.
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 simplicity of the tool (no parameters) and existence of an output schema, the description is minimally adequate. It hints at the return content but does not clarify that it is informational only or how it differs from similar 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?
The tool has zero parameters, so the baseline is 4. The description adds minimal context but does not contradict the schema. No parameter documentation is needed, and the description provides a hint of what the output covers.
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 'Current embedding model + available presets.' is a noun phrase that vaguely indicates what the tool returns, but lacks a specific verb like 'get' or 'retrieve'. It distinguishes from siblings like 'memory_version' only by name, not by explicit differentiation.
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 'memory_set_model' or 'memory_version'. The description does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed info for a project.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states 'Get detailed info,' implying a read operation, but does not mention side effects, authentication, rate limits, or how the optional null parameter behaves (e.g., defaults to current project). The bare description fails to provide transparency beyond the basic action.
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 clear sentence, which is concise but at the expense of necessary detail. It is front-loaded with the core action, but it omits critical information about the parameter and usage context. Conciseness should not sacrifice completeness; here it does.
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 is simple with one parameter, but the description is incomplete. While an output schema exists, the parameter and default behavior are unexplained. For a tool with 0% schema coverage, the description should provide more context about the project parameter and when to use it. The current description does not enable safe and effective invocation.
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%, and the description does not explain the 'project' parameter at all. It lacks format, valid values, default behavior, or semantics. The output schema exists but the description adds no meaning beyond the schema structure. This is insufficient for the agent to use the parameter correctly.
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') and resource ('detailed info for a project'), making the purpose clear. It distinguishes itself from siblings like memory_list_projects (which lists projects) and memory_store (which stores data). However, it does not clarify what 'detailed info' includes or that the optional parameter defaults to the current project, which slightly reduces specificity.
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 no guidance on when to use this tool versus alternatives. Given the large number of sibling tools (e.g., memory_list_projects, memory_store, memory_recall), the lack of usage context or exclusions leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full audit trail for a memory.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| memory_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 only states 'Get the full audit trail,' which implies a read-only operation but gives no details on performance, limits, or what 'full' entails. No behavioral traits beyond the basic action are disclosed.
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, making it concise, but it omits crucial information about parameters and usage. It is front-loaded with the purpose but under-specified for effective tool invocation.
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 an output schema exists, return values are not required, but the description still lacks detail about input parameters and behavioral context. The minimal description is insufficient for a tool with two parameters and no schema descriptions.
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 0%, meaning no parameter descriptions exist in the schema. The tool description does not explain what 'memory_id' or 'project' represent or how to use them, adding no semantic value beyond the schema's structural definition.
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 'Get the full audit trail for a memory' with a specific verb and resource, distinguishing it from siblings focused on storing, updating, or deleting memories. However, 'full audit trail' is somewhat vague and does not explicitly differentiate it from version tracking tools like memory_version.
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. It is implied that it is for retrieving audit trails, but there are no exclusion criteria, prerequisites, or mentions of related tools despite many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recall a specific memory by ID or exact title.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| project | No | ||
| memory_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects, authentication, or return behavior. It only states 'Recall', implying read-only, but fails to mention case sensitivity, uniqueness, or how missing parameters behave.
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, which is concise but lacks structure. It states the core function but provides no additional context or organization beyond that.
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 many sibling tools and three optional parameters with no descriptions, the description is too brief. It does not address expected output (despite an output schema), parameter relationships, or the tool's specific role in the broader set.
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% so the description must explain parameters. It mentions memory_id and title but omits the project parameter entirely. No explanation that parameters may be combined or are mutually exclusive, leaving ambiguity.
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 specific memory by ID or exact title, differentiating it from siblings like memory_search (likely fuzzy) and memory_list. The verb 'recall' and resource 'memory' are precise.
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 such as memory_search or memory_list. The description implies exact matching but does not explicitly advise against using for fuzzy or list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-embed all active memories with the current model.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action but omits important details such as whether the re-embedding is destructive, requires certain permissions, or has performance implications (e.g., affecting all active memories).
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 wasted words. However, it may be too brief for the complexity of the tool, lacking necessary details that could be added without harming 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 has one undocumented parameter and no usage guidelines or behavioral details, the description is incomplete. While an output schema exists, the description does not provide enough context for an agent to select and invoke this tool correctly among many siblings.
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 does not mention the only parameter 'project' (optional, string or null). Schema description coverage is 0%, so the description adds no value beyond what the schema provides, leaving the agent without guidance on how to use the parameter.
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 (re-embed) and the resource (all active memories) with a specific context (with the current model). It effectively differentiates from sibling tools like memory_store or memory_recall by using a unique verb 're-embed'.
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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or scenarios where this tool is preferred over siblings like memory_set_model or memory_store.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a project (its display name) and optionally update its description.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| description | No | ||
| display_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It only states that the tool renames a project and optionally updates description, which implies mutation. No details on side effects, reversibility, permissions, or what happens to related data.
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 wasted words. It is structured efficiently, but could benefit from a bit more detail without becoming 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 3 parameters and no annotations, the description is incomplete. It does not explain the 'project' parameter, nor does it reference the output schema or any return values. For a task that involves identifying a project, this is a significant gap.
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%. The description mentions 'display_name' and 'description' but omits the 'project' parameter entirely. The 'project' parameter is optional and has default null, but no explanation is given for its purpose or how to identify the project. This leaves the agent unaware of a critical parameter.
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 'Rename' and the resource 'project (its display name)'. It also mentions the optional description update. However, it does not explicitly distinguish this tool from siblings like 'memory_update' which might also modify project attributes.
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 no guidance on when to use this tool over alternatives (e.g., memory_update, memory_project_info). It lacks any context about prerequisites, exclusions, or recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search with composite relevance scoring.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| limit | No | ||
| query | Yes | ||
| status | No | active | |
| project | No | ||
| category | No | ||
| token_budget | No | ||
| min_similarity | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'semantic search' and 'composite relevance scoring' without mentioning side effects, permissions, rate limits, or whether it is read-only. The agent cannot infer behavioral traits from this minimal text.
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 extremely concise (5 words) but lacks necessary detail. While it avoids unnecessary words, it is under-specified for a tool with 8 parameters and no annotations. Score reflects minimal adequacy.
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 complexity (8 parameters, output schema exists), the description is incomplete. It doesn't explain what is being searched (memory entries), how composite scoring works, or how to use parameters effectively. The output schema may compensate partly, but the description itself lacks essential context.
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%, so description must compensate. It does not explain any of the 8 parameters (e.g., tags, limit, status, project, category, token_budget, min_similarity) beyond their names and defaults. No added value for parameter understanding.
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 'Semantic search with composite relevance scoring' clearly indicates a search tool using semantic techniques, distinguishing it from siblings like memory_recall or memory_list that likely use different retrieval methods.
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 no guidance on when to use this tool versus alternatives such as memory_recall, memory_list, or other search-related siblings. No explicit or implicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End a session and store its summary.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| summary | Yes | ||
| session_id | Yes | ||
| memories_created | No | ||
| memories_accessed | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it ends a session and stores a summary. It does not disclose side effects, permanence, required permissions, or what happens to the session data.
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, front-loaded sentence with no wasted words. However, it may be too brief given the tool's complexity.
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 description lacks essential context for a tool with 5 parameters, no annotations, and an output schema (not explained). It does not specify what 'ending a session' entails, prerequisites, or the role of 'summary'. Incomplete for 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 description coverage is 0% and the description adds no meaning to any of the 5 parameters (session_id, summary, project, memories_created, memories_accessed). The agent gains no insight into parameter roles or formats beyond the 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 'End' and the resource 'a session', with the additional action 'store its summary'. It distinctly contrasts with sibling tools like 'memory_session_start'.
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 others, no prerequisites or when-not-to-use context, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a session. Loads rules, last summary, sprint goals, recent decisions.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It states that a session is started and that specific data is loaded, which is adequate but does not mention potential side effects, prerequisites, or behavior if a session is already active.
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, concise and front-loaded, but could benefit from a slightly more structured format (e.g., listing loaded items separately). No wasted words.
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 an output schema and only one parameter, the description lacks critical context such as return value behavior, what happens when 'project' is provided vs null, or how session state is managed. It feels 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 has one parameter ('project') with no description coverage (0%). The description does not mention or explain this parameter, leaving its purpose and effect completely unclear.
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 ('Start') and resource ('session') and lists key loading actions (rules, last summary, sprint goals, recent decisions), which clearly distinguishes it from sibling tools like memory_session_end or memory_store.
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 a session already exists, or before calling other memory tools). The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch embedding model between 'english' and 'multilingual' presets.
| Name | Required | Description | Default |
|---|---|---|---|
| preset | Yes | ||
| confirm | No | ||
| project | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 switching presets but does not disclose any behavioral traits such as whether the operation is destructive, requires confirmation, or affects existing data. The presence of a 'confirm' parameter is not explained.
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, efficient sentence that contains no redundant information. It is optimally 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?
Given the tool's complexity (3 parameters, output schema, state-changing action), the description is too minimal. It omits necessary context about impact, usage scenarios, and parameter details, making it incomplete for safe and 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?
With 0% schema description coverage, the description should explain all parameters. It only explains the 'preset' parameter by listing its values. The 'confirm' and 'project' parameters are completely undocumented in both the description and 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 'Switch' and resource 'embedding model', and names the two presets ('english' and 'multilingual'). It leaves no ambiguity about the tool's primary action. However, it does not differentiate from sibling tools like memory_model_info or memory_reembed.
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?
There is no guidance on when to use this tool versus alternatives (e.g., when to switch models, prerequisites, or consequences). The description only states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a new memory with auto-embedding, summary, entity extraction, and TTL.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| title | Yes | ||
| source | No | assistant | |
| content | Yes | ||
| project | No | ||
| category | Yes | ||
| metadata | No | ||
| priority | No | ||
| related_ids | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals that the tool performs auto-embedding, summary extraction, entity extraction, and applies a TTL. However, it omits details like required permissions, rate limits, side effects on existing data, or whether the process is synchronous.
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?
A single 11-word sentence that efficiently conveys the tool's core purpose and automatic features. No redundant information; every phrase earns its place.
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 an output schema, the description does not explain the return value. With 9 parameters, many optional, and no annotation or schema descriptions, the single sentence leaves significant gaps in understanding the tool's behavior and how to use it effectively among 30+ siblings.
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%, and the description adds no parameter-level details. It mentions 'content' but does not clarify the meaning or constraints of 'tags', 'metadata', 'priority', or 'related_ids'. The schema lists defaults but the description does not leverage them.
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 ('Store') and resource ('new memory'), and lists key features (auto-embedding, summary, entity extraction, TTL) that distinguish it from update, delete, or query tools. However, it does not explicitly contrast with siblings like memory_update or memory_use.
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. The description does not mention prerequisites, typical use cases, or when not to use it. The default source 'assistant' is not explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sync a portable DB after git pull. Auto-activates on success.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | ||
| project_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions auto-activates on success, but lacks details on safety, auth requirements, or side effects. No annotations to supplement.
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 sentence, no waste, but oversimplified; could add parameter context 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?
Output schema exists but unmentioned; with many siblings, more context on what 'sync' entails and return value is needed.
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 0%, and description does not explain 'slug' or 'project_path' beyond names, leaving meaning ambiguous.
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?
Describes a specific action: syncing a portable DB after git pull, which distinguishes it from siblings like memory_make_portable or memory_check_update.
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?
Only states after git pull, but provides no guidance on when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing memory. Re-embeds if title/content changed.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| title | No | ||
| status | No | ||
| content | No | ||
| project | No | ||
| metadata | No | ||
| priority | No | ||
| memory_id | Yes | ||
| related_ids | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral disclosure is the re-embedding trigger on title/content change. With no annotations, the description should cover idempotency, required permissions, error scenarios, and return behavior, but it does not.
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?
Two brief sentences, front-loaded with the core action. However, conciseness sacrifices necessary detail for a tool with many parameters.
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 9 parameters, no schema descriptions, no annotations, and an output schema, the description is severely incomplete. It fails to explain parameter usage, return values, or typical use cases.
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%, so the description must compensate, but it provides no meaning for any of the 9 parameters. The parameter names are self-explanatory to some degree, but the description adds no extra value.
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' and resource 'memory', and hints at a side effect (re-embedding). It distinguishes from sibling creation/deletion tools, though it does not explicitly mention that it requires an existing memory.
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 like memory_store or memory_delete. Among many sibling tools, no context is provided for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing mandatory or forbidden rule by its id.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| content | No | ||
| project | No | ||
| rule_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Update' without disclosing side effects, idempotency, error handling for missing rule, or any behavioral traits. The presence of an output schema is not leveraged in the description.
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 efficient sentence with no wasted words. However, it could include more relevant details without becoming 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?
The description is minimal and does not cover key aspects like which fields are updatable, constraints, or behavior when rule_id is invalid. Given the sibling tools and complexity, more context is needed.
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%, and the description adds no meaning beyond the parameter names. It only explains that rule_id identifies the rule, but does not describe title, content, or project fields.
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 (Update), the resource (existing mandatory or forbidden rule), and the identifier (by its id). It effectively distinguishes from sibling tools like memory_add_rule and memory_delete_rule.
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. There is no mention of prerequisites, such as the rule must exist or the type constraints (mandatory vs forbidden).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the active project. Subsequent tools use it by default.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions that subsequent tools use the active project by default, but it does not disclose potential side effects, reversibility, or permission requirements.
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 extremely concise—two short sentences with no wasted words. Each sentence serves a clear purpose: the first defines the action, the second explains the consequence.
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 presence of many sibling tools and an output schema, the description leaves significant gaps. It does not explain what 'active project' means, how it interacts with other tools, or what the output contains.
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 does not mention the 'project' parameter at all. With 0% schema description coverage, the description fails to add any meaning beyond the bare schema, leaving the agent uninformed about what values to provide.
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 'Set the active project,' which is a specific verb and resource. It distinguishes itself from sibling tools like memory_init_project and memory_rename_project by focusing on setting the active project for default use.
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 no guidance on when to use this tool versus alternatives such as memory_attach_project or memory_init_project. It does not specify prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current version of the Memory MCP server and configuration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool performs a read operation ('Get'), which is non-destructive. However, with no annotations provided, the description does not disclose potential latency, authentication requirements, or whether the version is cached. For a simple version check, this is adequate but minimally transparent.
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, clear sentence with no unnecessary words. It is front-loaded with the key information ('Get the current version') and is appropriately sized for a simple tool. Every word contributes meaning.
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 low complexity (no parameters, trivial function) and the existence of an output schema (which covers return values), the description is complete. It specifies what information is returned (version of server and configuration) and no additional context is needed.
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 tool has no parameters, so the description does not need to add parameter details. The input schema is fully defined and empty, achieving 100% coverage. The description adds no extra parameter semantics, but none are needed, justifying the baseline score of 4.
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 the current version of the Memory MCP server and configuration. The verb 'Get' is specific, and the resource 'version of the Memory MCP server and configuration' is unambiguous. This distinguishes it from all sibling tools, which focus on data operations, project management, or configuration changes.
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 implicitly indicates that this tool is for checking version information. No sibling tool provides version data, so there are no alternatives to exclude. However, explicit guidance on when to use it (e.g., before performing updates or troubleshooting) is absent but not critical given the tool's simplicity.
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.
v0.6.0memory_add_rulememory_add_rule_bulkmemory_add_template_rulememory_apply_templatememory_attach_projectmemory_check_updatememory_create_templatememory_deletememory_delete_rulememory_exportmemory_get_rulesmemory_importmemory_import_claude_mdmemory_import_rulesmemory_init_projectmemory_link_foldermemory_listmemory_list_projectsmemory_list_templatesmemory_load_from_foldermemory_make_portablememory_model_infomemory_project_infomemory_provenancememory_recallmemory_reembedmemory_rename_projectmemory_searchmemory_session_endmemory_session_startmemory_set_modelmemory_storememory_syncmemory_updatememory_update_rulememory_usememory_versionScored across 37 tools
Each tool has a distinct and clear purpose, with names like memory_store, memory_search, memory_add_rule, and memory_session_start all targeting different operations. While there are many tools, descriptions ensure they are easily distinguished, and there is no ambiguity.
All tools follow a consistent 'memory_<verb>_<noun>' pattern (e.g., memory_list_projects, memory_init_project, memory_add_rule, memory_session_end). No mixing of conventions, making it predictable and easy to navigate.
37 tools is higher than typical but justified by the broad scope: project management, memory CRUD, rules, templates, sessions, import/export, and model configuration. A slight reduction could improve simplicity, but it remains well-scoped for the domain.
The tool surface covers the full lifecycle of memory management: create/read/update/delete for memories, projects, and rules, plus sessions, templates, import/export, and version checking. No obvious gaps for the intended purpose of a persistent memory server.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Persistent, governed institutional memory for Claude Code — specs, decisions, learnings.
Persistent memory for Claude Code, Cursor and Codex. Facts retire when they change.
