What can you do with this server?

A portable, durable memory store for AI agents that saves markdown notes with YAML frontmatter — no database required. Files are git-friendly and Obsidian-compatible. Core Memory Operations * Create (create_memory): Store facts, decisions, or context as structured notes with metadata (title, category, tags, status, aliases, author) * Retrieve (get_memory): Fetch a complete memory by ID, including its full markdown body and frontmatter * Append (append_memory): Add content to an existing memory while preserving current content and updating the timestamp * Update (update_memory): Patch metadata fields or replace the markdown body of an existing memory * Archive (archive_memory): Soft-delete by marking a memory as archived without removing the file * Delete (delete_memory): Permanently remove a memory Search & Browse * Search (search_memory): Full-text, relevance-ranked search across title, aliases, tags, description, and body; supports metadata filters (category, status, tags, author) * List (list_memories): Browse memory metadata in bulk without loading full content; filter by status, category, and tags Organization & Maintenance * Build index (build_memory_index): Generate a human-readable markdown index (index.md), optionally grouped by category * Load index (load_memory_index): Retrieve the generated index, with an option to refresh before loading * Rebuild/repair (rebuild_memory): Fix missing or malformed frontmatter, apply/normalize [[wikilinks]] from titles and aliases, and rebuild index.md/index.yaml; supports dry-run mode Key characteristics: memories are plain markdown files organized into category-based directories, support [[wikilinks]] for cross-referencing, and work with any MCP-compatible AI agent (Claude, OpenAI, local models, etc.).

Which integrations are available for this server?

Provides a portable memory server for AI agents, enabling persistent memory storage and retrieval for OpenAI agents through the Model Context Protocol.

How do I use memex-mcp?

1. Click on "Deploy 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., "@memex-mcp create a memory about the project architecture decision" 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.

memex-mcp

by deepak-bhardwaj-ps

Overview Schema Source Related Servers Discussions Admin

Python

Local

Smriti MCP

A portable memory server for AI agents, built for the Model Context Protocol (MCP).

PyPI version Python 3.10+ Tests

Smriti stores durable memories as plain markdown files with YAML frontmatter. This keeps your data readable, git-friendly, and easy to inspect outside any single agent runtime.

Features

Framework agnostic: Works with any MCP-compatible agent (Claude, OpenAI, local models, etc.)
Durable & portable: All memories stored as plain markdown files—no database required
Git-friendly: Version control your memories alongside your code
Search & filter: Full-text search, filtering by tags, categories, and status
Relationship tracking: Use [[wikilinks]] to connect related memories
Memory index: Auto-generate markdown indexes of your entire memory store
Archive & organize: Hierarchical organization with categories and status tracking

Related MCP server: mem-persistence

Installation

Smriti MCP is published on PyPI as smriti-mcp.

With pip

Install into your current Python environment:

pip install smriti-mcp

Then verify the CLI is available:

smriti-mcp --help

With uv

Install Smriti as a persistent command-line tool:

uv tool install smriti-mcp

Or run it directly without a separate install:

uvx smriti-mcp --help

From source for development

git clone https://github.com/deepak-bhardwaj-ps/smriti-mcp.git
cd smriti-mcp
pip install -e .

Quick Start

1. Run the server locally

smriti-mcp server --memory-root ~/.smriti/memory

By default, Smriti uses ~/.smriti/memory. You can override it with:

export SMRITI_MEMORY_ROOT="$HOME/.smriti/memory"
smriti-mcp server

If you prefer uvx, run the server with:

uvx smriti-mcp server --memory-root ~/.smriti/memory

2. Configure in your MCP client

Claude Desktop with pip or uv tool install (~/.config/claude_desktop_config.json):

{
  "mcpServers": {
    "smriti": {
      "type": "stdio",
      "command": "smriti-mcp",
      "args": ["server", "--memory-root", "~/.smriti/memory"]
    }
  }
}

Claude Desktop with uvx:

{
  "mcpServers": {
    "smriti": {
      "type": "stdio",
      "command": "uvx",
      "args": ["smriti-mcp", "server", "--memory-root", "~/.smriti/memory"]
    }
  }
}

Then restart Claude Desktop and Smriti will be available as a tool.

Available Tools

Core Operations

Tool	Description
`create_memory`	Create a new durable markdown memory with metadata
`get_memory`	Retrieve a memory by ID and return its full content
`append_memory`	Add content to the end of an existing memory
`update_memory`	Patch metadata or replace memory content
`delete_memory`	Permanently remove a memory
`remember`	Agent-friendly write API that records a trace and can create, append, or update
`consolidate_memory`	Create, append, or update a memory from reviewed trace content

Search & Browse

Tool	Description
`search_memory`	Full-text search across title, tags, categories, and body. Returns ranked results
`list_memories`	Browse memory metadata without loading full content. Filter by status, category, tags

Organization

Tool	Description
`archive_memory`	Mark a memory as archived (soft delete)
`build_memory_index`	Generate a markdown index of all memories for easy browsing
`rebuild_memory`	Fix frontmatter, apply/normalize wikilinks from titles and aliases, and rebuild indexes
`load_memory_index`	Load the generated index as markdown

Memory Format

Each memory is stored as a markdown file with YAML frontmatter:

---
id: project/Example Architecture Decision
title: Example Architecture Decision
category: project
tags:
  - architecture
  - decision
status: active
short_description: Decided to use async/await pattern
created_at: "2026-06-05T10:30:00+10:00"
updated_at: "2026-06-05T10:30:00+10:00"
---

## Background

We needed to handle concurrent requests efficiently.

## Decision

Use async/await with asyncio for I/O-bound operations.

## Consequences

- Improved throughput for concurrent operations
- Need to manage event loop carefully in multi-threaded contexts

See also: [[Async Migration]], [[Performance Metrics]]

Metadata Fields

id: Unique identifier (auto-generated from category + title, or custom)
title: Human-readable title
category: Organizational category (becomes directory in file structure)
tags: Array of searchable tags
status: active, archived, or custom status
short_description: Brief summary (used in indexes)
created_at: ISO 8601 timestamp
updated_at: ISO 8601 timestamp
memory_type, confidence, salience, scope, source_agent: Optional agent memory metadata used for filtering and recall

File Structure

~/.smriti/memory/
├── project/
│   ├── Example Architecture Decision.md
│   ├── Async Migration.md
│   └── Performance Metrics.md
├── research/
│   └── LLM Benchmarks.md
├── decisions/
│   └── Use Postgres.md
└── index.md

Smriti keeps default filenames aligned with memory titles so Obsidian-style wikilinks like [[API Rate Limiting Strategy]] resolve to API Rate Limiting Strategy.md.

When you run rebuild_memory, Smriti can automatically add missing wikilinks and normalize alias links. It matches longer titles and aliases first and only links whole phrases, so Durable Memory is preferred over durable, and able is not linked inside durable.

Usage Examples

Create a memory

from smriti_mcp.store import MemoryStore

store = MemoryStore("~/.smriti/memory")

result = store.create_memory(
    {
        "title": "API Rate Limiting Strategy",
        "category": "decisions",
        "tags": ["api", "performance"],
        "short_description": "Decided on sliding window rate limiting",
    },
    content="We chose sliding window over token bucket because...",
)

# Returns: {"id": "decisions/API Rate Limiting Strategy", ...}

Remember with precise metadata

result = store.remember(
    content="User prefers markdown-first durable memory with no mandatory vector database.",
    id="preferences/Markdown First Memory",
    meta={
        "title": "Markdown First Memory",
        "category": "preferences",
        "memory_type": "preference",
        "short_description": "Preference for markdown-first durable memory.",
        "source_agent": "codex",
        "confidence": "high",
    },
    mode="create",
)

remember treats supplied meta as authoritative. If short_description is omitted, Smriti leaves it omitted instead of deriving a partial summary from the body. In auto mode, Smriti only appends to an existing memory when there is a strong deterministic match such as the same title; use id with append or update mode for explicit writes.

Search memories

results = store.search_memory(
    query="rate limiting",
    include_content=False,  # Just metadata
)

for result in results:
    print(f"{result['id']}: {result['title']}")

List memories with filters

active_decisions = store.list_memories(
    status="active",
    category="decisions",
)

for memory in active_decisions:
    print(f"{memory['title']} ({memory['status']})")

Rebuild and repair memories

result = store.rebuild_memory(
    fix_frontmatter=True,
    apply_wikilinks=True,
    group_by_category=True,
)

print(result["wikilinks"]["links_added"])

Running Tests

# Install test dependencies
pip install -e ".[dev]"

# Run all tests
pytest tests/ -v

# Run integration tests only
pytest tests/test_smriti_mcp_integration.py -v

All tests pass, including full MCP stdio round-trip integration tests.

Architecture

MemoryStore: Core storage engine with markdown file I/O
Server: MCP server exposing tools to agents
CLI: Command-line interface for running the stdio server
Frontmatter: YAML metadata parsing and generation

The package has zero external database dependencies and works with Python 3.10+.

Roadmap

Web UI for browsing memories
Multi-user support with authentication
Memory graph visualization
Sync to cloud storage (S3, GCS)
Memory embeddings for semantic search

Contributing

Contributions are welcome! Please:

Fork the repository
Create a feature branch (git checkout -b feature/my-feature)
Add tests for new functionality
Ensure all tests pass (pytest tests/ -v)
Submit a pull request

License

MIT License - see LICENSE file for details.

Author

Created by Deepak Bhardwaj.

Available Tools

11 tools

append_memoryA

Append new markdown to an existing memory while preserving its current content and updating the modified timestamp.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Memory id to append to.
`content`	Yes	Markdown content to append to the end of the memory.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/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 fully disclose behavior. It mentions preserving content and updating timestamp, but fails to address error handling (e.g., non-existent id), permission requirements, size limits, or return value behavior. For a mutation tool, this is insufficient.

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, front-loaded with the primary action ('Append new markdown'). Every word is meaningful and there is no redundancy or filler.

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

Completeness3/5

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

Given that output schema exists (covering return values) and parameter descriptions are complete, the description is adequate for basic understanding. However, missing behavioral details (errors, prerequisites, side effects) reduce completeness for a mutation tool.

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

Parameters3/5

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

Schema coverage is 100%, providing baseline 3. The description adds limited semantics beyond the schema: it confirms 'content' is Markdown and specifies appending to the end. However, this is largely redundant with schema field descriptions.

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 indicates the action (append), the resource (existing memory), and the effect (preserve content, update timestamp). It distinguishes from siblings like 'update_memory' which would replace content, and 'create_memory' which creates new.

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 implies when to use (to add content without replacing), but lacks explicit when-not-to-use or alternatives. The sibling tool 'update_memory' provides implicit contrast, but no direct comparison is given.

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

archive_memoryA

Mark a memory as archived without deleting its markdown file.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Memory id to mark as archived.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description carries the burden. It discloses the non-destructive nature (file not deleted) but omits other behavioral details like reversibility or impact on search/listings. 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?

Single sentence, no wasted words, clearly front-loaded with action and resource. Exceptional conciseness.

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?

For a simple tool with one parameter and existing output schema, the description is mostly complete. It could mention whether archiving affects other operations, but it's sufficient for basic use.

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

Parameters3/5

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

Schema coverage is 100% and description does not add meaning beyond the schema's parameter description. Baseline score is appropriate as the description merely restates 'Memory id to mark as archived'.

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

Purpose5/5

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

The description clearly states the action (mark as archived) and resource (memory) while distinguishing it from deletion by noting 'without deleting its markdown file'. This differentiates it from the sibling tool delete_memory.

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 archiving is desired over deletion, but does not explicitly state when to use or provide alternative tool names. The contrast with deletion is present but not directive.

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

build_memory_indexB

Build or refresh the human-readable markdown memory index at index.md.

ParametersJSON Schema

Name	Required	Description	Default
`group_by_category`	No	When true, group index entries under category headings.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/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 states operation ('build or refresh') but does not disclose whether it overwrites files, requires memory state, or has side effects. Minimal behavioral context.

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 that is concise and front-loaded with the key action. No redundant words.

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

Completeness4/5

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

With one optional parameter and an output schema (implied), the description is nearly complete. It lacks explanation of what 'refresh' entails or dependencies on memory data, but suffices for a simple tool.

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

Parameters3/5

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

Schema coverage is 100% and the description adds no extra meaning beyond the schema's 'group_by_category' parameter. Baseline score applies.

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 'Build or refresh' and the specific resource 'human-readable markdown memory index at index.md.' It distinguishes from siblings like 'load_memory_index' and 'rebuild_memory' by focusing on index file generation.

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. There is no mention of prerequisites, or comparison with 'load_memory_index' or 'rebuild_memory'.

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

create_memoryA

Create a durable markdown memory for facts, decisions, preferences, or project context that should survive beyond the current chat.

ParametersJSON Schema

Name	Required	Description
`meta`	Yes	Structured metadata used for naming, grouping, filtering, and retrieval.
`content`	Yes	Markdown body of the memory. Use wikilinks like [[Other Memory]] to relate notes.
`id`	No	Optional stable memory id such as 'project/Deploy Workflow'. If omitted, Memex creates one from category and title.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/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 discloses that memories are durable and survive beyond the chat, but does not cover error handling, authorization, or side effects like overwrite on duplicate id.

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 wasted words. It efficiently conveys the core purpose.

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 a rich schema and output schema, the description provides the core purpose but lacks guidance on when to use vs siblings and how parameters like 'id' affect behavior (e.g., idempotency). More detail would improve 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?

Schema coverage is 100%, so baseline is 3. The description adds value by suggesting wikilinks in the 'content' parameter, which is not in the schema description. No other param details are added, but this is meaningful.

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

Purpose5/5

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

The description clearly states the tool's purpose with a specific verb ('Create') and resource ('durable markdown memory'), and distinguishes it from siblings like append_memory and update_memory by emphasizing durability and survival beyond the current chat.

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

Usage Guidelines3/5

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

The description implies usage for new, persistent memories but does not explicitly state when to use this tool over alternatives (e.g., update_memory). No when-not guidance is provided.

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

delete_memoryA

Permanently delete a memory note by id.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Memory id to permanently delete.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/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 discloses that the action is permanent ('permanently delete'), which is important for a destructive operation. However, it lacks details on authorization, side effects, or behavior when the id does not exist.

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

Conciseness5/5

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

The description is a single sentence, concise and front-loaded. Every word contributes meaning: 'Permanently delete a memory note by id.' No extraneous content.

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 (one required id parameter) and presence of an output schema (not shown), the description is largely complete. It explains the action and input. Missing are details on error handling or id validation, but it remains sufficient for basic use.

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

Parameters3/5

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

Schema description coverage is 100% (one parameter with description). The description adds no additional meaning beyond 'by id', which is already in the schema. Baseline 3 applies.

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 'Permanently delete a memory note by id.' It uses a specific verb (delete) and resource (memory note), and distinguishes from siblings like archive_memory or update_memory by specifying permanent deletion.

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 explicit guidance on when to use this tool versus alternatives like archive_memory or update_memory. It does not mention prerequisites, consequences, or conditional usage.

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

get_memoryB

Retrieve a memory note by id and return its complete markdown with YAML frontmatter.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Memory id returned by create_memory, for example 'project/Deploy Workflow'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior1/5

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

No annotations are provided, so the description carries the full burden. It mentions the action and output format but does not disclose behavioral traits such as idempotency, error handling for missing id, or any side effects. The description is insufficient to inform the agent about the tool's behavior.

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 concise sentence that efficiently conveys the core functionality and output. Every word contributes to the purpose without redundancy.

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 (one parameter, no nested objects) and the presence of an output schema, the description is adequate but lacks behavioral context and usage guidelines. It is minimally complete for a simple retrieval tool but could benefit from more detail.

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

Parameters3/5

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

Schema description coverage is 100% because the single parameter 'id' has a detailed description including an example. The tool description adds no additional information beyond the schema, so it meets the baseline expectation of a 3.

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 'Retrieve', the resource 'memory note', and the scope 'by id', and specifies the output format 'complete markdown with YAML frontmatter'. This distinguishes it from sibling tools like list_memories (which lists without details) and search_memory (which searches).

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 like search_memory or list_memories. Given multiple sibling tools for memory operations, explicit usage context is missing.

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

list_memoriesA

List memory metadata for browsing or filtering without returning full note bodies. Use search_memory when you need relevance ranking.

ParametersJSON Schema

Name	Required	Description
`category`	No	Optional category filter.
`status`	No	Optional lifecycle status filter, such as 'active' or 'archived'.
`tags`	No	Optional tags that every returned memory must contain.
`limit`	No	Maximum number of memories to return.

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?

The description states it returns metadata without full note bodies, which is key behavior. It could be more detailed about ordering or how filters interact, but with no annotations, this is acceptable.

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 concise with two sentences, front-loading the main purpose and adding a sibling distinction. No wasted words.

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

Completeness4/5

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

With an output schema present, the description doesn't need to explain return values. It covers filtering and browsing intent well, though it could mention default ordering or pagination behavior.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description doesn't add extra meaning to the parameters beyond what's in the schema.

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

Purpose5/5

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

The description uses a specific verb and resource ('List memory metadata') and explicitly distinguishes from 'search_memory', making the tool's purpose very clear.

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

Usage Guidelines4/5

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

The description explicitly advises using 'search_memory' for relevance ranking, providing clear guidance on when to use this tool. However, it doesn't mention other alternatives like 'get_memory' for full content.

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

load_memory_indexB

Load the generated markdown memory index, optionally refreshing it first.

ParametersJSON Schema

Name	Required	Description	Default
`refresh`	No	When true, rebuild index.md before returning it.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. 'Load' implies read, but 'refresh' involves writing (rebuilding the index); the description does not disclose side effects like file overwriting or performance impact, leaving gaps in behavioral understanding.

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?

A single sentence conveys the core functionality with no unnecessary words or repetition. Excellent front-loading and efficiency.

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?

With an output schema present and a single parameter, the description covers basic functionality. However, without annotations, it lacks details on read-only vs. write nature and fails to differentiate from sibling tools, leaving moderate gaps for a complete understanding.

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

Parameters3/5

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

Schema coverage is 100% with the refresh parameter clearly described. The description adds no new information beyond restating the parameter's effect, so a baseline score of 3 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 loads a markdown memory index with an optional refresh. It distinguishes from siblings like build_memory_index by implying 'load' retrieves an existing index rather than generating a new one.

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 build_memory_index or other siblings. The optional refresh is mentioned but without context on when it is appropriate, leaving the agent to infer usage scenarios.

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

rebuild_memoryA

Repair and rebuild the memory store: optionally fix frontmatter, apply or normalize wikilinks from memory titles and aliases using longest matches first, then rebuild index.md and index.yaml.

ParametersJSON Schema

Name	Required	Description
`apply_wikilinks`	No	When true, add and normalize wikilinks based on memory titles and aliases.
`fix_frontmatter`	No	When true, repair missing or malformed required frontmatter fields before indexing.
`group_by_category`	No	When true, group generated index.md entries under category headings.
`dry_run`	No	When true, report proposed frontmatter and wikilink changes without writing files or indexes.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

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

The description discloses the key behaviors: fixing frontmatter, applying wikilinks with 'longest matches first', and rebuilding indexes. It also mentions the dry_run flag for testing. However, it does not explicitly state whether existing data is overwritten or the full 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?

The description is a single sentence that packs significant detail, but it is somewhat dense and could be split for readability. It is concise but not perfectly structured.

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 presence of an output schema, the description does not need to detail return values. It covers the main functionality and parameters. However, it lacks high-level context on when to run this tool relative to other operations (e.g., after creating memories).

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?

Schema coverage is 100%, so baseline is 3. The description adds context beyond schema by mentioning 'longest matches first' for wikilinks and that dry_run reports changes without writing. This adds value for understanding parameter behavior.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Repair and rebuild the memory store' with specific actions (fix frontmatter, apply wikilinks, rebuild indexes). It distinguishes from siblings by mentioning rebuilding index.md and index.yaml, which other tools like build_memory_index may only partially cover.

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?

While the description implies usage for repairing the memory store, it does not explicitly state when to use this tool vs alternatives like build_memory_index or append_memory. No exclusions or prerequisites are given.

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

search_memoryA

Search durable memories with relevance ranking over title, aliases, tags, path, description, and body terms.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search terms, phrase, or topic to retrieve relevant memories for.
`limit`	No	Maximum number of ranked results to return.
`filters`	No	Optional exact-match metadata filters applied before ranking.
`include_content`	No	When true, include full markdown content in each result; set false to save context.

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 discloses the search fields and ranking but does not mention side effects (likely read-only, but not confirmed), performance characteristics, or return format details. Adequate but not comprehensive for a read operation without annotation support.

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 of ~20 words, front-loaded with the key action and resource. Every word contributes meaning; no redundancy or filler. Achieves maximum conciseness for a search tool.

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?

With 100% schema coverage and an output schema present, the description need not detail parameters or return values. It explains the core function and search scope. Minor omission: does not clarify that ranking is the default ordering or mention pagination, but overall it is nearly complete for a search 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?

Schema coverage is 100%, so baseline is 3. The description adds value by listing the specific fields searched (title, aliases, etc.), which is not in the schema descriptions. This helps the agent form effective queries. Other parameters are well-described in the schema, so the description's addition is meaningful.

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 specifies the action ('Search') and the resource ('durable memories') with a unique feature ('relevance ranking') and explicitly lists the fields searched (title, aliases, tags, path, description, body terms). This distinguishes it from sibling tools like list_memories (no ranking) and get_memory (single retrieval).

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

Usage Guidelines3/5

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

The description implies usage for finding relevant memories but does not explicitly state when to use this tool over alternatives like list_memories or get_memory. The context of sibling tools partially compensates, but direct guidance on when-not-to-use or prerequisites is missing.

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

update_memoryA

Patch memory metadata and optionally replace the full markdown body. Use append_memory when adding incremental observations.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Memory id to update.
`meta`	No	Partial metadata changes. Omitted fields keep their existing values.
`content`	No	Replacement markdown body. Leave null to preserve existing content.

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?

With no annotations, the description carries the burden. It mentions patching and replacing but does not disclose potential side effects, authentication needs, or error behavior. The output schema may cover returns, but behavioral traits like idempotency are omitted.

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 filler. The first sentence conveys the core action, and the second provides a sibling differentiator. Every word is meaningful.

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 complexity (3 parameters, high schema coverage, output schema), the description is adequate. It explains the primary operations and the alternative tool, leaving return values to the output schema.

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

Parameters3/5

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

The input schema has 100% coverage with descriptions for all parameters, so the description adds minimal extra value. It clarifies that 'content' is a full replacement and that 'meta' is partial, which is already implied by the schema.

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

Purpose5/5

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

The description clearly states the action: patching memory metadata and optionally replacing the full markdown body. It also distinguishes itself from the sibling 'append_memory' by specifying when to use that alternative.

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

Usage Guidelines4/5

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

The description provides explicit guidance on when to use this tool versus 'append_memory' for incremental additions. While it does not cover all siblings, this targeted alternative is sufficient for most cases.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

11 tool updatesv0.1.1Jun 8, 2026
- First observedappend_memory
- First observedarchive_memory
- First observedbuild_memory_index
- First observedcreate_memory
- First observeddelete_memory
- First observedget_memory
- First observedlist_memories
- First observedload_memory_index
- First observedrebuild_memory
- First observedsearch_memory
- First observedupdate_memory

Deploy Server

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

TDQS

A4/5.0

Scored 2026-06-08 05:05 across 11 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: create, read, update, delete, archive, search, and index operations are all separate, with no overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_memory, search_memory), making them predictable and easy to understand.

Tool Count5/5

11 tools is appropriate for a memory management server, covering essential operations without unnecessary bloat.

Completeness5/5

The tool set provides full lifecycle management: create, read (get, list, search), update (append, update, rebuild), delete, archive, and index operations, with no obvious gaps.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Agentage MemoryOAuth
io.agentage
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Knowledge & Memory File Systems
2
Living MemoryOAuth
to.viibe
An MCP memory server. One memory your agents share — across models, devices and apps.
Knowledge & Memory Autonomous Agents AI & Machine Learning
22
Motecloud MemoryOAuth
io.github.motecloud
Cloud-hosted MCP server for durable AI memory
Knowledge & Memory Cloud Platforms
2
WorkingMemory A
ai.workingmemory
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
Knowledge & Memory Search
42

Related MCP Servers

Universal Memory MCP Server
Knowledge & Memory Autonomous Agents AI & Machine Learning
DevMinions
A
license
Not graded
quality
D
maintenance
A portable MCP server providing a shared intelligent memory system for any MCP-compatible AI tool, enabling storage, retrieval, extraction, and governance of memories across sessions.
Updated 5 months ago (2026-03-30 07:00 UTC)
5
MIT
mem-persistence
Knowledge & Memory Search
emiliotorrens
A
license
Not graded
quality
B
maintenance
Persistent memory MCP server that stores and retrieves memories in Markdown files, enabling shared context across multiple AI agents with hybrid search and deduplication.
Updated 2 months ago (2026-07-25 09:42 UTC)
MIT
Agentic Memory
Knowledge & Memory Search
ArkaAiAdmin
A
license
A
quality
B
maintenance
MCP server for persistent, cross-session, local-first memory for AI agents, storing memories as Markdown files with SQLite indexing for hybrid search.
Updated 6 days ago (2026-09-06 13:41 UTC)
24
Apache 2.0
mnema
Knowledge & Memory RAG Systems File Systems
Ray0907
A
license
Not graded
quality
B
maintenance
Provides a file-first personal memory layer for AI agents, enabling them to store and retrieve memories as markdown files with an SQLite index. The MCP server offers read-only search by default, with optional write tools for manual memory addition and conflict resolution.
Updated a month ago (2026-08-04 09:51 UTC)
11
MIT

Smriti MCP

Features

Installation

With pip

With uv

From source for development

Quick Start

1. Run the server locally

2. Configure in your MCP client

Available Tools

Core Operations

Search & Browse

Organization

Memory Format

Metadata Fields

File Structure

Usage Examples

Create a memory

Remember with precise metadata

Search memories

List memories with filters

Rebuild and repair memories

Running Tests

Architecture

Roadmap

Contributing

License

Author

See Also

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers