Teach AI coding agents to learn from mistakes and remember project knowledge across sessions.
Memory Management
Save memories across 5 categories: config (settings/URLs/ports), dont (mistakes/anti-patterns), decision (architecture choices), log (implementation records), and snippet (reusable commands/queries), with optional tags, scope, and intensity rating
Search memories using hybrid full-text + vector semantic search (works offline, includes Japanese support), filterable by category, scope, or cross-project (project: "active" searches top 5 recent projects)
Two-stage retrieval — lightweight index search returns IDs/titles/tags, then fetch full details on demand to save context window space
Delete or update memory entries, including manually pinning high-priority entries (intensity 6+ gets priority injection)
Intelligent Consolidation & Context Injection
Automatically compresses dont entries into 5–9 actionable behavioral principles and config entries into 4–5 thematic summaries, reducing injection size by ~71%
Converts negative instructions ("don't do X") into affirmative rules ("do Y") to prevent the Pink Elephant problem
Two injection modes: full injection or agent mode (minimal index only, sub-agents retrieve details on demand)
Automated Learning from Mistakes
Detects user frustration, retry patterns, and repeated failures during sessions
Automatically analyzes conversations to save lessons, assign intensity scores (1–5 based on sentiment), and promote frequently accessed memories
Autonomous Task Execution
Submit tasks with objectives, desired outcomes, and machine-verifiable completion criteria for 24/7 AI-driven execution with automatic retry
Check task status (pending/in-progress/completed/failed) and manage human action items for unresolved issues
Project Setup
Initialize project-specific quality standards, phases, and decision criteria to guide autonomous task execution and memory management
Integrates with Google's Gemini API to perform sophisticated conversation analysis, sentiment detection, and automated synthesis of project rules and memories.
Uses Markdown as a structured storage format for project context, decision logs, and code snippets, ensuring the AI's memory is both human-readable and version-controllable.
Supports automated status notifications via webhooks to alert users when autonomous background tasks, such as documentation updates, are completed or fail.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@wasurenagusa-mcp Search for the project rules and technical decisions we made earlier."
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.
Teach your AI coding agent to learn from its mistakes.
wasurenagusa (forget-me-not) — a Japanese flower whose name means "don't forget me."
AI coding agents are powerful but amnesiac. Every session starts from scratch — your project conventions, past decisions, and hard-learned lessons vanish the moment a session ends.
Existing solutions either require manual effort or simply store raw memories that grow until they overwhelm the context window.
Related MCP server: memory-bank-mcp
wasurenagusa is an MCP server that doesn't just remember — it learns.
Detects mistakes automatically — Catches retry patterns, user frustration, and repeated failures
Distills lessons into principles — LLM compresses hundreds of raw entries into a handful of actionable rules
Converts negatives to positives — Generates positiveRule alongside each principle: "don't do X" becomes "do Y instead." Research shows LLMs follow affirmative instructions significantly better than prohibitions (Pink Elephant problem)
Compresses config into themes — LLM groups scattered settings into coherent summaries, preserving facts like ports and paths
Injects only what matters — Consolidated wisdom + active settings only. No template bloat, no duplicate entries.
Hybrid search (full-text + semantic) — SQLite-backed storage with local embedding inference (no external API needed). Full-text search with Japanese support + vector semantic search, merged and deduplicated. Works completely offline.
Smart tag retrieval — LLM-generated weighted tags + composite scoring (freshness, tag weight, access frequency) optimize retrieval priority without discarding any data.
Memory stash/restore — Temporarily stash memories out of the active context to save context window space, then restore them when needed. Ideal for long sessions with sub-agents.
Fully automated via Claude Code hooks — zero configuration after setup.
From the author's daily use across 8 production projects (with cross-project memory sharing between them):
1,581 "dont" entries → 5-9 principles per project (LLM consolidation)
each with positiveRule → affirmative-only injection (Pink Elephant fix)
29 config entries → 4-5 thematic summaries (LLM consolidation)
21,800 chars raw data → 6,200 chars injected (71% reduction)Session 1: Claude uses port 3000 — user corrects it to 8080
Stop Hook: wasurenagusa auto-analyzes the conversation and records the mistake
Session 2: Claude correctly uses port 8080 without being told
Most memory tools store what happened. wasurenagusa teaches your AI why things went wrong — and ensures it never repeats the same mistake.
It's not a memory bank. It's a learning system.
wasurenagusa | claude-mem | mcp-memory-service | CLAUDE.md | |
Auto-detect mistakes | Yes (retry + sentiment) | No | No | No |
Auto-consolidate (LLM) | Yes (dont→principles, config→themes) | No | Yes (decay-based) | No |
Vector semantic search | Yes (local inference, offline) | Yes (ChromaDB) | Yes (SQLite-vec / ChromaDB) | No |
Memory tiers (short/mid/long) | Yes (cosine distance thresholds) | No | No | No |
Auto-promotion (intensity) | Yes (access count → intensity 5) | No | No | No |
Zero-effort via hooks | Yes | Yes | Partial | No |
Human-readable storage | No (SQLite — auto-migrated from v1 Markdown) | No (SQLite) | No (SQLite-vec) | Yes |
Multi-LLM support | Gemini / OpenAI / Anthropic (embedding is local — no API key needed) | Claude only | Local (MiniLM-L6-v2) | N/A |
Token-efficient retrieval | Yes (index → detail, 70-90% savings) | Yes (3-layer) | N/A | No |
Cross-project memory | Yes (top 5 active projects) | No | No | No |
License | MIT | AGPL-3.0 | Apache-2.0 | N/A |
Session Start (Hook) — injection mode
→ Checks if consolidation is stale
→ Spawns background LLM worker if needed (non-blocking)
→ Spawns background embedding backfill worker (non-blocking)
→ Injects consolidated config + principles (layer 1) + recent 30-day entries (layer 2) + owner profile
→ Vector search injects semantically related short-term memories (layer 3)
→ Cross-project vector search injects related memories from other active projects (layer 4)
→ Only customized settings injected (defaults stripped)
Session Start (Hook) — agent mode
→ Injects dont summary + config index + owner profile (minimal footprint)
→ No vector search at startup (deferred to on-demand recall)
User Prompt (Hook) — agent mode
→ Injects 1-line reminder: "search memory if relevant"
→ Main agent spawns memory-recall sub-agent as needed
→ Sub-agent runs memory_search → returns summary only (no raw data in main context)
→ Survives compaction (re-injected on every user message)
During Session
→ memory_save auto-generates embedding via local inference (no API call)
→ memory_save enriches tags with LLM-assigned weights (0.0-1.0) (when API key available)
→ Theme shift triggers background re-tagging of related past entries
→ memory_search merges keyword + vector semantic + tag-weighted results
→ Vector hits increment access counts → auto-promote to intensity 5 at threshold
Session End (Hook)
→ LLM analyzes the conversation
→ Detects mistakes, frustration, retry patterns
→ Auto-saves lessons learned (with embedding)
→ Deduplicates against existing entries before saving
→ Updates active projects tracker (top 5 recent projects)
Background (async workers)
→ Consolidates "dont" entries → behavioral principles
→ Consolidates "config" entries → thematic summaries
→ Backfills embeddings for entries created before vector layer (20/run)
→ Results used in next session start💡 Recommended: Paste this README into Claude Code and ask it to set up wasurenagusa for you. It'll handle everything below automatically.
Node.js 18+
Claude Code (CLI)
No external API key required for core memory features (embedding runs locally)
Optional: API key for LLM consolidation/analysis — Gemini / OpenAI / Anthropic
npm install -g wasurenagusa-mcpOr from source:
git clone https://github.com/tsutushi0628/wasurenagusa-mcp.git
cd wasurenagusa-mcp
npm install && npm run build
npm link
npm run buildautomatically runschmod +xon CLI entry points. No manual permission setup needed.
Create ~/.wasurenagusa/.env:
# Set at least one API key
GEMINI_API_KEY=your-key-here
# OPENAI_API_KEY=your-key-here
# ANTHROPIC_API_KEY=your-key-hereVariable | Required | Description |
| One of three | Google Gemini API key |
| One of three | OpenAI API key |
| One of three | Anthropic API key |
| No |
|
| No | Override the default model for your provider |
| No | Memory directory (default: |
| No | Entry limit per category before auto-archiving (default: |
| No | Log retention period in days (default: |
| No | Slack notifications for autonomous tasks |
claude mcp add wasurenagusa -- wasurenagusa-mcp⚠️ Required — Without this step, memory is never injected at session start. This is the most commonly missed setup step.
Add to ~/.claude/settings.json (or settings.local.json if you prefer to keep hooks separate):
{
"hooks": {
"SessionStart": [
{
"hooks": [
{
"type": "command",
"command": "wasurenagusa-context",
"timeout": 5
}
]
}
],
"UserPromptSubmit": [
{
"hooks": [
{
"type": "command",
"command": "wasurenagusa-context",
"timeout": 5
}
]
}
],
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "wasurenagusa-analyze",
"timeout": 30
}
]
}
],
"PreCompact": [
{
"hooks": [
{
"type": "command",
"command": "wasurenagusa-context",
"timeout": 15
}
]
}
]
}
}Launch Claude Code. That's it.
First session: .wasurenagusa/ directory is created automatically
After first conversation: Stop Hook analyzes and saves important context
Second session onward: accumulated wisdom is auto-injected at start
Add
.wasurenagusa/to your.gitignore— it contains project-specific memory data.
Category | What it stores | File |
config | API URLs, ports, auth locations |
|
dont | Mistakes, anti-patterns, user frustrations |
|
decision | Architecture decisions, tech choices |
|
log | Implementation records, resolved errors |
|
snippet | Frequently used commands & queries |
|
Tool | Description |
| Get config + consolidated principles (auto-called at session start) |
| Lightweight index search (ID, title, tags only). Use |
| Get full detail by ID(s) |
| Save a memory entry explicitly |
| Temporarily stash memories to save context window space |
| Restore previously stashed memories back into active context |
| Delete entries by ID |
| Submit an autonomous task for 24/7 execution |
| Check task execution status |
| List and manage pending human actions |
| Initialize project quality standards |
Command | Purpose | Invoked by |
| Output config + dont + vector memories to stdout | SessionStart / UserPromptSubmit / PreCompact Hook |
| LLM-analyze conversation and auto-save | Stop Hook |
| Generate embeddings for entries without vectors | Background (auto-spawned) |
| Repair corrupted memory data (dedup, re-sort logs) | Manual |
| Auto-update spec documents | cron / systemd timer |
| Run consolidation across all active projects | Manual / Scheduler |
| Install/uninstall/status nightly consolidation scheduler | Manual |
wasurenagusa supports two output modes for the SessionStart Hook, configurable per project via .wasurenagusa/config.json.
Mode | Description | Best for |
injection (default) | Injects full memory text at session start | Environments without sub-agents (Cursor, Windsurf, etc.) |
agent | Injects minimal index at session start + memory-recall reminder on each user message. Details retrieved on-demand via sub-agents | Claude Code + Agent Teams |
Add outputMode to your project's .wasurenagusa/config.json:
{
"outputMode": "agent"
}If the file doesn't exist or outputMode is not set, the default is "injection" (full backward compatibility).
When using "agent" mode with Claude Code Agent Teams, add these rules to your project's CLAUDE.md:
- Read/write memories via sub-agents (memory_search / memory_get_detail / memory_save)
- Do not bring raw memory data into the main context
- When system-reminder suggests memory recall, spawn a sub-agent to run memory_search and return summary onlywasurenagusa introduces a biologically-inspired memory system powered by local embeddings. Every memory is converted to a 384-dimensional vector, enabling meaning-based retrieval that goes far beyond keyword matching.
Three-tier architecture with cosine distance thresholds:
Tier | Threshold | Use case |
Short-term | ≤ 0.2 | Highly relevant — auto-injected at session start |
Medium-term | ≤ 0.45 | Contextually related — surfaced during |
Long-term | ≤ 0.7 | Loosely related — discoverable but not proactively shown |
Automatic promotion: Every time a memory is retrieved via vector search, its access count increments. After 5 retrievals, the memory auto-promotes to intensity: 5 — ensuring frequently-needed knowledge gets maximum weight in consolidation. Long-dormant memories can be "woken up" by relevance and eventually earn top intensity through repeated access.
How it works:
memory_save
→ Text → local inference (Hugging Face Transformers) → embedding → SQLite (sqlite-vec)
memory_search "authentication setup"
→ Full-text search (FTS5, Japanese support) ─┐
→ Embed query → vector similarity search ─┤→ merge, deduplicate → results
└→ increment access count
→ auto-promote if threshold met
SessionStart Hook
→ Embed project name → short-tier search → inject related memoriesNo external API required — embeddings are generated locally via @huggingface/transformers. Data is stored in SQLite with sqlite-vec for vector indexing. Works completely offline.
Automatic migration from v1 — existing Markdown-based memory files are automatically migrated to SQLite on first run. No manual steps required.
Smart Tag Retrieval improves search precision through three mechanisms — without ever deleting or forgetting data:
Weighted tag enrichment at save time — When you save a memory, the LLM generates descriptive tags and assigns each a weight (0.0-1.0). Concrete facts like port numbers or API endpoints receive high weights; generic categories receive low weights.
Background re-tagging on theme shift — When a new topic is detected, a background worker updates tags on related past entries so they stay discoverable under the new context.
Composite scoring — Search results are ranked by a blend of freshness, tag weight, and access frequency — surfacing the most relevant memories first.
All memories are preserved at full fidelity. Smart Tag Retrieval only optimizes retrieval priority, never discards data.
wasurenagusa automatically tracks your top 5 most recently used projects and searches across their memories for relevant context.
How it works:
Stop Hook records each project session in ~/.wasurenagusa/scheduler/active-projects.json
SessionStart searches other active projects' vector stores (short tier ≤ 0.2, high-relevance only)
memory_search with project: "active" searches across all active projects (keyword + vector)
Example: You're working on project-a and previously discussed authentication in project-b. When you start a session in project-a and the topic is related, wasurenagusa automatically surfaces the relevant auth memories from project-b.
No configuration needed — works automatically after two or more projects have been used.
When memory entries accumulate, the LLM automatically compresses them into compact summaries:
Dont entries → 5-9 behavioral principles scored by sourceCount × maxIntensity. Each principle includes both the original rule (❌→💡→✅ format) and a positiveRule (affirmative-only phrasing). The positiveRule is injected by default — research on the Pink Elephant problem shows LLMs struggle with negation in instructions.
Config entries → 4-5 thematic summaries (e.g., 29 entries → 5 themes preserving all ports, paths, URLs)
Consolidation runs as a detached background process during session start, and optionally as a nightly scheduled job (2:00 AM). Results are cached as JSON and used from the next session onward. Staleness is detected by comparing file modification times and entry counts.
Raw entries are always preserved. The consolidated version is injected at session start; original entries remain searchable via memory_search.
Every consolidated principle stores two forms:
Field | Format | Purpose |
| ❌ Bad pattern → 💡 Why it's bad → ✅ Correct behavior | Full context for |
| Affirmative-only action statement ("do X", "use Y") | Injected into LLM context |
Why? LLM attention mechanisms activate concepts mentioned in negations — "don't use innerHTML" still activates "innerHTML." Affirmative instructions ("use textContent") activate only the desired behavior. The raw user feedback (dont.md) is preserved unchanged; conversion happens only at the consolidation layer.
Every dont entry carries an intensity score (1-5) representing the severity of the lesson:
Intensity | Meaning | Example |
5 | Rage / resignation — user nearly gave up | "I told you 10 times, STOP doing this" |
4 | Strong frustration — explicit anger | "No! Don't do that!" |
3 | Clear correction — firm but calm | "That's wrong, do it this way" |
2 | Mild note — gentle guidance | "Next time, prefer X over Y" |
1 | Suggestion — informational | "FYI, we usually do it like this" |
Auto-detection: The LLM analyzes user messages for emotional signals (exclamation marks, strong language, repeated corrections) and assigns intensity automatically. Conversation metadata (turns since last positive feedback, message length ratio) provides additional boost signals.
Manual override: Pass intensity: N to memory_save to set or adjust the score.
Scoring formula: During consolidation, each principle gets score = sourceCount × maxIntensity. Principles are sorted by score descending — frequently repeated, high-anger lessons appear first with stronger wording.
Each memory category has an entry limit (default: 100). When exceeded, oldest entries are automatically moved to archive files (*-archive.md). Logs have separate 30-day rotation. Your data is never deleted — just moved out of the active search path.
Detects user frustration through text patterns, message length changes, and absence of positive signals. Records what went wrong, why, and what to do instead.
Submit tasks via task_submit and wasurenagusa runs them using Claude CLI as a subprocess. The LLM evaluates completion conditions and retries if needed. Useful for spec updates, refactoring, and test generation.
On first run, an owner-profile.md template is generated. Fill it in to teach the AI your decision-making preferences for autonomous task execution.
Only sections you've actually customized are injected — default selections and empty fields are automatically stripped, keeping injection minimal.
Instead of only consolidating at session start, you can schedule nightly consolidation across all active projects — like "sleeping on it overnight."
# Install (macOS: launchd, Linux: crontab)
wasurenagusa-scheduler install
# Check status
wasurenagusa-scheduler status
# Remove
wasurenagusa-scheduler uninstallRuns daily at 2:00 AM, consolidating dont and config entries for all recently active projects. This ensures your AI starts every morning with freshly organized principles, even if you never close your sessions.
Claude Code only — Hook-based auto-injection requires Claude Code. The MCP server itself works with any MCP-compatible client, but without auto-injection.
Autonomous by default, manual by choice — Hooks automate everything. Manual tools exist but are optional.
Context-efficient — LLM consolidation + smart filtering achieves 71% injection reduction. Two-stage retrieval (index then detail) further reduces on-demand consumption.
SQLite storage — All memory stored in SQLite with sqlite-vec for vector indexing. Auto-migrated from v1 Markdown format.
Externalized prompts — LLM prompts live in prompts/ as plain text. Iterate without rebuilding.
npm run build # Compile TypeScript
npm test # Run tests
npm run test:watch # Watch modeMIT
メモリエントリを削除する。memory_searchで取得したIDを指定して削除。 複数IDを一括指定可能。カテゴリをまたいだ削除もOK。
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | 削除したいエントリのID配列 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It mentions cross-category deletion scope and bulk capability, but fails to mention whether deletion is permanent, if there are permission requirements, or error handling behavior when IDs don't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four compact sentences with zero waste: action definition, ID source requirement, bulk capability, and scope flexibility. Information is front-loaded with the core action first, followed by constraints and capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter deletion tool without output schema, the description adequately covers the operational workflow (search-then-delete) and key behavioral constraints (bulk, cross-category). Minor gap in not describing the operation's result or permanent nature, but sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema has 100% coverage (baseline 3), the description adds valuable semantic context by specifying that IDs come from 'memory_search' (workflow prerequisite) and explicitly noting that multiple IDs can be bulk-specified, reinforcing the array nature of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'メモリエントリを削除する' (Delete memory entries), providing a specific verb and resource. It clearly distinguishes this as the sole deletion tool among siblings (memory_save, memory_search, memory_update_intensity, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow guidance by specifying that IDs should be obtained from 'memory_search' first. It also notes bulk and cross-category deletion capabilities. However, it lacks explicit 'when not to use' guidance or mention of alternatives like memory_update_intensity for partial modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
config（設定情報）とdont（やってはいけないこと）を一括取得する。 通常はSessionStart Hookで自動注入されるため、手動で呼ぶ必要は少ない。 セッション途中でコンテキストを再確認したい場合に使用。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully conveys the SessionStart Hook injection pattern, which is critical operational context. However, it lacks explicit statements about read-only safety, idempotency, caching behavior, or the structure of the returned config/dont data, leaving gaps in the safety/behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: (1) function definition, (2) automatic usage pattern/warning, (3) exceptional manual usage case. The logical flow moves from what it does, to the common case (don't use), to the edge case (do use). Japanese text is economical and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter retrieval tool, the description adequately covers the operational context (hook injection) and identifies the returned data categories (config and dont). However, given the absence of annotations and output schema, it could be improved by explicitly confirming the read-only nature of the operation or describing the return format structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters (empty object). According to calibration rules, zero parameters establishes a baseline score of 4. The description correctly does not invent parameter documentation where none exist, and the 100% schema coverage is vacuously satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool performs batch retrieval ('一括取得') of specific resources: 'config' (configuration) and 'dont' (constraints/things not to do). It clarifies what 'context' means in this domain, effectively distinguishing it from siblings like memory_get_detail or memory_search which likely operate on specific memories rather than system context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: it states when NOT to use the tool ('通常はSessionStart Hookで自動注入されるため、手動で呼ぶ必要は少ない' - rarely needed manually because it's auto-injected at session start) and specifically when TO use it ('セッション途中でコンテキストを再確認したい場合' - when reconfirming context mid-session). This clear conditional guidance prevents unnecessary invocations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_search で取得したIDを指定して、メモリのフル詳細を取得する。 複数IDを一括指定可能。必要なものだけ取得してトークンを節約すること。
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | 取得したいメモリエントリのID配列 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses batch capability ('複数IDを一括指定可能') and cost implications (token saving). However, lacks disclosure of error behavior (what happens if ID not found), idempotency, or safety characteristics beyond the implicit 'get' operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two efficient sentences. First sentence establishes purpose and batch capability; second provides optimization guidance. Zero redundancy, front-loaded with essential workflow information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no nested objects, 100% schema coverage), the description is appropriately complete. It explains the integration with memory_search (sibling tool) and batch behavior. Minor gap regarding error handling or return value description, but acceptable without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description adds valuable semantic context that IDs should come specifically from memory_search (not arbitrary sources) and emphasizes batch retrieval capability, enriching the 'ids' parameter meaning beyond the schema's basic type description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves 'full details' (フル詳細) of memories using IDs, with specific verb+resource. It distinguishes from sibling memory_search by explicitly stating this tool requires IDs obtained from memory_search, establishing a clear workflow dependency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite ('memory_search で取得したIDを指定して'), guiding users to search first. Includes specific optimization guidance ('必要なものだけ取得してトークンを節約') for efficient usage. Lacks explicit 'when not to use' or named alternatives, though the workflow implication is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
メモリを保存する。カテゴリ:
config: API URL、ポート、認証情報などの設定
dont: やってはいけないこと、過去のミス、ユーザーが怒ったこと、AIのリトライパターン
decision: 決定事項、採用した方針
log: 実装したこと、解決したエラー
snippet: よく使うコマンド、クエリ、便利スクリプト
titleには検索しやすい具体的な名詞を含めること。
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | メモリのカテゴリ | |
| title | Yes | 1行の要約タイトル（20文字以内推奨）。検索用の具体的な名詞を含める。例: 「本番API URL」「ログ未読への怒り」 | |
| content | Yes | 保存する内容の詳細 | |
| tags | No | 検索用タグ（オプション、最大5個） | |
| scope | No | スコープ（オプション）。推奨候補: frontend, backend, infra, design, spec, ai, general。自由入力も可 | |
| intensity | No | 怒られ度（オプション、1〜10の整数）。1=提案, 2=軽い注意, 3=明確な指摘, 4=強い不満, 5=激怒・諦め。6以上は手動ピン留め用（数値が大きいほどcontext注入で優先される）。指定時はLLM自動判定より優先される |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses behavioral semantics of the intensity parameter (the 1-10 scale meaning from '提案' to '激怒') and category taxonomy, but omits operational details like idempotency, overwrite behavior for duplicate titles, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly structured with the core action front-loaded, followed by a scannable bulleted category list with inline semantics, and closing with specific title guidance. No redundant text; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema coverage and lack of output schema, the description is appropriately complete for a save operation. It comprehensively covers the categorical taxonomy and intensity semantics that the schema cannot express fully, though it could briefly mention whether the operation returns an ID or confirmation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the input schema has 100% description coverage (baseline 3), the description adds significant semantic value by detailing what each enum value in 'category' represents (e.g., 'config: API URL、ポート、認証情報などの設定') and expanding the 'intensity' parameter with the full semantic scale of anger levels (1=提案 through 5=激怒).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb+resource 'メモリを保存する' (save memory) and immediately distinguishes this as the creation tool among CRUD siblings by enumerating the five distinct category types (config, dont, decision, log, snippet) that can be saved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides extensive contextual guidance on when to use each category (e.g., 'config' for API URLs/auth, 'dont' for past mistakes, 'snippet' for commands) and specific title formatting instructions. Lacks explicit comparison to sibling tools like memory_update_intensity or memory_delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
メモリを検索する。【重要】このツールは軽量インデックス（ID, タイトル, タグ）のみを返す。 フル内容が必要な場合は、返されたIDを memory_get_detail に渡すこと。 全件の詳細を取得せず、必要なものだけ取得してトークンを節約すること。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 検索クエリ（キーワード） | |
| category | No | 検索対象カテゴリ。デフォルトはall | |
| limit | No | 最大取得件数。デフォルトは20 | |
| project | No | プロジェクトフィルタ（オプション）。指定するとそのプロジェクト+プロジェクト未指定のエントリのみ返却。"active"を指定すると最近作業した上位5プロジェクト横断で検索 | |
| scope | No | スコープフィルタ（オプション）。指定するとそのscope+general+scope未指定のエントリのみ返却 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses critical behavioral trait that only partial data is returned (軽量インデックスのみ), explains the token-saving optimization strategy, and clarifies the return structure. Minor gap: doesn't specify behavior when no matches found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: (1) purpose declaration, (2) critical limitation + alternative tool, (3) optimization rationale. Front-loaded with 【重要】alert and efficient Japanese prose. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Strong coverage for a 5-parameter search tool with no output schema: explains return format (lightweight index), workflow integration with memory_get_detail, and cost optimization. Lacks only error-handling context (e.g., empty results behavior) to be perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 5 parameters fully documented), so baseline score applies. Description focuses on behavioral guidance rather than repeating parameter details already covered in schema, which is appropriate prioritization.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with specific verb+resource (メモリを検索する) and immediately distinguishes from sibling tools by clarifying it returns only lightweight index (ID, title, tags) rather than full content, explicitly naming memory_get_detail as the alternative for full data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-not-to-use guidance (フル内容が必要な場合は...memory_get_detailに渡すこと) and describes the two-step workflow (search IDs first, fetch details selectively) to optimize token usage, directly addressing the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
既存メモリエントリのintensity（重要度）だけを変更する。 ピン留め運用に使う: intensity 6以上を設定するとcontext注入で最優先される。 memory_searchで取得したIDを指定すること。
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 更新対象エントリのID | |
| intensity | Yes | 新しいintensity値（1〜10の整数）。6以上は手動ピン留め用 |
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 critical behavioral details: setting intensity 6+ results in 'highest priority in context injection' (context注入で最優先される), explaining the ranking mechanism. It also clarifies this is a partial update (only intensity). It does not mention error handling for invalid IDs or idempotency, but covers the key domain-specific behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly structured sentences with zero waste: (1) purpose/scope, (2) usage mechanics and threshold behavior, (3) prerequisite workflow. Information is front-loaded and every sentence earns its place. Appropriate length for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple 2-parameter update tool. It explains the domain concept (intensity/pinning), references the necessary sibling tool (memory_search) for the workflow, and describes the priority system's effect. No output schema exists, but the description does not need to explain return values for this type of operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds workflow semantics beyond the schema: it specifies that the ID should come from memory_search (establishing tool chaining) and elaborates on the 'context injection priority' effect of the intensity parameter, which is not fully explained in the schema's description of the number range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'only changes the intensity of existing memory entries' (既存メモリエントリのintensityだけを変更する), using a specific verb and resource. It explicitly distinguishes itself from creation tools like memory_save by emphasizing 'existing' entries and narrowing scope to 'only intensity'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use: 'Used for pin operation' (ピン留め運用に使う) and specifies the prerequisite workflow 'Specify the ID obtained from memory_search' (memory_searchで取得したIDを指定すること). However, it does not explicitly state when NOT to use it (e.g., for creating new entries) or name alternatives like memory_save.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
プロジェクトの初期設定を行う。自律タスク実行のために、プロジェクトの品質基準・フェーズ・判断基準を登録する。
操作モード:
mode="generate": 選択式の質問リストを生成
mode="save": 回答をもとにプロジェクトメタ情報を保存
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | 操作モード | |
| projectName | Yes | プロジェクト名 | |
| projectPath | No | プロジェクトの絶対パス（mode=save時に必須） | |
| initialInfo | No | プロジェクトの初期情報（mode=generate時、省略可） | |
| answers | No | 質問への回答（mode=save時に必須）。キーは質問のkey、値は選択した回答 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool registers project metadata and saves meta-information, and mentions the autonomous execution context. However, it fails to specify critical operational details: whether 'save' mode is destructive (overwrites existing), idempotent, requires specific file permissions for projectPath, or what side effects occur (file creation vs database storage).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by operation mode bullets. Every sentence serves a function: the first defines the action and target, the second explains the 'why' (autonomous execution), and the bullets clarify the mode parameter semantics. No redundancy or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects, conditional requirements, two distinct operating modes) and lack of output schema, the description adequately explains the input workflow but omits critical details about return values (what does 'generate' return? what does 'save' return?) and error conditions. For an initialization tool, it should also address idempotency concerns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema has 100% coverage documenting each parameter, the description adds valuable workflow context explaining that 'generate' produces questions and 'save' consumes those answers to create metadata. It clarifies the semantic relationship between the mode, answers, and initialInfo parameters beyond the schema's standalone descriptions, though it doesn't add syntax details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'initial project setup' (プロジェクトの初期設定を行う) and specifies exactly what gets registered: 'quality standards, phases, and decision criteria for autonomous task execution' (品質基準・フェーズ・判断基準を登録する). It effectively distinguishes from siblings like memory_* (memory management) and task_* (task execution) by focusing on project metadata initialization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two-mode workflow (generate vs save) and implies the sequence (generate questions first, then save based on answers). However, it lacks explicit guidance on when to use this versus task_submit or memory_save, and doesn't specify prerequisites or conditions where this tool should not be used (e.g., existing projects).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
人間アクションリストを管理する。AIが解決できなかったタスクの一覧表示と対応操作。
操作モード:
mode="list"（デフォルト）: アクションリストを表示
mode="resolve": タスクに対応（action: "retry"=再実行, "complete"=手動解決済み, "cancel"=対応不要）
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 操作モード（デフォルト: list） | |
| taskId | No | 対応するタスクID（mode=resolve時に必須） | |
| action | No | 対応アクション（mode=resolve時に必須） |
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 successfully explains the semantics of actions (retry=re-execute, complete=manual resolution, cancel=no action needed) and conditional requirements, but lacks disclosure of side effects, return values, or safety profile (e.g., whether resolve operations are reversible).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is optimally structured with a clear purpose statement followed by an 'Operation modes' section that efficiently delineates the two modes and their associated actions. Every sentence earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description adequately covers the input parameters and operational modes but fails to describe what the 'list' mode returns or the success/failure behavior of the 'resolve' mode, leaving gaps in contextual completeness for a tool handling task lifecycle operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema has 100% coverage, the description adds significant value by explaining the operational semantics of enum values (e.g., clarifying that 'complete' means manually resolved and 'cancel' means no action needed) and explicitly noting conditional requirements for taskId and action that are not enforced in the schema's required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages 'human action lists' specifically for 'tasks AI could not resolve' (AIが解決できなかったタスク), using specific verbs (管理する, 一覧表示, 対応操作). This effectively distinguishes it from siblings like task_submit (new tasks) and task_status (monitoring).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear operational guidance through the two-mode structure (list vs resolve) and explains when each parameter is required (mode=resolve時に必須). However, it does not explicitly contrast with sibling tools like task_submit to clarify when to escalate to human action versus initial submission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
自律タスクの状態サマリを返す。pending/in-progress/completed/failed/human-required/cancelledの件数と直近20件のタスク一覧を表示。
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | プロジェクト名でフィルタ（省略時は全プロジェクト） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context about pagination (20-item limit) and specific status taxonomy, but does not explicitly state safety characteristics (read-only nature) or error handling, leaving gaps an annotation would normally cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core function (returning status summaries) and efficiently packs in specific status values and result limits with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description adequately compensates by detailing the return structure (count metrics + task list). For a single-parameter read operation, this provides sufficient completeness, though explicit safety confirmation would strengthen it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, documenting the optional 'project' filter parameter fully. The description does not mention the parameter, but since the schema is self-explanatory, it meets the baseline expectation without adding redundant information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a status summary (状態サマリ) of autonomous tasks, specifying exact status categories (pending/in-progress/completed/failed/human-required/cancelled) and output format (counts + recent 20 items), effectively distinguishing it from sibling tools like task_submit (submission) and task_action_list (action listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies usage context by detailing the output (status counts and recent tasks), suggesting it's for status overview/monitoring, it lacks explicit guidance on when to use this versus task_action_list or task_submit, and contains no 'when-not-to-use' exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
自律タスクを投入する。AIが24/365で自動実行し、完了条件を満たすまでリトライする。
投入する4項目:
why: なぜやるか（背景・目的）
what: どんな体験/行動変容を与えたいか
done: 完了条件（機械検証可能な基準。例: "npx tsc通過 + vitest全パス"）
project: プロジェクト名
| Name | Required | Description | Default |
|---|---|---|---|
| why | Yes | なぜやるか（背景・目的） | |
| what | Yes | どんな体験/行動変容を与えたいか | |
| done | Yes | 完了条件（機械検証可能な基準） | |
| project | Yes | プロジェクト名 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses critical behavioral traits: continuous execution (24/365), automatic retry logic, and completion-based termination. It could be strengthened by mentioning failure modes (e.g., max retry limits) or return values, but the execution model disclosure is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient structure: one sentence for purpose/behavior, a header '投入する4項目:', then four bullet-style parameter definitions. Every line earns its place. The critical behavioral information (24/365, retry) is front-loaded before parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter flat schema with no output schema, the description adequately covers operational context. It explains what happens after invocation (AI takes over execution). Minor gap: doesn't describe the return value (likely a task ID) or how to reference the task later, though sibling tools suggest this functionality exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds significant value by providing a concrete, syntax-rich example for the 'done' parameter: '例: "npx tsc通過 + vitest全パス"'. This example clarifies expected machine-verifiable formats beyond the schema's abstract description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '自律タスクを投入する' (submit autonomous tasks) and immediately clarifies the unique execution model: 'AIが24/365で自動実行し、完了条件を満たすまでリトライする' (AI executes automatically 24/365, retrying until completion conditions are met). This specific verb+resource+behavioral scope clearly distinguishes it from siblings like task_status (query) or memory_save (storage).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 24/365 auto-execution and retry behavior implicitly signals when to use this (for persistent background tasks) versus one-shot operations. While it doesn't explicitly name alternatives like 'use task_status to monitor progress,' the operational model is distinct enough to guide selection. Lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.15.0memory_deletememory_get_contextmemory_get_detailmemory_savememory_searchmemory_update_intensityproject_inittask_action_listtask_statustask_submitScored across 10 tools
Most tools have distinct purposes, but there is some overlap between memory_get_context and memory_get_detail, as both retrieve memory information. However, memory_get_context focuses on config and dont categories specifically, while memory_get_detail retrieves full details for any memory entry, which helps differentiate them. The other tools like memory_search, memory_save, and task-related tools are clearly distinct in their functions.
The naming follows a consistent verb_noun pattern throughout, such as memory_delete, memory_get_context, and task_submit. All tools use snake_case, which is uniform. The only minor deviation is project_init, which fits the pattern but stands out slightly as it doesn't start with a memory or task prefix, though it's still consistent in structure.
With 10 tools, the count is well-scoped for the server's purpose, which appears to be memory management and task automation. This number allows for comprehensive coverage without being overwhelming, including operations for memory CRUD, context retrieval, and task lifecycle management, making it efficient for agents to handle.
The tool set provides good coverage for memory operations (save, search, get, delete, update) and task management (init, action list, status, submit), but there are minor gaps. For example, there's no tool for updating memory content beyond intensity, and task operations lack direct update or delete functions, though agents might work around this with existing tools like task_action_list for resolution.
Cloud-hosted MCP server for durable AI memory
Persistent, verbatim, searchable memory for AI assistants — one memory across every MCP client.
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
