How do I use smg-claude-memory-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@smg-claude-memory-mcp store that we chose PostgreSQL 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.

smg-claude-memory-mcp

by serkansmg

Overview Schema Related Servers Score Discussions

Python

SMG Claude Memory MCP

Persistent, searchable project memory for Claude Code. Each project has its own brain — decisions, rules, architecture notes, sprint goals — all stored locally in a vector database and automatically loaded every time you start a new session.

What problem does this solve? Claude forgets everything between sessions. You end up re-explaining the same things over and over, rules get missed, past decisions get lost when your context window fills up, and switching machines means starting from scratch. This MCP gives Claude a real memory — one that survives restarts, context overflows, and team handoffs.

In Plain English

What does this project actually do?

It gives Claude permanent memory per project. Think of it as a separate brain for each of your projects.

When you're working on something, you make decisions ("we chose PostgreSQL"), set rules ("always run tests before commits"), and plan sprints. Normally, all of that is forgotten when a new session starts, or gets scattered across .md files that Claude has to re-read every time.

With this MCP:

When you make a decision → Claude stores it automatically
When you ask about something → Claude searches memory first, then answers
When you start a new session → All the important stuff loads automatically
When you set a rule ("always do X") → Claude won't forget it again

Three things users should understand

Semantic search — Ask "what database did we pick?" and it finds the PostgreSQL decision, even if you never typed "PostgreSQL" in your query. It searches by meaning, not keywords.
Project isolation — Every project has its own separate memory database. Memories from project-A never leak into project-B.
Team collaboration — You can move a project's memory into the project folder, commit it to git, and your teammates get the same memory after git pull.

The technical one-liner

"An MCP server for Claude Code that stores per-project memory in local DuckDB with vector embeddings. It remembers decisions, rules, and sprint notes, retrieves them via semantic search, and auto-loads full context at session start — so Claude never forgets anything."

What you'll feel day-to-day

You won't need to re-explain your project's decisions every session
Rules you've set stick — Claude can't skip them (enforced by hooks)
Context window overflows don't lose important info (it's in the DB)
Switching machines? git pull + one command, and Claude picks up exactly where you left off
Onboarding a teammate's Claude? Same thing — they get your whole project memory instantly

Related MCP server: Claude Memory MCP

FAQ — Common Questions, Clear Answers

Q: When I run `make_portable`, does it move ALL projects' memory to git, or just the one I'm working on?

Just the one project. Other projects are never touched.

Each project has its own separate .duckdb file:

~/.memory-mcp/
├── registry.duckdb              ← List of projects (name + path)
└── projects/
    ├── my-app.duckdb            ← ONLY my-app's memory
    ├── smg-analytics.duckdb     ← ONLY smg-analytics's memory
    └── other-project.duckdb     ← ONLY other-project's memory

When you run:

/smg-memory portable /Users/you/projects/smg-analytics

What happens:

Copies ~/.memory-mcp/projects/smg-analytics.duckdb → /Users/you/projects/smg-analytics/.memory-mcp.duckdb
Moves the original to ~/.memory-mcp/backups/ (kept as safety net)
Updates the registry so this project now uses the new location

The other projects stay right where they are. Their memory is never exposed in this repo's git history.

When you git add .memory-mcp.duckdb and push, you're only sharing that specific project's memory. Teammates who pull it only get that project's memory — not a window into all your other work.

Q: Will my memories from one project contaminate another project?

No. Strict isolation. Each project's .duckdb is its own DuckDB database. Searches, rules, sessions — everything is scoped to one project at a time.

Q: What happens if my context window fills up mid-session?

You won't lose anything. Memories live in the DB, not in the context window. When you start a new session, memory_session_start auto-loads:

All mandatory rules (guaranteed, cached, never approximated)
All forbidden rules
Last session's summary
Active sprint goals
Recent decisions (last 7 days)

Anything older is one semantic search away.

Q: Do I need to manually store every memory?

No. When a session is active, Claude auto-stores:

Decisions you make ("we decided to use X", "going with Y")
Rules you set ("always do X", "never do Y")
Feedback ("don't do that again", "keep doing that")
Architecture choices

You can also explicitly use /smg-memory store <category> <title> <content> when you want control.

Q: Does anything leave my machine?

No. Everything is local:

DuckDB database on your disk
Embeddings generated locally by sentence-transformers (CPU, no GPU needed)
No API keys, no cloud services, no telemetry

The only network call is the one-time ~80MB download of the embedding model from Hugging Face.

Q: Can my teammate who doesn't have this MCP still read the memories?

Yes. Run /smg-memory export <project-path> and it creates a .memory/ directory with human-readable Markdown files. Anyone can read, edit, or review them directly. You can sync changes back with /smg-memory import.

How It Works — The Flow

Three interaction patterns. In all of them, you talk to Claude normally — the MCP works behind the scenes.

The Cast

Before the flows, a quick clarification — these are different things:

Component	What it is	What it does
Claude (LLM)	Large language model	Understands you, makes decisions, writes answers
Memory MCP	This server	Orchestrates storage and retrieval
Embedding model (all-MiniLM)	Small neural net (~80MB)	Turns text into 384 numbers (a vector). Does NOT understand anything
DuckDB	Local database	Stores memories + vectors, does similarity math

The embedding model is NOT an LLM. It doesn't "understand" — it just converts text to numbers so that similar meanings produce similar vectors. That's why it's small and fast.

Flow 1: You ask a question

"What was our caching strategy?"

sequenceDiagram
    actor You
    participant Claude
    participant MCP as Memory MCP
    participant Embed as Embedding Model
    participant DB as DuckDB

    You->>Claude: "What was our caching strategy?"
    Claude->>MCP: memory_search("caching strategy")
    MCP->>Embed: encode(query)
    Embed-->>MCP: [384-dim vector]
    MCP->>DB: vector similarity search (cosine)
    DB-->>MCP: top-N matching memories
    MCP-->>Claude: [Redis for cache, decisions, ...]
    Claude-->>You: "We chose Redis for session caching because..."

What happened: Claude triggered a vector search. The query became a vector. DuckDB found memories with similar vectors (same meaning). Claude composed the answer from those memories.

Flow 2: You make a decision

"Let's use Redis for caching."

sequenceDiagram
    actor You
    participant Claude
    participant Hook as UserPrompt Hook
    participant MCP as Memory MCP
    participant Embed as Embedding Model
    participant DB as DuckDB

    You->>Claude: "Let's use Redis for caching"
    Hook->>Claude: detects decision pattern
    Claude->>MCP: memory_store(decision, "Use Redis", content)
    MCP->>Embed: encode(title + content)
    Embed-->>MCP: [384-dim vector]
    MCP->>MCP: generate summary, extract entities, compute TTL
    MCP->>DB: INSERT memory + vector + metadata
    DB-->>MCP: stored
    MCP-->>Claude: {id, summary, entities, expires_at}
    Claude-->>You: "Noted — Redis caching decision saved."

What happened: The UserPromptSubmit hook noticed a decision pattern. Claude auto-stored it. MCP generated a summary, extracted entities (like "Redis"), computed a TTL (365 days for decisions), and wrote everything to DuckDB along with the vector.

Flow 3: You start a new conversation

"Hi, let's continue."

sequenceDiagram
    actor You
    participant Claude
    participant Hook as SessionStart Hook
    participant MCP as Memory MCP
    participant DB as DuckDB

    You->>Claude: "Hi, let's continue"
    Hook->>Claude: enforces memory_session_start
    Claude->>MCP: memory_session_start(project)
    MCP->>DB: auto-close orphaned sessions
    MCP->>DB: SELECT mandatory_rules, forbidden_rules
    MCP->>DB: SELECT last session summary
    MCP->>DB: SELECT active sprint goals
    MCP->>DB: SELECT recent decisions (last 7 days)
    DB-->>MCP: full context bundle
    MCP-->>Claude: {rules, last_summary, sprint, decisions}
    Claude-->>You: "Hi! Last session we chose Redis. Auth module is next."

What happened: The hook forced Claude to call memory_session_start. MCP pulled everything important in one batch — rules, last session summary, active sprint, recent decisions — and Claude started the conversation already knowing the project's state.

High-Level View

graph LR
    User[You] <--> Claude[Claude LLM]
    Claude <--> MCP[Memory MCP Server]
    MCP --> Embed[Embedding Model<br/>~80MB local]
    MCP --> DB[(DuckDB<br/>per-project)]
    DB --> HNSW[HNSW Vector Index]
    Hooks[Hooks] -.->|enforce session_start,<br/>detect decisions| Claude

    style User fill:#e1f5e1
    style Claude fill:#fff4e1
    style MCP fill:#e1e8ff
    style Embed fill:#ffe1f0
    style DB fill:#f0e1ff

Everything runs locally on your machine. No cloud, no API keys, no telemetry.

Multilingual Support

The Default: English-Only

Out of the box, this MCP uses all-MiniLM-L6-v2 — a small, fast, English-only embedding model:

Size: ~80MB on disk, ~90MB RAM
Speed: ~14k sentences/sec on CPU
Languages: English only
Quality: Excellent for English

What this means in practice:

✅ "which database did we choose?" → finds the PostgreSQL decision (English content)
❌ "hangi veritabanını seçtik?"    → may return 0 results (Turkish query, English content)

If your memories are in English, the default works great. If you or your team write in other languages, you need the multilingual model.

Switching to Multilingual

If you want to ask questions or store memories in non-English languages, switch to the multilingual model:

/smg-memory model multilingual

This will:

Show you the impact (disk, RAM, memories to re-embed)
Ask for confirmation
Download the multilingual model (~470MB, one-time)
Re-embed all your existing memories with the new model
Persist the choice (survives restarts)

After switching, you can search and store in any of these 50+ languages:

Region	Languages
European	English, German, French, Spanish, Italian, Portuguese, Dutch, Polish, Swedish, Romanian, Czech, Danish, Finnish, Greek, Hungarian, Norwegian, Bulgarian, Catalan, Galician, Croatian, Slovak, Slovenian, Lithuanian, Latvian, Estonian, Ukrainian, Serbian, Macedonian, Albanian
Middle Eastern	Arabic, Hebrew, Persian (Farsi), Kurdish, Armenian, Urdu
Asian	Chinese, Japanese, Korean, Vietnamese, Thai, Indonesian, Malay, Burmese, Mongolian
South Asian	Hindi, Gujarati, Marathi
Turkic	Turkish, Azerbaijani (partial)

Cross-Lingual Superpower

The multilingual model is cross-lingual — you can store memories in one language and search in another:

Store (English):  "We chose PostgreSQL for JSON support and reliability"
Search (Turkish): "hangi veritabanını kullanıyoruz?" → finds the PostgreSQL decision ✅
Search (Japanese): "どのデータベースを使っていますか?" → finds it too ✅

Comparison

	English-only (default)	Multilingual
Model	`all-MiniLM-L6-v2`	`paraphrase-multilingual-MiniLM-L12-v2`
Disk	~80MB	~470MB
RAM	~90MB	~500MB
Parameters	22M	118M
Speed	~14k sent/sec	~5k sent/sec
Languages	English only	50+ languages
Cross-lingual	No	Yes
Vector dimensions	384	384 (same)

Switching Back

Want to go back to English-only?

/smg-memory model english

Same two-step confirmation, re-embeds all memories back.

Check Current Model

/smg-memory model

Shows which model is active and presents both options with their trade-offs.

Why Not Just Use `MEMORY.md`?

Claude Code's built-in memory has real limitations:

Problem	`MEMORY.md`	This MCP
Semantic search	❌ Keyword only	✅ Vector-based, finds by meaning
Context window cost	❌ Eats your context	✅ Stored in DB, fetched on demand
Project isolation	❌ Mixes across projects	✅ One DB per project
Rules enforcement	❌ May get skipped	✅ Hook-enforced, always loaded
Team sharing	❌ Local only	✅ Git-portable
Multi-language	❌ Varies	✅ 50+ languages (optional model)
Audit trail	❌ None	✅ Full provenance tracking

Features

Feature	Description
Semantic Search	HNSW-accelerated cosine similarity — find memories by meaning
Per-Project Isolation	Each project gets its own DuckDB database
11 Memory Categories	decisions, sessions, sprints, architecture, rules, devops, and more
Rules Enforcement	Mandatory/forbidden rules, cached, never approximated
Session Management	Auto-loads full context (rules, sprint, recent decisions) at session start
Auto-Summary	15-20 word summary generated for every memory
Entity Extraction	Automatic detection of tech names, @mentions, #tags, acronyms
TTL/Expiration	Category-based auto-expiration (rules never expire)
Provenance Tracking	Full audit trail for every memory operation
Token Budgeting	Dual-phase search responses — lightweight index + full details
Portable DB	Move DB into project directory, share via git
Export/Import	Human-readable `.md` export for non-MCP users
Active Project	Set once, use everywhere — no need to repeat project slug
CWD Detection	Auto-detects project from current working directory
Switchable Models	English-only (fast, 80MB) or multilingual (50+ langs, 470MB)
Zero Cloud Deps	No API keys, no cloud services, fully local

Quick Install

git clone https://github.com/serkansmg/smg-claude-memory-mcp.git
cd smg-claude-memory-mcp
chmod +x install.sh
./install.sh

This will:

Install uv if not present
Install all Python dependencies in an isolated venv (no system pollution)
Download the embedding model (~80MB, one-time)
Configure Claude Code MCP automatically

Then restart Claude Code.

Manual Install

uv sync
uv run memory-mcp-setup

Or add to Claude Code manually (.mcp.json or ~/.claude.json):

{
  "mcpServers": {
    "memory": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/smg-claude-memory-mcp", "memory-mcp"]
    }
  }
}

Quick Start

# 1. Create a project (one-time)
/smg-memory init my-app "My Application"

# 2. Start a session (beginning of each conversation)
/smg-memory start

# 3. Store memories (or let Claude auto-detect from conversation)
/smg-memory store decision "Use PostgreSQL" "Chose PostgreSQL for JSON support"
/smg-memory store mandatory_rules "Always Test" "Run pytest before every commit"

# 4. Search
/smg-memory search "database choice"

# 5. End session
/smg-memory end "Implemented auth module, chose JWT tokens"

Usage

Project Management

# Create new project (auto-activates)
/smg-memory init my-app "My Application"

# Attach existing project directory
/smg-memory attach /path/to/my-app

# Set active project (no need to pass project= to every command)
/smg-memory use my-app

# List all projects
/smg-memory projects

Session Lifecycle

# Start session — loads rules, last session summary, sprint goals, recent decisions
/smg-memory start

# End session with summary
/smg-memory end "Completed user auth, decided on JWT, next: API rate limiting"

Memory Operations

# Store (project is optional — uses active project)
/smg-memory store decision "Redis for Cache" "Using Redis for session and API caching"
/smg-memory store architecture "Event-Driven" "Adopted event-driven architecture with RabbitMQ"
/smg-memory store mandatory_rules "PR Reviews" "All PRs require at least one review"

# Semantic search
/smg-memory search "caching strategy"
/smg-memory search "deployment pipeline"

# List by category
/smg-memory list decisions
/smg-memory list mandatory_rules

# Get rules
/smg-memory rules

# View change history
/smg-memory history <memory-id>

Team Collaboration

# Developer 1: Move DB to project directory
/smg-memory portable /path/to/project
# Add to .gitignore: *.duckdb.wal
git add .memory-mcp.duckdb
git commit -m "add project memory"
git push

# Developer 2: After git pull
/smg-memory sync /path/to/project
# Ready! All memories from Developer 1 are available.

Option B: Export for non-MCP users

# Export to human-readable .md files
/smg-memory export /path/to/project

# Creates:
# .memory/
#   MEMORY_INDEX.md          <- Master index
#   README.md                <- Format docs
#   decision/
#     use-postgresql.md      <- Individual memories
#   mandatory_rules/
#     always-test.md
#   architecture/
#     event-driven.md

# Non-MCP users can read and edit these files directly.

# Import changes back
/smg-memory import /path/to/project

Automatic Memory (No Commands Needed)

When a session is active, Claude automatically:

Stores decisions when you make architectural or technical choices
Stores rules when you say "always do X" or "never do Y"
Searches memory when you ask about past decisions
Checks rules before significant operations

Memory Categories

Category	Description	TTL
`decision`	Important decisions and rationale	365 days
`session`	Session summaries	30 days
`sprint`	Sprint goals, progress, retrospectives	90 days
`project_plan`	Project plans and milestones	365 days
`architecture`	Architecture decisions and patterns	365 days
`devops`	DevOps configs, deployment notes	180 days
`mandatory_rules`	Rules that MUST be followed	Never expires
`forbidden_rules`	Operations that are FORBIDDEN	Never expires
`developer_docs`	Developer documentation	180 days
`feedback`	User feedback on assistant behavior	90 days
`reference`	Pointers to external resources	365 days

MCP Tools Reference

Tool	Description
`memory_use`	Set active project (no more repeating slug)
`memory_init_project`	Create new project namespace
`memory_attach_project`	Attach existing project directory
`memory_store`	Store memory with auto-embedding, summary, entities, TTL
`memory_search`	Semantic search with relevance scoring + token budgeting
`memory_recall`	Get memory by ID or exact title
`memory_update`	Partial update (re-embeds if content changes)
`memory_delete`	Soft or hard delete with provenance
`memory_list`	Filtered listing with pagination
`memory_provenance`	Full audit trail for a memory
`memory_get_rules`	Get all rules (cached, direct SQL)
`memory_session_start`	Start session, load full context
`memory_session_end`	End session, store summary
`memory_make_portable`	Move DB to project dir for git sharing
`memory_sync`	Register portable DB after git pull
`memory_export`	Export to .md files for non-MCP users
`memory_import`	Import from .md files
`memory_list_projects`	List all projects
`memory_project_info`	Get project details
`memory_model_info`	Current embedding model + available presets
`memory_set_model`	Switch between english and multilingual models
`memory_reembed`	Re-embed all memories with current model
`memory_version`	Server version + configuration

Architecture

~/.memory-mcp/
  registry.duckdb              # Project registry (list of all projects)
  projects/
    my-app.duckdb              # Per-project vector DB (ONLY my-app's memory)
    api-backend.duckdb         # Per-project vector DB (ONLY api-backend's memory)
  backups/                     # Automatic backups before destructive operations

# Or portable (DB lives in the project dir, shared via git):
my-app/
  .memory-mcp.duckdb           # This project's memory (in git)
  .memory/                     # Optional: human-readable .md export

Internal architecture (for contributors):

┌───────────────────────────────────────────────┐
│  server.py — FastMCP tool bindings (thin)     │
├───────────────────────────────────────────────┤
│  services/ — business logic                   │
│    MemoryService, SearchService, SessionService,
│    RulesService, ProjectService, PortableService,
│    ExportImportService, ModelService          │
├───────────────────────────────────────────────┤
│  repositories/ — SQL, centralized             │
│    MemoryRepository, ProjectRepository,       │
│    SessionRepository, ProvenanceRepository    │
├───────────────────────────────────────────────┤
│  db/ — connection, schema                     │
└───────────────────────────────────────────────┘

Stack: FastMCP + DuckDB (VSS/HNSW) + sentence-transformers + Pydantic v2

Requirements

Python 3.11+
macOS or Linux (Apple Silicon fully supported)
~80MB disk for the English embedding model (~470MB for multilingual)
~90MB RAM for the English model loaded (~500MB for multilingual)

Development

uv sync --all-extras
uv run pytest -v

Current test coverage: 98 tests — 34 repository unit tests, 35 service unit tests, 29 integration tests.

License

MIT

Available Tools

24 tools

memory_attach_projectC

Attach an existing project directory. Auto-activates on success.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	No
`description`	No
`display_name`	No
`project_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It discloses 'Auto-activates on success' (a behavioral trait), but fails to describe other important behaviors: side effects (e.g., does it modify files?), required permissions, reversibility, or error conditions. The single behavioral note is helpful but insufficient for a tool with no annotations.

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

Conciseness2/5

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

The description is extremely short (two sentences, 11 words). While concise, it is underspecified and lacks structure (e.g., no front-loading of key information, no separation of purpose from usage). The brevity results in missing essential details.

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

Completeness1/5

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

Given the tool's complexity (4 parameters, 0% schema coverage, no annotations, and an output schema that is not described), the description is severely incomplete. It does not explain the return value (even though an output schema exists), parameter semantics, or behavioral context. The agent cannot reliably select or invoke this tool.

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

Parameters1/5

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

Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The tool description does not compensate: it does not explain the purpose of any of the four parameters (slug, description, display_name, project_path). An agent must guess their meanings from names alone, which may be ambiguous.

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

Purpose4/5

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

The description clearly states the verb 'attach' and resource 'existing project directory', which conveys the basic purpose. However, it does not explicitly differentiate from sibling tools like memory_init_project (which creates new projects) or memory_list_projects (which lists projects). The distinction is implied but not stated.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context (e.g., project must exist), or when not to use it. An agent would have to infer usage from the name alone.

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

memory_check_updateA

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

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

Without annotations, the description fully describes behavior: read-only check, no modifications, returns update instructions. It is transparent about its non-destructive nature and the steps it takes.

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

Conciseness5/5

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

The description is extremely concise and well-structured. The main purpose is front-loaded, with only four short sentences that each add value. No unnecessary words.

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

Completeness5/5

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

Everything relevant is covered: purpose, mechanism, side effects, and output. The existence of an output schema is noted, and the description already mentions returning instructions, so it is complete for a simple check tool.

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

Parameters4/5

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

The input schema has no parameters, so schema coverage is 100%. The description adds no parameter information, but none is needed. A baseline of 4 is appropriate for zero-parameter tools.

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

Purpose5/5

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

The description clearly states the tool checks for a newer version of the Memory MCP server, using a specific verb ('check') and resource. It distinguishes itself from siblings like memory_version by focusing on update availability.

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

Usage Guidelines4/5

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

The description explains how the tool works (GitHub Releases, fallback to git commit comparison) and what it doesn't do (no modifications). It provides guidance on when to use it, though it does not explicitly compare with siblings or state when not to use.

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

memory_deleteC

Soft-delete (archive) or hard-delete a memory.

ParametersJSON Schema

Name	Required	Description	Default
`hard`	No
`reason`	No
`project`	No
`memory_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It mentions two behaviors but lacks details on impact, reversibility, or side effects of each delete mode.

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

Conciseness3/5

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

Very concise single sentence, but it omits essential information. Appropriate length for the simplicity, but lacks structure for detailed guidance.

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

Completeness2/5

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

With 24 sibling tools and no output schema description, the description is incomplete. It does not explain what happens after deletion, how to recover soft-deleted memories, or expected output.

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

Parameters1/5

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

Schema description coverage is 0%, and description does not explain any of the 4 parameters (memory_id, hard, reason, project). Agent gets no help understanding parameter purpose or constraints.

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

Purpose5/5

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

Description clearly states the tool deletes a memory with two modes: soft-delete (archive) or hard-delete. This distinguishes it from sibling tools like memory_update, memory_list, etc.

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

Usage Guidelines2/5

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

No guidance on when to use soft vs hard delete, or when not to use this tool. No mention of prerequisites or alternatives.

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

memory_exportC

Export all active memories to human-readable .md files.

ParametersJSON Schema

Name	Required	Description	Default
`project`	No
`export_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It does not disclose whether the operation is read-only, if it modifies memory, or any side effects. 'All active memories' is ambiguous, and there is no mention of permissions or error conditions.

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

Conciseness3/5

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

Single sentence is concise, but lacks essential details that would make it useful. For a tool with no schema coverage, this is under-specification rather than effective conciseness.

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

Completeness2/5

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

Given no annotations and 0% schema coverage, the description is incomplete. It does not explain what happens after export (e.g., return value from output schema), the scope of 'active memories', or file handling behavior.

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

Parameters1/5

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

With 0% schema description coverage, the description must explain parameters but does not. 'export_path' is required, but not described as file vs directory. 'project' is optional with no hint of its purpose (e.g., filtering by project).

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

Purpose5/5

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

Description clearly states the action (Export), resource (all active memories), and output format (human-readable .md files). It distinguishes from sibling tools like memory_import or memory_make_portable by specifying the export to .md files.

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

Usage Guidelines2/5

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

No guidance on when to use this tool over alternatives. Siblings include memory_import and memory_make_portable, but the description does not clarify scenarios where this tool is preferred.

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

memory_get_rulesC

Get all mandatory and forbidden rules (direct SQL, cached).

ParametersJSON Schema

Name	Required	Description	Default
`project`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

Behavior3/5

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

The description mentions caching and direct SQL, which gives some insight into behavior. However, with no annotations, it fails to disclose important traits like read-only nature or side effects. The caching hint is useful but incomplete.

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

Conciseness3/5

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

The description is a single sentence, very concise, but lacks essential details that could be added without verbosity. It is appropriately short but sacrifices clarity.

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

Completeness2/5

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

Given the presence of an output schema, the tool is partially documented, but the description fails to explain the purpose of the parameter, the meaning of 'rules', or the role of caching. Despite output schema, the textual description is insufficient for a complete understanding.

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

Parameters1/5

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

The single optional parameter 'project' is not described at all. Schema description coverage is 0%, and the description does not clarify what the parameter does or how it affects results.

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

Purpose4/5

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

The description clearly states the tool retrieves all mandatory and forbidden rules, with a mention of direct SQL and caching. However, it does not differentiate from other memory tools like memory_search or memory_recall, which may also retrieve data.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as memory_search or memory_recall. The description provides no context for when rules should be fetched.

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

memory_importC

Import memories from exported .md files.

ParametersJSON Schema

Name	Required	Description	Default
`project`	No
`import_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

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

No annotations exist, so the description carries full burden. It only states 'Import' but fails to disclose behavioral traits like overwrite behavior, conflict resolution, or permission requirements. The one-line description is insufficient for safe invocation.

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

Conciseness3/5

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

The description is concise at one sentence, but it sacrifices necessary detail. It is front-loaded with the purpose, yet it would benefit from a brief note on parameters or behavior. The trade-off reduces overall utility.

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

Completeness1/5

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

Given the tool has 2 parameters, no schema descriptions, no annotations, and an output schema is present but unmentioned, the description is far from complete. It fails to cover essential invocation context, leading to high ambiguity.

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

Parameters1/5

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

The input schema has 0% description coverage, and the tool description does not explain any parameter. 'import_path' is required but not described (e.g., file path format), nor is 'project' (optional, purpose unclear). This forces the agent to guess or rely on external knowledge.

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

Purpose5/5

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

The description clearly states the verb 'import' and the resource 'memories from exported .md files', which is specific and distinguishes from siblings like memory_export (export) and memory_store (store). The format is explicitly mentioned, aiding correct selection.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives (e.g., memory_store for raw memories, memory_export for reverse operation). There are no context hints or exclusions, leaving the agent without situational direction.

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

memory_init_projectC

Initialize a new project namespace (creates DuckDB + registers it).

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes
`set_active`	No
`description`	No
`display_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden. It discloses creation and registration but does not detail side effects, required permissions, or behavior on duplicate slugs. Partial transparency.

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

Conciseness3/5

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

The description is a single sentence, which is concise but lacks structure like front-loading key details. It is minimally viable but could benefit from more efficient organization.

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

Completeness2/5

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

Given the tool's complexity (4 parameters, no schema descriptions, no annotations, but has output schema), the description fails to address key aspects like duplicate handling, use of set_active, or what 'registers it' entails. Incomplete for effective agent use.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning to parameters like slug, display_name, set_active, or description beyond their names. Baseline for 0% coverage should be a high score only if description compensates, which it does not.

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

Purpose5/5

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

The description clearly states the verb 'Initialize' and the resource 'project namespace', with explicit mention of creating DuckDB and registering it. This distinguishes it from query tools like memory_list_projects.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., memory_attach_project for existing projects). The description implies usage for new projects but lacks explicit context or exclusions.

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

memory_listC

List memories with filtering, sorting, and pagination.

ParametersJSON Schema

Name	Required	Default
`tags`	No
`limit`	No
`offset`	No
`status`	No	active
`project`	No
`sort_by`	No	updated_at
`category`	No
`sort_order`	No	desc

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description must carry behavioral disclosure. It only says 'list memories', implying a read operation, but fails to describe pagination limits, default sort behavior, or any side effects. This is insufficient for safe use.

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

Conciseness4/5

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

Single sentence, front-loaded, no redundancy. Could be improved by adding parameter details without being excessively long. Current version is concise but too sparse.

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

Completeness2/5

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

Despite an output schema existing, the description omits critical context: what filtering fields are available, what sorting options exist, pagination behavior (max limit?), and how this differs from other retrieval tools. Incomplete for a tool with 8 optional parameters.

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

Parameters1/5

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

Schema has 8 parameters with 0% coverage in description. The description mentions 'filtering, sorting, and pagination' but provides no mapping to parameters like tags, limit, offset, sort_by, etc. An agent gets no help understanding parameter roles or valid values.

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

Purpose4/5

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

Description clearly states 'List memories' with filtering, sorting, and pagination, making the purpose evident. However, it does not distinguish from siblings like memory_search or memory_recall, which serve overlapping retrieval purposes.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus siblings. For example, it does not specify that this is a structured list query vs. a semantic search (memory_search) or a specific recall (memory_recall).

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

memory_list_projectsA

List all registered projects.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It states 'list', indicating a read operation, but lacks details on whether results are paginated, sorted, or limited. While the behavior is simple, additional context (e.g., 'returns all projects without filtering') would improve transparency.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no superfluous words. It is highly concise and easy to parse.

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

Completeness4/5

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

Given the tool's simplicity (no parameters, output schema present), the description is largely complete. However, it lacks contextual guidance distinguishing it from memory_list, which could be a sibling. The output schema likely covers return values, so no further detail is critical.

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

Parameters4/5

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

With zero parameters, schema description coverage is 100%, so the baseline is 4. The description adds no semantic detail about parameters, but none are needed. The name and description already convey the action.

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

Purpose5/5

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

The description 'List all registered projects' uses a specific verb ('list') and resource ('projects'), making the tool's action and scope clear. It distinguishes from sibling tools like memory_list (which likely lists memories) and memory_project_info (which focuses on a single project).

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

Usage Guidelines3/5

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

The description implies use when you need to see all projects, but it does not explicitly state when to use this tool vs alternatives such as memory_project_info for specific details. No when-not-to-use guidance is provided, leaving room for ambiguity.

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

memory_make_portableC

Move the project's DB into the project directory for git sharing.

ParametersJSON Schema

Name	Required	Description	Default
`project`	No
`project_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It mentions 'move' but does not clarify whether the original database is deleted, copied, or linked. No information about permissions, side effects, or safe usage.

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

Conciseness4/5

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

The description is a single sentence, front-loaded with the main purpose. It is concise, though it sacrifices necessary detail.

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

Completeness2/5

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

With no annotations, 0% schema coverage, and a brief description, the tool lacks crucial context for correct invocation. The agent would not understand parameter roles or behavioral expectations.

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

Parameters1/5

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

The description does not explain any parameters. Schema coverage is 0%, and the two parameters (project, project_path) are not mentioned at all. The description adds no meaning beyond the raw schema.

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

Purpose4/5

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

The description clearly states the action ('Move') and the object ('the project's DB into the project directory for git sharing'). It is specific enough to distinguish this tool from other memory tools that manage or query memory, though it does not explicitly differentiate from siblings.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description implies usage for git sharing, but there is no explicit mention of prerequisites, when not to use, or alternative tools.

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

memory_model_infoA

Current embedding model + available presets.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It implies a read-only operation returning info, but does not explicitly state that, nor does it mention any side effects, authentication needs, or rate limits. For a simple info tool, this is minimally adequate.

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

Conciseness5/5

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

The description is extremely concise—one short sentence. It is front-loaded and every word is meaningful. There is no waste.

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

Completeness4/5

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

Given zero parameters, an existing output schema, and a simple purpose, the description provides sufficient information about what the tool returns. It could be slightly more specific (e.g., 'returns names'), but is complete enough for this context.

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

Parameters4/5

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

The tool has no parameters, and schema coverage is 100% (empty). The description does not need to add meaning beyond the schema; baseline of 4 is appropriate.

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

Purpose4/5

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

The description clearly states the tool returns the current embedding model and available presets. It uses specific terms and, while brief, adequately distinguishes it from sibling tools that handle storage, search, or versioning.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'memory_set_model' or 'memory_version'. The description does not mention typical use cases or context.

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

memory_project_infoD

Get detailed info for a project.

ParametersJSON Schema

Name	Required	Description	Default
`project`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1.7/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only indicates a read operation ('Get'), but provides no details on side effects, required permissions, rate limits, or what 'detailed info' encompasses. Insufficient for safe use.

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

Conciseness2/5

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

The description is a single underspecified sentence. While brief, it fails to earn its place by providing meaningful substance, making it more of a placeholder than a concise, helpful guide.

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

Completeness2/5

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

Given the tool has one parameter, no schema descriptions, no annotations, and an output schema that is not referenced, the description is incomplete. It lacks information about what the output contains, which is critical given the vagueness of 'detailed info.'

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

Parameters1/5

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

Schema description coverage is 0%. The description does not explain the 'project' parameter's meaning, format, or expectations (e.g., ID vs. name). The default null is not addressed.

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

Purpose2/5

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

The description states 'Get detailed info for a project,' which is a verb+resource but is vague. It does not differentiate from sibling tools like memory_version or memory_get_rules, leaving ambiguity about what specific information is returned.

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

Usage Guidelines1/5

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

No guidance on when to use this tool versus alternatives. The agent has no context about prerequisites, typical use cases, or how it compares to other memory tools.

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

memory_provenanceC

Get the full audit trail for a memory.

ParametersJSON Schema

Name	Required	Description	Default
`project`	No
`memory_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits beyond the basic operation. It does not mention whether the operation is read-only, requires special permissions, or has any 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.

Conciseness3/5

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

The description is extremely concise (one sentence), but this brevity comes at the cost of necessary detail. It could easily include parameter context or usage hints without being verbose.

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

Completeness2/5

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

Given the tool has an output schema and only two parameters, the description still lacks completeness. It does not explain the notion of 'provenance' or 'audit trail,' nor does it clarify the role of the optional project parameter.

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

Parameters1/5

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

Schema description coverage is 0%, meaning no parameter descriptions are in the schema. The tool description fails to explain either parameter (memory_id, project), leaving the agent with no semantic guidance beyond the names.

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

Purpose5/5

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

The description "Get the full audit trail for a memory" clearly specifies the action (get) and the resource (audit trail for a memory). It distinguishes from siblings like memory_version or memory_search, which have different purposes.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus other memory tools, such as memory_version for version history. It lacks any when-to-use or when-not-to-use context.

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

memory_recallC

Recall a specific memory by ID or exact title.

ParametersJSON Schema

Name	Required	Description	Default
`title`	No
`project`	No
`memory_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It states 'recall' implying read-only, but does not explicitly confirm idempotency, side effects, or authorization requirements. Minimal behavioral disclosure.

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

Conciseness4/5

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

Single sentence is efficient and front-loaded with key verb and resource. However, it sacrifices detail for brevity, missing parameter enumeration.

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

Completeness2/5

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

With 3 optional params, an output schema, and many sibling tools (e.g., memory_search, memory_list), the description is too sparse. It lacks clarity on exact match requirement, parameter precedence, and when to use over alternatives.

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

Parameters2/5

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

Schema coverage is 0%, and the description only mentions 'by ID or exact title', covering memory_id and title but omitting the project parameter. No explanation of parameter interactions or defaults.

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

Purpose4/5

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

The description clearly states the action (recall) and resource (memory) with identification methods (ID or exact title). It implies precise matching, distinguishing from fuzzy search siblings like memory_search, but could explicitly differentiate.

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

Usage Guidelines2/5

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

No guidance provided on when to use this tool versus alternatives (e.g., memory_search for fuzzy queries, memory_list for listing all). No exclusions or context for appropriate use.

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

memory_reembedC

Re-embed all active memories with the current model.

ParametersJSON Schema

Name	Required	Description	Default
`project`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided, so description must fully disclose behavior. It implies a mutation (re-embedding) but does not mention consequences, reversibility, or dependencies like needing a model set.

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

Conciseness4/5

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

The description is very concise (9 words), but at the cost of completeness. It is front-loaded but lacks necessary detail.

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

Completeness1/5

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

The description is inadequate given the tool's complexity, lack of annotations, and many sibling tools. No output schema is described, and parameter usage is unexplained.

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

Parameters1/5

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

The single parameter 'project' is not described at all in the description. With 0% schema coverage, the agent cannot understand its purpose or when to use it.

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

Purpose4/5

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

The verb 're-embed' and resource 'all active memories' clearly state the action. It distinguishes from siblings like memory_store or memory_search, but 'active' is ambiguous.

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

Usage Guidelines2/5

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

No usage guidelines provided. There is no indication of when to use this tool vs siblings like memory_update or memory_set_model, or prerequisites.

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

memory_searchC

Semantic search with composite relevance scoring.

ParametersJSON Schema

Name	Required	Default
`tags`	No
`limit`	No
`query`	Yes
`status`	No	active
`project`	No
`category`	No
`token_budget`	No
`min_similarity`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only mentions 'semantic search' and 'composite relevance scoring' without explaining what this entails, how scoring works, or whether the operation is destructive or read-only.

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

Conciseness2/5

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

The description is very short, but this is not concise—it is under-specified for a tool with 8 parameters. It lacks necessary detail, making it uninformative.

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

Completeness1/5

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

Given the tool's complexity (8 parameters, no schema descriptions, no annotations), the description is highly incomplete. It does not explain the search scope, output format, or how parameters affect behavior.

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

Parameters1/5

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

Schema description coverage is 0%, meaning the input schema provides no descriptions. The tool description does not explain any of the 8 parameters (e.g., tags, limit, min_similarity), leaving agents without guidance on how to use them.

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

Purpose3/5

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

The description says 'semantic search with composite relevance scoring,' which indicates a search tool but does not specify what is being searched (e.g., stored memories). It is vague and does not clearly differentiate from sibling tools like memory_recall or memory_list.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of 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.

memory_session_endB

End a session and store its summary.

ParametersJSON Schema

Name	Required	Description	Default
`project`	No
`summary`	Yes
`session_id`	Yes
`memories_created`	No
`memories_accessed`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are available, so the description must fully disclose behavior. It only says 'store its summary' without explaining what 'store' entails (e.g., persistence, immutability, or whether it finalizes the session). No mention of side effects or required permissions.

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

Conciseness5/5

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

The description is an extremely concise single sentence that front-loads the action. 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.

Completeness2/5

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

Despite having an output schema, the description does not clarify return values or behavior. With 5 parameters (2 required) and no param descriptions, the description leaves many open questions about usage and effects, especially regarding the optional project and integer parameters.

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

Parameters2/5

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

Schema description coverage is 0%, yet the description provides no explanation for any of the five parameters (session_id, summary, project, memories_created, memories_accessed). Only 'summary' is hinted at via 'store its summary', leaving the rest completely undocumented.

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

Purpose5/5

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

The description 'End a session and store its summary' clearly specifies the verb 'end' and the resource 'session', along with an additional action 'store its summary'. It uniquely identifies the tool among siblings, especially distinguishing it from '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.

Usage Guidelines3/5

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

No explicit when-to-use or when-not-to-use guidance is provided. However, the context of sibling tools like 'memory_session_start' implies its usage for ending sessions. Lacks prerequisites or consequences.

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

memory_session_startB

Start a session. Loads rules, last summary, sprint goals, recent decisions.

ParametersJSON Schema

Name	Required	Description	Default
`project`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior3/5

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

No annotations provided, so description bears full burden. It discloses that the tool loads specific data (rules, summary, etc.), which indicates state changes. However, it does not mention idempotency, destructive behavior, or auth requirements. The output schema may cover return values, but behavior is only partially disclosed.

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

Conciseness4/5

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

The description is a single sentence that is front-loaded with the core action. It is concise but could include more detail about the session lifecycle or parameter usage without becoming verbose.

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

Completeness3/5

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

Given the tool's simplicity (start session, one optional param, output schema exists), the description includes the key loaded items but omits context about the session lifecycle, such as whether it resets an existing session or requires a project to be initialized first. It is adequate but not fully complete.

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

Parameters2/5

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

Schema description coverage is 0%, yet the description fails to mention the single 'project' parameter. The description adds no meaning beyond the schema, leaving the agent to guess what 'project' does. With only one optional parameter, the gap is less severe, but still significant.

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

Purpose5/5

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

The description clearly states 'Start a session' followed by specific items loaded (rules, last summary, sprint goals, recent decisions). This is a specific verb+resource combination that distinguishes it from sibling tools like memory_session_end and memory_init_project.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or how it relates to other session or memory tools.

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

memory_set_modelB

Switch embedding model between 'english' and 'multilingual' presets.

ParametersJSON Schema

Name	Required	Description	Default
`preset`	Yes
`confirm`	No
`project`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It fails to disclose important behavioral traits such as the need for confirmation (implied by the confirm parameter), whether existing embeddings are re-indexed, or if the change is project-specific (implied by the project parameter).

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

Conciseness4/5

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

The description is very brief (one sentence) and front-loads the key action and options. However, it could be better structured by including inline parameter explanations, though it already avoids unnecessary verbosity.

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

Completeness2/5

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

Given the tool has 3 parameters, no annotation coverage, and a known output schema, the description is incomplete. It lacks explanation of the confirm and project parameters, does not describe return values, and omits behavioral details like side effects or scope.

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

Parameters2/5

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

Schema description coverage is 0% and the description only names the two presets but does not explain the 'preset' parameter's exact format or enumerations. It also ignores the 'confirm' and 'project' parameters entirely, leaving their purpose unclear.

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

Purpose5/5

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

The description clearly states the verb 'Switch', the resource 'embedding model', and the two preset options 'english' and 'multilingual'. It distinguishes this tool from siblings like memory_reembed or memory_model_info by specifying the action of switching presets.

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

Usage Guidelines3/5

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

The description implies the tool is for switching between preset models, but it does not provide explicit guidance on when to use it versus alternatives, nor does it mention when not to use it or any prerequisites.

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

memory_storeB

Store a new memory with auto-embedding, summary, entity extraction, and TTL.

ParametersJSON Schema

Name	Required	Default
`tags`	No
`title`	Yes
`source`	No	assistant
`content`	Yes
`project`	No
`category`	Yes
`metadata`	No
`priority`	No
`related_ids`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, description carries full burden. It discloses auto-embedding, summary, entity extraction, TTL, but omits details like potential delays, auth needs, or side effects of TTL.

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

Conciseness4/5

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

Single sentence is concise and front-loaded. Could benefit from structured list of features but no wasted words.

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

Completeness2/5

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

With 9 parameters, no annotations, and many siblings, description is too brief. Lacks explanation of return values (output schema exists but not mentioned), parameter defaults, or workflow integration.

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

Parameters2/5

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

Schema coverage is 0%, but description only vaguely mentions features not mapped to parameters. No explanation for tags, source, project, metadata, related_ids, or priority. TTL is not a parameter, causing confusion.

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

Purpose5/5

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

Description clearly states 'Store a new memory' with specific verb and resource. Mentions auto-embedding, summary, entity extraction, TTL which distinguish it from siblings like memory_update, memory_search, etc.

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

Usage Guidelines3/5

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

Implied usage for storing new memories, but no explicit when-to-use, when-not-to-use, or alternatives. Sibling tools like memory_update could be confused without guidance.

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

memory_syncB

Sync a portable DB after git pull. Auto-activates on success.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	No
`project_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavioral traits. 'Auto-activates on success' hints at behavior but is vague; no mention of read-only vs destructive, required permissions, 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.

Conciseness4/5

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

Extremely concise with two sentences, no waste. However, it is perhaps too sparse and could benefit from slightly more detail without losing conciseness.

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

Completeness2/5

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

Given two parameters, no annotations, and an output schema, the description is insufficient. It fails to explain parameters, return values, or contextual behavior for effective tool selection and invocation.

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

Parameters1/5

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

Schema description coverage is 0%, but description adds no meaning to parameters slug or project_path. The description is completely silent on parameter guidance.

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

Purpose5/5

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

Clearly states the verb 'sync' and resource 'portable DB' with specific trigger 'after git pull', distinguishing it from sibling tools like memory_store or memory_search.

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

Usage Guidelines4/5

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

Implicitly indicates usage after git pull, but lacks explicit when-not-to-use or alternatives. The trigger is clear, so it's good but not perfect.

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

memory_updateB

Update an existing memory. Re-embeds if title/content changed.

ParametersJSON Schema

Name	Required	Description	Default
`tags`	No
`title`	No
`status`	No
`content`	No
`project`	No
`metadata`	No
`priority`	No
`memory_id`	Yes
`related_ids`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses the re-embedding behavioral trait, but fails to mention other side effects, latency, atomicity, or error conditions. Partial transparency.

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

Conciseness5/5

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

Two sentences with no fluff. Every word adds value: action, resource, and key behavioral trigger. Efficient and front-loaded.

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

Completeness2/5

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

Despite having an output schema, the description lacks sufficient context for a 9-parameter tool with no annotations or schema descriptions. Missing parameter behaviors, error handling, and operational details.

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

Parameters1/5

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

Schema description coverage is 0%, yet description provides no parameter-level information. All 9 parameters remain undocumented in both schema and description, forcing the agent to guess their meaning.

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

Purpose5/5

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

The description clearly states the verb 'Update' and the resource 'existing memory', and adds the specific detail that re-embedding occurs if title/content changes. This distinguishes it from siblings like memory_store (create) or memory_delete.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., memory_store for upsert) or prerequisites (e.g., memory must exist). Missing context for proper selection among siblings.

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

memory_useA

Set the active project. Subsequent tools use it by default.

ParametersJSON Schema

Name	Required	Description	Default
`project`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided; description lacks details on side effects, idempotency, permissions, or overwriting behavior. Minimal transparency beyond the core action.

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

Conciseness5/5

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

Two sentences, no fluff, front-loaded with core purpose. Perfectly concise for the tool's simplicity.

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

Completeness3/5

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

Adequate for a simple setter given output schema exists, but could clarify statefulness (session-bound? persistent?) and relation to sibling tools.

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

Parameters2/5

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

Schema coverage is 0% with no parameter description. Description only says 'Set the active project' for the single parameter, not providing format or valid values.

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

Purpose5/5

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

Description clearly states verb 'Set', resource 'active project', and effect 'Subsequent tools use it by default'. It distinguishes from siblings like memory_init_project and memory_project_info.

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

Usage Guidelines4/5

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

Description implies when to use (before other tools needing project context) and notes default behavior. No explicit when-not or alternatives, but sufficient for a simple setter.

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

memory_versionA

Get the current version of the Memory MCP server and configuration.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only states it retrieves version without disclosing any behavioral traits like side effects, authentication needs, or response format. Minimal disclosure for a read-only operation.

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

Conciseness5/5

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

Single sentence, no redundant information. Every word serves a purpose. Appropriately front-loaded for quick understanding.

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

Completeness4/5

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

Given no parameters and existence of an output schema, the description is largely sufficient for a simple version tool. Could optionally specify format or examples to reach full completeness.

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

Parameters4/5

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

Input schema has 0 parameters with 100% coverage, so description correctly adds no parameter details. Baseline score of 4 per calibration guidelines for zero-parameter tools.

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

Purpose5/5

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

Description clearly states verb 'Get' and resource 'version of the Memory MCP server and configuration', making purpose unambiguous. Easily distinguished from siblings like memory_model_info which focuses on model version.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. However, the tool is self-explanatory for version retrieval, and sibling tools have distinct purposes, so implicit usage is adequate.

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

Install Server

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

TDQS

B3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with descriptions that resolve potential overlap. Tools for storing, searching, recalling, updating, and deleting memories are well-differentiated. Retrieval tools (search, recall, list) each target different access patterns.

Naming Consistency4/5

All tools start with 'memory_' forming a consistent prefix. However, the second component mixes verb_noun (memory_store, memory_search), noun phrases (memory_project_info), and bare verbs (memory_use), which is somewhat inconsistent. The pattern is more noun-heavy than typical verb_noun conventions.

Tool Count3/5

With 24 tools, the server offers extensive functionality, but this exceeds the typical well-scoped range of 3-15. While the domain (memory management with projects, sessions, models, git sync) justifies many tools, the count feels heavy. A reduction or grouping could improve coherence.

Completeness4/5

The tool set covers most expected operations for a memory server: CRUD for memories, project management, session handling, model configuration, export/import, and audit trails. Missing features include project deletion and rule editing, which are minor gaps. The surface is largely complete for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

suma-memory A
io.github.sumanaddanki
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Knowledge & Memory Developer Tools Autonomous Agents
2
Threadminder
ai.threadminder
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Knowledge & Memory Project Management
2
TeamShared B
io.github.xhad
Shared memory for coding agents. Stop re-explaining your codebase every session.
Knowledge & Memory Developer Tools
1041
ContextStream MCP Server
io.github.contextstream
Project memory, semantic code search, and grounded agent context.
Knowledge & Memory Code Analysis RAG Systems
139

Related MCP Servers

acheron-mcp-server
Knowledge & Memory Developer Tools File Systems
timmx7
A
license
A
quality
D
maintenance
Cross-surface persistent memory for Claude. Bridges context between Claude Chat, Code, and Cowork via local SQLite with full-text search.
Updated 5 months ago (2026-03-26 15:36 UTC)
6
21
6
MIT
Claude Memory MCP
Knowledge & Memory Developer Tools
navid-kianfar
A
license
A
quality
D
maintenance
Persistent, searchable per-project memory for Claude Code using DuckDB and vector search, with rule enforcement and a management UI.
Updated 2 months ago (2026-07-01 20:25 UTC)
37
MIT
Claude Persistent Memory
Knowledge & Memory RAG Systems
MIMI180306
A
license
Not graded
quality
C
maintenance
Gives Claude Code long-term memory that persists across sessions via hybrid BM25 and vector semantic search, with multi-project isolation.
Updated 6 months ago (2026-02-25 10:57 UTC)
11
8
MIT
claude-memory
Knowledge & Memory Search
Tim-Fischer-zh
A
license
Not graded
quality
D
maintenance
Provides persistent, searchable memory for Claude Code using local SQLite, semantic embeddings, and full-text search, enabling Claude to recall and retrieve context across sessions and projects without external services.
Updated 5 months ago (2026-03-24 06:27 UTC)
19
4
MIT

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/serkansmg/smg-claude-memory-mcp'

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

SMG Claude Memory MCP

In Plain English

What does this project actually do?

Three things users should understand

The technical one-liner

What you'll feel day-to-day

FAQ — Common Questions, Clear Answers

Q: When I run make_portable, does it move ALL projects' memory to git, or just the one I'm working on?

Q: Will my memories from one project contaminate another project?

Q: What happens if my context window fills up mid-session?

Q: Do I need to manually store every memory?

Q: Does anything leave my machine?

Q: Can my teammate who doesn't have this MCP still read the memories?

How It Works — The Flow

The Cast

Flow 1: You ask a question

Flow 2: You make a decision

Flow 3: You start a new conversation

High-Level View

Multilingual Support

The Default: English-Only

Switching to Multilingual

Cross-Lingual Superpower

Comparison

Switching Back

Check Current Model

Why Not Just Use MEMORY.md?

Features

Quick Install

Manual Install

Quick Start

Usage

Project Management

Session Lifecycle

Memory Operations

Team Collaboration

Option A: Share via Git (portable DB)

Option B: Export for non-MCP users

Automatic Memory (No Commands Needed)

Memory Categories

MCP Tools Reference

Architecture

Requirements

Development

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Q: When I run `make_portable`, does it move ALL projects' memory to git, or just the one I'm working on?

Why Not Just Use `MEMORY.md`?