Includes automation scripts for tmux to facilitate session reloading and context injection workflows.
Click on "Install 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., "@wisdom-store save the lesson about handling the race condition in our auth middleware"
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.
An MCP server that gives AI coding assistants persistent memory, context control, and anti-hallucination tools.
Early release — actively developed, APIs may change. Expect rough edges.
Context control — Trim conversation context live (no restart needed), inject curated knowledge into sessions, monitor context usage.
Persistent knowledge — Save lessons, patterns, cautions, and edge cases to flat files that survive across sessions. Organize by project section, file, or globally.
Project indexing — AST-based symbol extraction (via @ast-grep/napi), API route detection, HTML page inventory. Produces a compact project overview designed to give Claude a detailed map of your project for a fraction of your context window.
Anti-hallucination — Symbol registry with fuzzy matching catches hallucinated function names, typos, and unknown symbols. Includes a post-write hook that automatically warns about hallucinated imports, file paths, function calls, and API routes after every edit.
Related MCP server: MCP Memory Server
Tool | Description |
| Check context usage — message count, estimated tokens, bloat indicators |
| Trim old messages live. Modes: |
| Insert curated context as a new conversation root. Requires |
Tool | Description |
| Persist lessons, patterns, cautions, edge cases, or decisions to |
| Load wisdom for a file, section, or keyword. Call with no args for project overview |
| Document feature plans with files, decisions, and status |
| Browse what wisdom exists — sections, plans, patterns, sidecars |
Tool | Description |
| Scan project, extract symbols via AST, save to |
| Compact project map — file tree, symbols, API routes, HTML pages. Always fresh |
Tool | Description |
| Cross-reference symbols against registry. Reports: confirmed, fuzzy match (typo?), or unknown (hallucinated?) |
| Re-scan and update the symbol registry |
git clone https://github.com/InfiniQuest-App/wisdom-store.git
cd wisdom-store
npm installAdd to your ~/.claude.json or project .mcp.json (see examples/mcp.json):
{
"mcpServers": {
"wisdom-store": {
"command": "node",
"args": ["/path/to/wisdom-store/src/mcp-server/index.js"],
"env": {}
}
}
}Restart Claude Code or run /mcp to connect.
Copy the relevant sections from examples/CLAUDE.md into your project's CLAUDE.md. This teaches Claude when to load wisdom, save knowledge, check symbols, and manage context.
The hooks/ directory contains Claude Code hooks that integrate with wisdom-store automatically.
Add to your settings file — ~/.claude/settings.json (global), .claude/settings.json (project), or .claude/settings.local.json (personal per-project). Replace /path/to/wisdom-store with your actual clone path.
Automatically checks for hallucinations after every Write/Edit:
Import paths pointing to files that don't exist
Imported symbols not in the project registry
Standalone function calls to unknown symbols
API routes not found in the project index
Requires .wisdom/symbols.json — run get_project_overview once to generate it (auto-refreshes on each call). Only fires for code files (.js, .ts, .py, .go, .rs).
Reminds Claude to save important findings to wisdom-store before context gets compacted. Fires on both manual (/compact) and automatic compaction. Only fires in projects with a .wisdom/ directory.
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit",
"hooks": [{
"type": "command",
"command": "/path/to/wisdom-store/hooks/post-write-symbol-check.sh",
"timeout": 10
}]
},
{
"matcher": "Write",
"hooks": [{
"type": "command",
"command": "/path/to/wisdom-store/hooks/post-write-symbol-check.sh",
"timeout": 10
}]
}
],
"PreCompact": [
{
"matcher": "",
"hooks": [{
"type": "command",
"command": "/path/to/wisdom-store/hooks/pre-compact-save-reminder.sh",
"timeout": 10
}]
}
]
}
}Everything is flat files in a .wisdom/ directory at your project root:
.wisdom/
index.json # Project metadata + file list
symbols.json # Symbol registry (functions, classes, exports, routes)
sections/ # Knowledge organized by topic
auth.md
estimates.md
plans/ # Feature plans
v2-migration.md
patterns/ # Reusable patterns
error-handling.mdWisdom is stored at three levels:
Project — .wisdom/sections/, .wisdom/plans/, .wisdom/patterns/ for knowledge about this project
File-specific — Sidecar files next to source: myfile.js gets myfile.js.wisdom
Global — ~/.claude/wisdom/ for cross-project lessons (use scope: "global" with save_wisdom)
prune_context works by setting parentUuid: null on a target message in the JSONL conversation file, orphaning everything before it. This takes effect live on the next message — no restart needed.
inject_context appends a new message with parentUuid: null as a fresh root. Requires /resume to reload. A helper script (hooks/send-resume.sh) is included as a starting point for tmux automation, but manual /resume is the most reliable approach.
Uses @ast-grep/napi (tree-sitter based) for JavaScript/TypeScript/TSX. Extracts functions, classes, variables, exports, interfaces, types, enums. Regex fallback for Python, Go, and Rust.
The project overview is designed to be context-efficient — compact enough to fit in a single tool response while covering file tree, symbols, routes, and pages.
Running get_project_overview on this repo:
# Project Overview
## Files (16)
Total: 3,093 lines
- hooks/: symbol-check.mjs (273L)
- src/mcp-server/: index.js (371L)
- src/mcp-server/lib/: indexer.js (643L), jsonl.js (276L), wisdom.js (325L)
- src/mcp-server/tools/: check-symbols.js (87L), context-status.js (123L),
get-project-overview.js (58L), get-wisdom.js (179L), inject-context.js (177L),
list-wisdom.js (144L), prune-context.js (125L), refresh-symbols.js (15L),
reindex-project.js (92L), save-wisdom.js (106L), update-plan.js (99L)
## Symbols
Functions: 62, Classes/Types: 0, Exports: 40
### Exports
- appendLine — src/mcp-server/lib/jsonl.js:273
- checkSymbols — src/mcp-server/lib/indexer.js:543
- findConversationFile — src/mcp-server/lib/jsonl.js:30
- generateOverview — src/mcp-server/lib/indexer.js:450
- handleCheckSymbols — src/mcp-server/tools/check-symbols.js:24
- handlePruneContext — src/mcp-server/tools/prune-context.js:23
- scanProject — src/mcp-server/lib/indexer.js:50
- walkChain — src/mcp-server/lib/jsonl.js:160
... (40 exports total)1. Start working on a task
2. get_project_overview → understand the codebase
3. get_wisdom for relevant files/sections → load past knowledge
4. Work on the task
5. save_wisdom to persist new insights
6. check_symbols after writing code → catch hallucinations
7. If context gets large: save_wisdom → prune_context → continueLanguage | AST extraction | Regex fallback |
JavaScript (.js, .mjs, .cjs, .jsx) | Full | - |
TypeScript (.ts, .tsx) | Full | - |
Python (.py) | - | Functions, classes, methods |
Go (.go) | - | Functions, types, variables |
Rust (.rs) | - | Functions, structs, enums, traits |
HTML (.html) | - | Page titles, structure |
Node.js 18+
Claude Code (for MCP integration and hooks)
MIT
Add a comment or correction to existing wisdom. Use when you discover a previous assumption was wrong, needs clarification, or has new context. Annotations are timestamped and appended below the matching entry. Think of it as leaving a sticky note for future sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Text to search for within the wisdom file to place the annotation near. If omitted, appends to end. | |
| comment | Yes | The annotation to add (e.g. "Actually XYZ is wrong because...", "To clarify: you also need to...") | |
| section | No | Section name to annotate (writes to .wisdom/sections/<name>.md) | |
| file_path | No | File path whose sidecar to annotate (<file>.wisdom) |
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 notes that annotations are 'timestamped and appended below the matching entry,' which implies non-destructive behavior. However, it omits details on authorization, what happens if search fails, or potential side effects on the wisdom file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and contains no unnecessary words. It efficiently conveys the action, usage context, and behavioral metaphor.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 4 parameters, no output schema, and no annotations, the description covers the tool's purpose, usage timing, and basic behavior (timestamped append). It is reasonably complete for an agent to use correctly, though more detail on the non-required parameters' interaction (e.g., section vs file_path) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds minimal extra value, like explaining that search is used 'to place the annotation near' and giving an example for comment. Baseline 3 is appropriate as the description does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Add a comment or correction to existing wisdom,' which clearly identifies the verb and resource. It distinguishes from sibling tools like get_wisdom or save_wisdom by focusing on annotation, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: 'Use when you discover a previous assumption was wrong, needs clarification, or has new context.' It does not explicitly mention when not to use or alternatives, but the context is strong enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Back up your current Claude Code plan file to .wisdom/plan-backups/. Your plan name is in your plan mode system prompt (the filename in ~/.claude/plans/). Saves a timestamped copy so you can restore it later.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_name | Yes | The plan filename (e.g. "peppy-launching-book"). Found in your plan mode system prompt path. | |
| source_path | No | Optional full path to the plan file, if it is not in the default ~/.claude/plans/ directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains that a timestamped copy is saved for restoration, but does not disclose details like directory structure, overwrite behavior, or permission requirements. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple file backup tool, the description covers the action, location, and plan name source. It does not specify what the tool returns (e.g., backup path), but the tool is straightforward and the return value is likely a success message. It is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds context beyond the schema by explaining that plan_name is found in the system prompt and that source_path is optional for non-default locations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Back up' and resource 'plan file', clearly stating the action and target. It distinguishes from sibling tools such as 'update_plan' by focusing on backup rather than modification.
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 tells when to use the tool ('to back up your current Claude Code plan file') and how to find the plan name, but does not explicitly mention when not to use it or list alternative tools. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify symbol names you just used are real. Pass function/class/variable names and get back: confirmed (exists), fuzzy match (possible typo — did you mean X?), or unknown (might be hallucinated). Call this after writing code that references existing symbols, especially in unfamiliar parts of the codebase. Only reports problems — confirmed symbols are counted but not listed.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes | List of symbol names to check against the registry. | |
| verbose | No | If true, also list all known symbols. Default: false. | |
| project_path | No | Project root path. If omitted, auto-detects from cwd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the three output outcomes (confirmed, fuzzy match, unknown) and the counting behavior for confirmed symbols. No contradictions with annotations since none 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?
The description is three sentences, front-loaded with the core purpose, and every sentence adds value. No redundant or unnecessary 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 moderate complexity (3 parameters) and no output schema, the description adequately explains the tool's behavior and output categories. It covers the returned statuses and the counting of confirmed symbols. Some minor details like guaranteed read-only behavior are implied but not explicit, but overall it is complete enough.
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%, so baseline is 3. The description mentions passing 'function/class/variable names' which corresponds to the 'symbols' parameter, but adds no significant detail beyond the schema descriptions. Hence, it does not elevate the score.
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 verifies symbol names, specifying the verb 'verify' and the resource 'symbol names'. This distinguishes it from sibling tools like 'refresh_symbols' and 'reindex_project', which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises calling 'after writing code that references existing symbols, especially in unfamiliar parts of the codebase', providing clear context. It also explains the output behavior ('Only reports problems'), though it does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check how much context you have left. Shows message count, estimated token usage, and bloat indicators. Call this when starting a complex task or when you suspect context is getting large. If usage is >70%, consider pruning old messages with prune_context before continuing.
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | No | Conversation UUID. If omitted, finds the most recently modified conversation for the current project. Your conversation ID is shown in your status bar as [xxxxxxxx]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers key behaviors: read-only status check (implied by 'check'), and outputs message count, token usage, bloat indicators. No mention of side effects, but it's a non-destructive query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences plus conditional guidance. Every sentence provides necessary information without redundancy. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately hints at return values (message count, token usage, bloat indicators). It aligns with siblings and covers typical usage scenarios. Could be slightly more specific about 'bloat indicators' but overall comprehensive.
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 single parameter `conversation_id` is described with additional context: default behavior (most recent conversation) and how to find the ID from the status bar. Schema coverage is 100%, and the description adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to check context usage, including message count, token usage, and bloat indicators. It distinguishes itself from siblings like `prune_context`, which modifies 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?
Explicitly states when to use: 'when starting a complex task or when you suspect context is getting large.' Provides an alternative action with `prune_context` if usage exceeds 70%, offering clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a compact map of the project: file tree with line counts, all classes/types, and all exports. Call this early in a session to orient yourself in an unfamiliar codebase. Much cheaper than reading individual files. Auto-runs reindex_project if no index exists yet.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | No | Project root path. If omitted, auto-detects from cwd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It reveals the side effect of auto-running reindex_project if no index exists. However, it does not state whether the tool is read-only or if it requires specific permissions, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding distinct value: purpose, usage context, and behavioral note. No redundancy, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is sufficiently complete. It covers what, when, and a behavioral side effect, though a mention of output format would be nice.
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% for the single parameter 'project_path', so baseline is 3. The description adds context about session orientation but does not elaborate on parameter details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a compact map including file tree with line counts, classes/types, and exports. It also explicitly positions it as an orientation tool, distinguishing it from siblings like reindex_project or check_symbols.
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 advises calling it early in a session to orient oneself and notes it's cheaper than reading files. It does not explicitly state when not to use it or list alternatives, but the context of sibling tools provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load relevant wisdom before working on a file or area. Call with no args for a project overview, then drill into specifics. Recommended workflow: get_wisdom() overview → get_wisdom(file_path) for the files you are about to edit → get_wisdom(keyword) if you need to find related knowledge. This gives you accumulated project knowledge from previous sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Set to "overview" for compact project wisdom summary. | |
| plan | No | Get a specific plan by name. | |
| keyword | No | Search all wisdom for this keyword. | |
| section | No | Get wisdom for this project section. | |
| file_path | No | Get sidecar wisdom for this file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states 'Load relevant wisdom' but does not specify if it is read-only, if there are side effects, or what happens when no wisdom is found. This lack of transparency could lead to incorrect assumptions about its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with the main purpose stated first, followed by a structured workflow. The workflow list is clear but could be shortened without losing meaning. Overall, it is well-organized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema or annotations, the description adequately explains the intended usage but does not cover return value details or edge cases (e.g., multiple parameters, no results). It provides a good starting point but lacks completeness for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by showing how parameters fit into a workflow (e.g., using file_path and keyword in sequence), but it does not provide additional semantics beyond what the schema already offers.
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 loads wisdom and provides a workflow for using it. It specifies the resource (wisdom) and verb (load). However, it does not explicitly differentiate from sibling tools like get_project_overview, which may cause slight confusion.
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 a clear recommended workflow: overview first, then drill down by file path, then search by keyword. This gives explicit guidance on when to use different parameter combinations. It does not mention when not to use the tool or alternatives, but the workflow is instructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inject curated context into the conversation as a new branch. Use to restore important context after pruning or to seed a session with relevant knowledge. Auto-triggers /resume via the dashboard if available. Keep injected content natural-sounding — avoid markers like [INJECTED] that trigger prompt injection detection.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The context to inject. Should be natural-sounding (avoid markers like [INJECTED] that trigger prompt injection detection). Can be formatted as pasted text, MCP responses, or conversation summaries. | |
| session | No | Tmux session name to send /resume to. If omitted, looks up by conversation ID via dashboard. | |
| prune_orphans | No | If true, delete orphaned messages after injection to reduce file size. Default: false. | |
| conversation_id | No | Conversation UUID. If omitted, finds the most recently modified conversation for the current project. Your conversation ID is shown in your status bar as [xxxxxxxx]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that injection auto-triggers /resume via dashboard and warns against trigger markers. Missing details on permissions, side effects, or reversibility.
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 four sentences, all substantive. It front-loads purpose, then gives usage context, a behavioral trait, and a warning. No redundant or 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?
Given the tool's 4 parameters and no output schema, the description covers purpose, usage, behavioral traits, and parameter tips comprehensively. It answers likely questions about when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, setting a baseline of 3. The description adds value by elaborating on each parameter: natural-sounding content, session fallback behavior, prune_orphans effect, and how to find conversation_id. This goes beyond the schema definitions.
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 injects context into the conversation as a new branch, with specific use cases: restoring after pruning or seeding a session. It distinguishes its purpose from sibling tools like prune_context and context_status.
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 'when to use' guidance (after pruning, to seed knowledge) and a warning about prompt injection detection. However, it does not explicitly state when not to use or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse what wisdom exists in the project. Filter by: all, sections, plans, patterns, sidecars, or global.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | What to list. Default: all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly indicates a read-only browse operation with no side effects, which is adequate for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main action. It could be slightly more structured (e.g., separating purpose and options), but it is concise without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and no annotations, the description adequately covers the tool's purpose and filter options. It does not detail return format, but that is acceptable for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents the filter parameter. The description essentially repeats the enum values, adding little new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses wisdom in the project, with a specific verb and resource. It lists distinct filter options, distinguishing it from siblings like get_wisdom and save_wisdom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing wisdom but provides no explicit guidance on when to use this tool versus alternatives like get_wisdom or annotate_wisdom. Contextual cues are minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free up context by trimming old messages. Works live without restart. Use when context_status shows >70% usage. Before pruning, save any important findings with save_wisdom so they survive the trim. Typical workflow: save_wisdom → prune_context(mode:"oldest_percent", percent:40) → continue working with more room.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Pruning mode: "before_message" trims before a specific message number, "oldest_percent" trims the oldest N% of messages, "after_phrase" finds a message containing a unique phrase and makes it the new root. | |
| phrase | No | For after_phrase mode: a unique phrase to search for in the conversation. The first message containing this phrase becomes the new root, everything before it is orphaned. | |
| percent | No | For oldest_percent mode: trim this percentage of messages from the beginning (0-100). | |
| message_number | No | For before_message mode: trim everything before this message (1-indexed from chain start). The target message becomes the new root. | |
| conversation_id | No | Conversation UUID. If omitted, finds the most recently modified conversation for the current project. Your conversation ID is shown in your status bar as [xxxxxxxx]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states 'works live without restart' and warns to save important findings with save_wisdom to survive the trim. However, it does not mention whether pruning is reversible or how the response indicates success.
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 and a workflow example efficiently convey purpose, usage, and mode options. No redundant information; every sentence serves a purpose. Could be slightly improved by listing modes more compactly, but it's well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description explains the three pruning modes but omits what the tool returns (e.g., success confirmation, new context size). The workflow example is helpful, but the lack of return value information is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds a concrete example (percent:40) but does not enrich understanding beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: freeing context by trimming old messages. It distinguishes itself from sibling tools like 'context_status' (which only shows usage) and 'save_wisdom' (which preserves info), making its unique role evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using when 'context_status shows >70% usage' and provides a typical workflow: save_wisdom → prune_context → continue working. It does not explicitly exclude scenarios (e.g., before critical operations), but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-scan the project and update the symbol registry. Run this after you have made code changes (added/renamed/removed functions) so that check_symbols works against the latest codebase state.
| Name | Required | Description | Default |
|---|---|---|---|
| max_depth | No | Max directory depth to scan. Default: 8. | |
| max_files | No | Max files to scan. Default: 2000. | |
| project_path | No | Project root path. If omitted, auto-detects from cwd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so burden is on description. It states the tool updates the symbol registry but does not describe any side effects, performance implications, or return behavior. Adequate for a simple update 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?
Two sentences with no wasted words. Essential information is front-loaded: what it does and when to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple registry update with optional parameters, the description is complete enough. Could mention return value but not critical given no 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?
Input schema has 100% coverage with descriptions for all 3 parameters. The description adds no additional context about parameters, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool re-scans the project and updates the symbol registry. It mentions the specific use case after code changes and references check_symbols, but does not explicitly differentiate from other siblings like reindex_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to run after making code changes so that check_symbols works. Provides clear context for when to use, though does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build or refresh the project symbol index. Extracts all functions, classes, variables, and exports using AST parsing (JS/TS) or regex (Python/Go/Rust). Run this when starting work on a project for the first time, or after significant code changes. The index powers check_symbols and get_project_overview. Fast: ~350 files in under 2 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| max_depth | No | Max directory depth to scan. Default: 8. | |
| max_files | No | Max files to scan. Default: 2000. | |
| project_path | No | Project root path. If omitted, auto-detects from cwd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses parsing mechanism (AST/regex per language) and performance metric (~350 files/2s). Missing details on side effects (overwrite behavior), authorization needs, or whether the index persists.
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 well-structured sentences: action, usage context, and dependencies+performance. No redundant information; 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 simple input schema (3 optional params) and no output schema, the description covers purpose, when to run, and what it powers. Minor gap: does not explain return value or post-index state, but not critical for a setup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions with defaults. The tool description does not add new semantic meaning beyond what the schema provides (e.g., no explanation of how max_depth affects scope). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool builds or refreshes a project symbol index and lists extracted elements (functions, classes, variables, exports) with parsing methods. However, it does not explicitly differentiate from sibling tool 'refresh_symbols', which may cause confusion.
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 guidance on when to use: 'when starting work on a project for the first time, or after significant code changes'. Mentions dependents (check_symbols, get_project_overview) but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request context compaction for your session. Sends /compact to your tmux session via the dashboard — it executes after your current turn completes. Use when context is getting large and you want to compact proactively. Save important findings with save_wisdom first, as compaction summarizes and trims conversation history. Requires DASHBOARD_URL env var.
| Name | Required | Description | Default |
|---|---|---|---|
| session | No | Tmux session name. If omitted, looks up by conversation ID via dashboard. | |
| conversation_id | No | Conversation UUID. If omitted, auto-detects from the current project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: async execution (after turn), destructive effect (summarizes and trims history), and environment prerequisite (DASHBOARD_URL). Could mention reversibility or error handling, but sufficient.
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 concise sentences, front-loaded with action and mechanism. No unnecessary words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, description covers purpose, usage, behavior, and prerequisites. Lacks return value or error info, but acceptable for an async trigger tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds fallback behavior for both parameters (lookup by conversation ID, auto-detect), enhancing understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly defines the action (request compaction), resource (session), mechanism (sends /compact via dashboard), and timing (after current turn). Differentiates from sibling tools like prune_context and save_wisdom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (context getting large, proactive) and important precaution (save important findings with save_wisdom first). Provides clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a lesson, pattern, caution, edge case, or decision so future sessions can benefit. Save when you discover something non-obvious: a tricky bug, an important constraint, a pattern that works well, or a decision rationale. Use file_path for file-specific wisdom (creates sidecar), section for broader project area knowledge, or scope:"global" for cross-project patterns. Keep entries concise and actionable — future you will thank present you.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Scope: "project" (default) or "global" (cross-project, saved to ~/.claude/wisdom/). | |
| content | Yes | The wisdom to save. Should be concise and actionable. | |
| section | No | Project section name (writes to .wisdom/sections/<name>.md). | |
| keywords | No | Keywords for indexing. Helps palette find this wisdom later. | |
| file_path | No | File to attach wisdom to (creates <file>.wisdom sidecar). | |
| wisdom_type | No | Type of wisdom. Default: lesson. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses creation of sidecar files, project sections, and global storage location. Could mention overwrite behavior or return value, but overall effective.
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 concise sentences cover purpose, usage context, and parameter selection. No unnecessary words; 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 absence of output schema and the simple create operation, the description is sufficiently complete. It explains what the tool does and how to use it, though it omits return value details.
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%, but description adds value by explaining the purpose of each parameter grouping (file_path, section, scope) and examples like 'scope:"global"'. Enhances usability beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Persist' and the resource 'wisdom', listing specific types (lesson, pattern, caution, edge case, decision). It distinguishes from sibling tools like get_wisdom and list_wisdom by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (non-obvious discoveries) and how to choose between file_path, section, and scope. Lacks explicit 'when not to use' or direct alternatives, but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Document a feature plan so future sessions understand what was built and why. Include files it touches, design decisions, and current status. Update existing plans when you complete or change direction on a feature. Plans are stored in .wisdom/plans/ and cross-referenced in the project index.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Plan name (will be slugified for filename). | |
| files | No | Files this plan touches. | |
| status | No | Plan status. | |
| content | No | Full plan content (markdown). If provided, replaces the entire plan file. | |
| replace | No | If true, replace existing plan entirely. Default: false (merge/append). | |
| sections | No | Sections this plan belongs to. | |
| decisions | No | Design decisions made for this plan. | |
| description | No | Plan description (used when building from fields, not full content). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses replace vs merge behavior and storage location. No annotations exist, so description carries burden. Missing details on permissions, side effects, or error cases, but sufficient for basic understanding.
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?
Single paragraph that is informative but slightly verbose. Could be more structured, but every sentence adds value and purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, description covers purpose, behavior, storage, and cross-referencing. Lacks return value or error details, but overall adequate.
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%, so baseline is 3. Description adds context like slugification of name and default replace behavior, but does not substantially enhance parameter understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: documenting feature plans, including files, decisions, and status. It specifies both creation and update, and distinguishes from siblings by focusing on plan management.
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 guidance on when to use ('Update existing plans when you complete or change direction on a feature'). Does not explicitly mention when not to use or compare with siblings like save_wisdom or backup_plan, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0annotate_wisdombackup_plancheck_symbolscontext_statusget_project_overviewget_wisdominject_contextlist_wisdomprune_contextrefresh_symbolsreindex_projectrequest_compactsave_wisdomupdate_planEach tool has a clearly distinct purpose: wisdom management, plan management, symbol operations, context control, and project overview. No two tools overlap significantly.
Most tools follow a verb_noun pattern (e.g., save_wisdom, list_wisdom, check_symbols). A few like context_status are noun_noun but still readable and consistent in using lowercase snake_case.
14 tools is well-scoped for the server's purpose. Each tool serves a specific need without being excessive or insufficient.
The tool surface covers core operations for wisdom (CRUD except delete), plans (backup and update), symbols (check, refresh, reindex), and context (status, prune, inject, compact). Minor gaps like a delete-wisdom tool exist, but annotations compensate.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Gives your AI assistant persistent memory and intelligence about your work patterns.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Project memory, semantic code search, and grounded agent context.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/InfiniQuest-App/wisdom-store'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
