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., "@Kratos MCP remember that our authentication uses JWT"
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.
Never explain your codebase again. Let AI remember everything.
github.com/ceorkm/kratos-cliKratos is now a standalone CLI — faster, lighter, works with ANY AI agent.
No MCP overhead. No vendor lock-in. Just memory that works.
npx kratos-memoryClaude Code, Codex, Cursor, Cline — anything that runs Bash.
Your existing memories work instantly. Same ~/.kratos/ storage, same SQLite format.
Go to Kratos CLI >Related MCP server: LumenCore
After building 30+ production apps with AI, we discovered a critical problem: AI tools forget everything between sessions. You explain your architecture, your patterns, your decisions—and tomorrow, you explain it all again.
Kratos MCP solves this with an ultra-lean memory system that gives AI perfect recall of your project—with minimal context overhead.
Each project gets its own SQLite database. No cross-contamination. Ever.
Auto-detects projects via git, package.json, or directory structure. Just install and code.
Just 12 essential tools. 64% smaller context footprint than competitors.
Works with Claude, Cursor, Windsurf, Continue—any MCP-compatible tool.
# Install globally
npm install -g kratos-mcp
# Or run directly with npx (no installation required)
npx kratos-mcp
# Or install as a dependency
npm install kratos-mcpAdd to your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/claude/claude_desktop_config.json
{
"mcpServers": {
"kratos": {
"command": "npx",
"args": ["--yes", "kratos-mcp@latest"]
}
}
}Or if you have it installed globally:
{
"mcpServers": {
"kratos": {
"command": "kratos-mcp",
"args": []
}
}
}Run this command in your terminal:
claude mcp add kratos -- npx --yes kratos-mcp@latestOr for global installation:
# First install globally
npm install -g kratos-mcp@latest
# Then add to Claude Code
claude mcp add kratos -- kratos-mcpAdd to .cursor/mcp_config.json in your project root:
{
"mcpServers": {
"kratos": {
"command": "npx",
"args": ["--yes", "kratos-mcp@latest"]
}
}
}Kratos works with any tool supporting the Model Context Protocol. The general format is:
{
"command": "npx",
"args": ["kratos-mcp"]
}Compatible with: Windsurf, Cline, BoltAI, Augment Code, Roo Code, Zencoder, Amazon Q, Qodo Gen, JetBrains AI, Warp, Opencode, Continue.dev, Zed, and more!
Check your tool's documentation for specific MCP server configuration location.
// Your AI now remembers:
// - Your authentication patterns
// - Your API structure
// - Your component architecture
// - Your coding standards
// - Every decision you've madeKratos provides 12 ultra-lean tools optimized for minimal context consumption:
Tool | Description |
| Store important project knowledge with tags, paths, and importance levels |
| Smart semantic search with debug mode and path matching |
| Natural language queries about your memories |
| Get recently created memories with filtering |
| Retrieve a specific memory by ID |
| Bulk retrieve multiple memories |
| Delete a memory by ID |
Tool | Description |
| Scan text for PII and secrets before saving |
Tool | Description |
| Switch between different projects |
| Get current active project info |
| Dynamically change storage location with automatic data migration |
Tool | Description |
| Get system status and memory statistics |
AI Tool ──► Kratos MCP ──► Project Detection ──► SQLite + FTS5 ──► Perfect ContextSQLite + FTS5: Lightning-fast full-text search
Smart Scoring: Path matching + recency + importance
Auto-detection: Git, package.json, or directory-based
Secure: All data stays local, no external calls
Lean: Only 4 core components, minimal memory footprint
Metric | Value |
Context Overhead | 64% smaller than v3 |
Memory Retrieval | < 10ms |
Project Switch | < 100ms |
Storage Overhead | ~2MB per project |
~/.kratos/
├── projects/
│ ├── project-id-1/
│ │ └── memories.db # SQLite database with FTS5
│ └── project-id-2/
│ └── memories.db
└── global/
└── global.db # Shared knowledge (optional)Use change_storage_path to move data to custom locations like /opt/kratos or .kratos for per-project storage.
// Save a memory
await memory_save({
summary: "JWT auth implementation",
text: "We use httpOnly cookies with refresh tokens...",
tags: ["auth", "security"],
paths: ["src/middleware/auth.ts"],
importance: 5
});
// Search memories
await memory_search({
q: "authentication",
k: 5,
debug: true
});
// Ask natural language questions
await memory_ask({
question: "How does our auth system work?",
limit: 10
});git clone https://github.com/ceorkm/kratos-mcp.git
npm install
npm run build
npm run devMIT
Built for developers who value their time.
Dynamically change where Kratos stores data (with automatic migration)
| Name | Required | Description | Default |
|---|---|---|---|
| newPath | Yes | New storage path (e.g., "/opt/kratos" or ".kratos") | |
| migrate | No | Migrate existing data to new location (default: true) | |
| backup | No | Create backup before migration (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions automatic migration but omits potential side effects like downtime, permission requirements, or whether the change is immediate or requires restart. The description is too brief to be transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key action and feature (automatic migration). Every word serves a purpose; no fluff.
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?
No output schema exists, so the description should explain what the tool returns or confirms (e.g., success message, errors). It does not. Also missing context about prerequisites like running Kratos or admin rights.
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 parameters are already well-documented. The description adds no additional meaning beyond the schema. 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?
The description clearly states the tool's purpose: dynamically changing the storage path for Kratos with automatic migration. The verb 'change' and resource 'storage path' are specific. No sibling tool has similar functionality, so distinction is inherent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description does not mention prerequisites, scenarios, or when not to use it. Being the only storage-related tool implies uniqueness but the description lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask questions about your memories using natural language
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Natural language question about your memories | |
| limit | No | Max results to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers no behavioral disclosure. No mention of read-only nature, data privacy, rate limits, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence is concise but lacks structure. No front-loading of key info beyond a generic verb-noun phrase.
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 simple parameters and no output schema, the description fails to specify what the tool returns, how to phrase effective questions, or any constraints (e.g., time range). Incomplete for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds minimal extra meaning beyond 'using natural language' for question parameter. Baseline 3 is appropriate as it does not significantly enrich parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool allows asking questions about memories using natural language, which distinguishes it from siblings like memory_search (likely keyword-based) and memory_get (by ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other memory tools, such as when to use memory_get or memory_search instead. Lacks context about appropriate scenarios or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a memory by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Memory ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It states 'Delete' (destructive) but provides no details on consequences, error handling, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no redundancy. Efficient front-loading of 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?
Adequate for a simple delete tool, but lacks context on behavior for invalid IDs or side effects. No output schema, so description could outline return value 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?
Schema already fully describes the 'id' parameter as 'Memory ID to delete'. Description adds no new meaning; baseline 3 applies as schema coverage is 100%.
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 action ('Delete') and resource ('a memory by ID'), directly distinguishing it from sibling tools like memory_get (read), memory_save (create/update), and memory_search (query).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., memory_save or memory_get). Does not specify prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific memory by ID with full text
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Memory ID to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only adds 'with full text', which implies a behavior but doesn't explain safety, authentication, or side effects. More context is needed for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every part of the sentence adds value and is directly relevant to the tool's 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?
For a simple retrieval tool with one parameter and no output schema, the description provides basic understanding. However, it lacks details on return format or how 'full text' differs from other retrieval tools, leaving gaps in 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% with a single parameter 'id' described as 'Memory ID to retrieve'. The tool description adds no extra meaning beyond the schema, but per rules, high coverage justifies a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('a specific memory'), and the key qualifier ('by ID with full text'). It effectively distinguishes from siblings like memory_get_multiple and memory_get_recent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., memory_get_recent for recent memories or memory_search for query-based retrieval). The agent is left to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get multiple memories by IDs with full text (bulk operation)
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Array of memory IDs to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only mentions 'full text' but omits read-only indication, error handling, or any side effects. The tool is likely safe (read), but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the action and object. However, it is slightly too terse, missing optional clarifications.
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 and a single parameter, the description is minimally sufficient. However, it lacks details on return format, behavior for invalid IDs, and does not leverage sibling context to clarify differences.
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 tool description adds 'by IDs' and 'full text' but does not enhance the parameter meaning beyond what the schema already provides ('Array of memory IDs').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get'), the resource ('memories by IDs'), and specifies 'full text' and 'bulk operation', distinguishing it from siblings like memory_get (likely single) and memory_get_recent.
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 bulk retrieval by IDs but does not explicitly state when to use this tool over memory_get or memory_get_recent. No alternatives or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent memories from active project
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Max results | |
| path_prefix | No | Filter by path prefix | |
| include_expired | No | Include expired memories |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits like read-only nature, authentication needs, rate limits, or side effects beyond the implied '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?
Single concise sentence, front-loads key information with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal description for a tool with 3 optional parameters and no output schema. Lacks clarity on how 'recent' is defined or what 'active project' means. Adequate but could be more 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?
Input schema has 100% parameter description coverage. Description adds no extra meaning beyond schema; 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?
The description clearly states 'Get recent memories from active project', specifying the verb (get), resource (memories), and scope (recent, active project). It distinguishes from siblings like memory_get (generic) and memory_search (search-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., memory_get, memory_search). No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a memory document to the active project
| Name | Required | Description | Default |
|---|---|---|---|
| summary | Yes | Short, 1-2 line summary | |
| text | Yes | Full memory content | |
| tags | No | Tags for categorization | |
| paths | No | File/directory paths (globs) | |
| importance | No | Importance level | |
| ttl | No | Time to live in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'save', which implies writing, but lacks details on side effects (e.g., overwriting, creation vs update), required permissions, or idempotency. This is insufficient for an agent to reason about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. It is appropriately front-loaded. However, it is perhaps too terse, missing opportunities to convey useful details without significant bloat.
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 should compensate by explaining return behavior or integration with the project. It does not mention what happens after saving (e.g., confirmation, error conditions), leaving the agent with an incomplete picture of the tool's effect.
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 6 parameters are described in the input schema (100% coverage), so the schema already documents their meaning. The tool description adds no extra semantic value beyond the schema. Baseline score of 3 is appropriate as the description does not detract but also does not enhance.
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 'Save' and the resource 'memory document to the active project', making the core action unambiguous. However, it does not differentiate from sibling tools like memory_ask or memory_forget, which limits its distinctiveness.
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 offers no guidance on when to use this tool over alternatives. There is no mention of prerequisites, context, or conditions where this tool is appropriate, leaving the agent without decision-support information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search memory documents in the active project
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query | |
| k | No | Max results to return | |
| require_path_match | No | Require path matching | |
| tags | No | Filter by tags | |
| include_expired | No | Include expired memories | |
| debug | No | Include debug information about search process | |
| scope | No | Search scope: project (default), global concepts, or all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not mention behavioral traits such as whether it is read-only, performance implications, or any side effects. For a search tool, basic transparency is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks critical information to be fully effective. It earns its place but is overly minimal.
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?
With 7 parameters and no output schema or annotations, the description is insufficient. It does not explain return format, scope behavior, or how parameters like 'debug' affect results.
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 covers 100% of parameters with descriptions. The tool description adds no extra meaning beyond stating the general purpose, 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 action ('Search') and resource ('memory documents'), and specifies scope ('in the active project'). However, it doesn't differentiate from siblings like memory_ask or memory_get, and the scope parameter allows 'global' or 'all', which is not reflected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., memory_ask for question answering, memory_get for exact retrieval). No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current active project
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description merely states 'Get', implying read-only, but lacks details on side effects, prerequisites, or return format. For a tool with no annotations, the description should compensate with more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four words, extremely concise. Every word is meaningful with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is minimally complete but could mention the expected return type (e.g., project object) or context (e.g., current project path).
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?
Tool has zero parameters and schema coverage is 100%. Description adds no param info but baseline for 0 params is 4. It adequately communicates the operation.
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 'Get current active project' is a specific verb+resource pair. It clearly distinguishes from sibling tools like project_switch, which switches projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it could mention that it requires no parameters and is used to retrieve the currently active project, whereas project_switch changes the active project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch to a different project
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path to project directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action without explaining effects on subsequent operations, required permissions, or side effects. For a state-changing tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It is front-loaded and efficient, though it could be slightly expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter), the description is adequate but lacks behavioral context such as the effect on subsequent tool calls. Output schema is absent, but not critical here.
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 one parameter 'project_path' described. The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Switch to a different project' uses a specific verb and resource, making the purpose clear. It distinguishes from siblings like project_current, which retrieves current project, and other tools. However, it lacks additional detail on scope or 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?
No guidelines are provided on when to use this tool versus alternatives such as change_storage_path or project_current. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan text for PII and secrets
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to scan | |
| redact | No | Return redacted version |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'scan,' which implies a read operation, but does not disclose whether the tool modifies data, the scope of detection, or side effects. No annotations exist to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description is adequate but lacks detail on what constitutes PII/secrets or how scanning works. More context 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 both parameters. The description adds minimal context ('PII and secrets') but does not explain parameter interactions or formats beyond 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 scans text for PII and secrets, using a specific verb and resource. It distinguishes itself from sibling tools like memory_get or system_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?
No guidance is provided on when or when not to use this tool, such as prerequisites or alternatives. Sibling tools are unrelated, but the description offers no contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get system status and statistics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects (e.g., read-only, auth needs). The word 'Get' implies safety, but transparency beyond that is minimal for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 7 words with no extraneous content. Every word 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 no parameters or output schema, the description covers the basic purpose but omits details about return format or statistics included. Additional context on output 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% with zero parameters, baseline 3 applies. The description adds no parameter information because there are none.
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 'Get system status and statistics' clearly uses a specific verb and resource, distinguishing it from sibling tools like memory and project tools. No ambiguity exists.
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 use for system status, but lacks explicit guidance on when to use vs alternatives or prerequisites. No alternatives are mentioned, which is acceptable given uniqueness, but exclusion criteria are absent.
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.
v4.1.1change_storage_pathmemory_askmemory_forgetmemory_getmemory_get_multiplememory_get_recentmemory_savememory_searchproject_currentproject_switchsecurity_scansystem_statusScored across 12 tools
Most tools have distinct purposes, but memory_get and memory_get_multiple are closely related, and memory_ask could be conflated with memory_search if not careful. Overall, boundaries are clear.
All tool names follow a consistent verb_noun pattern in snake_case, making them predictable and easy to navigate.
With 12 tools, the set is well-scoped for a memory and project management system, neither too sparse nor overwhelming.
Missing a memory update tool and project listing capability. The set covers core CRUD for memories but lacks lifecycle operations for projects and explicit memory updates.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Universal memory for AI agents and tools. Save, organize and search context anywhere.
Project memory, semantic code search, and grounded agent context.
Project memory for coding agents: requirements, decisions, code graph and delivery telemetry.