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., "@OCD - Organized Context Datastore (MCP) Store the current architecture decisions as a new context branch"
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.
Give your AI persistent, structured memory — and let humans see it too.
OCD is an MCP server that stores project knowledge as Markdown files in a hierarchical tree. LLMs read and write via MCP tools; humans browse and edit via a built-in Web UI or any text editor. Both share the same source of truth.
No more lost context — Project knowledge persists across sessions in a Git-backed store
Token-efficient — Fetch only the branches you need with tree-text format, not entire documents
Human-friendly — Plain Markdown + frontmatter. Edit in VS Code, review on GitHub, or use the built-in Web UI
One command — npx github:teamstove/organized-context-datastore-mcp starts both the MCP server and the Web UI
# Cursor connects via stdio + humans browse http://localhost:38291/viewer
npx github:teamstove/organized-context-datastore-mcp
# Read-only mode
npx github:teamstove/organized-context-datastore-mcp --readonly# Local dev mode (with Web UI)
npx github:teamstove/organized-context-datastore-mcp --http --port 38291
# Remote server mode
npx github:teamstove/organized-context-datastore-mcp --http --mode remote-server --config ./config.jsonRelated MCP server: agent-memory
┌──────────────┐ MCP (stdio / HTTP) ┌─────────────────┐
│ LLM / IDE │ ◄───────────────────► │ OCD Server │
│ (Cursor…) │ │ │
└──────────────┘ │ Markdown files │
│ + frontmatter │
┌──────────────┐ HTTP + Web UI │ + Git history │
│ Human │ ◄───────────────────► │ │
│ (Browser) │ └─────────────────┘
└──────────────┘For LLMs | For Humans |
Persistent memory across sessions | Plain Markdown — edit anywhere |
Hierarchical tree with pattern queries | Built-in Web UI with tree view & search |
Token-efficient | Git-backed history & diffs |
6 MCP tools: list, get, tree, search, mutate, commit | Review and refine what the AI writes |
Option | Description |
(none) | stdio mode (default) + Web UI on port 38291 |
| HTTP server mode |
| Disable write tools |
| HTTP port number (default: 38291) |
| Web UI port in stdio mode (default: 38291) |
| Disable the Web UI |
| HTTP only: |
| Config file for |
Duplicate launch behavior: If OCD is already running on the same port, subsequent launches log "OCD is already running on this port" and exit cleanly (exit 0). An error exit only occurs when the port is occupied by a different process. The server identity check uses GET /whois — if the response is OCD, it is recognized as an existing OCD instance.
Run read/write operations without starting the MCP server. Results are printed as JSON on stdout (pipe to jq, etc.).
ocd-mcp tool --help
ocd-mcp tool --cwd . list-roots
ocd-mcp tool --cwd . get-contexts --patterns 'docs/**'
ocd-mcp tool --cwd . search --query "auth"Context | Flag | Meaning |
Project (usual) |
| Resolve |
Fixed storage |
|
|
--readonly: blocks mutate and commit.
Do not run mutate / commit against the same Git repo while the stdio MCP server is writing — risk of lock/conflict.
get-contexts --include-content can produce very large JSON.
{
"mcpServers": {
"ocd-mcp": {
"command": "npx",
"args": [
"--package", "github:teamstove/organized-context-datastore-mcp",
"tsx", "src/cli.ts"
]
}
}
}Cursor connects via stdio
Humans browse http://localhost:38291/viewer
"args": [
"--package", "github:teamstove/organized-context-datastore-mcp",
"tsx", "src/cli.ts",
"--disable-web-ui"
]{
"mcpServers": {
"ocd-mcp": {
"command": "npx",
"args": ["github:teamstove/organized-context-datastore-mcp"]
}
}
}# Start the server in a terminal
npx github:teamstove/organized-context-datastore-mcp --http --port 38291{
"mcpServers": {
"ocd-mcp": {
"url": "http://localhost:38291/api/mcp"
}
}
}Web UI is available at http://localhost:38291/viewer.
{
"mcpServers": {
"ocd-pj-alpha": {
"url": "http://localhost:38291/api/mcp?roots=project-alpha,core-docs"
},
"ocd-pj-beta-readonly": {
"url": "http://localhost:38291/api/mcp?roots=project-beta,shared&readonly=shared"
}
}
}Parameter | Description | Example |
| Context Root IDs to include (comma-separated) |
|
| Context Root IDs to make read-only |
|
.ocd.config.js)Place in the project root. OCD searches upward from cwd automatically.
export default {
contextRoots: [
{
path: './organized-context',
git: 'auto-commit'
},
{
path: './CORE/docs',
name: 'CORE Docs',
readOnly: true
}
],
inheritGlobal: true
}~/.ocd/config.js)Define Context Roots shared across all projects.
Value | Description |
| Automatically commit after each operation |
| Commit explicitly via the |
| Do not use Git |
Tool | Description |
| List all Context Roots |
| Retrieve contexts by pattern and filters |
| Get the context tree (table of contents) |
| Search contexts by keyword |
| Mutate a context (create / update / delete / move) |
| Commit changes (for |
Serialization: Within the same Context Root (same cwd), ocd_mutate_context and ocd_commit execute one at a time. When called in rapid succession, subsequent calls wait for the previous one to complete — this is a queue, not a freeze. This prevents Git operation conflicts.
Move cost: A move operation scans all .md files under the Context Root to update internal links and prevent broken references. If the root contains many files, a single move may take noticeable time.
my-context-store/
├── .ocd.config.js
├── project-a/
│ ├── index.md
│ ├── features/
│ │ ├── feature-1.md
│ │ └── feature-2.md
│ └── decisions/
│ └── adr-001.md
└── project-b/
└── ...---
title: Feature Specification
status: draft
priority: high
---
# User Authentication
## Overview
Details about the user authentication implementation...All frontmatter fields other than title are treated as attrs.
git clone https://github.com/teamstove/organized-context-datastore-mcp.git
cd organized-context-datastore-mcp
npm installThe Web UI is built automatically on first launch. To build manually: npm run build:web-ui.
See docs/DEVELOPMENT.md for local development, testing, and build instructions.
MIT
[OCD] 変更をコミット (git: 'manual' モード用)（cwd から設定を探索）
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | 作業ディレクトリ（設定探索の起点） | |
| paths | No | 対象パス (省略時は全変更) | |
| message | Yes | コミットメッセージ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states 'commit changes' and 'search settings from cwd' but does not mention side effects (e.g., whether it pushes, stages, or rewrites history), nor does it explain what 'manual mode' entails or any required permissions. For a mutation tool, this is insufficient transparency.
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 that front-loads the action and context. It contains no redundant words or filler, making it highly concise and 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?
The tool is reasonably simple (commit with 3 params), and the description conveys the core intent. However, it omits important contextual details such as what 'manual' mode means, the effects of committing (e.g., does it also push?), and how it relates to the sibling context tools. It is minimally viable but not fully 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 description coverage is 100%, so the baseline is 3. The description adds no meaningful parameter semantics beyond the schema; the phrase 'cwd から設定を探索' merely restates the cwd parameter's existing description. No extra insight on 'paths' or 'message' is provided.
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: '変更をコミット' (commit changes). It specifies the resource (git) and mode ('manual' モード用), and the scope (cwd-based settings search). It distinguishes from sibling context tools by using the verb 'commit'.
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 phrase '(git: 'manual' モード用)' provides clear context on when to use the tool: in manual git mode. It implies this is the explicit commit action as opposed to automatic modes. However, it does not name alternatives or provide exclusions beyond this implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[OCD] Organized Context Datastore - 階層構造を持つコンテキストを LLM と人間が共同で読み書きする MCP サーバー。
パターンとフィルタでコンテキストを取得します。
patterns: glob パターン配列 (例: ['project/**', 'docs/*'])
filter: jq フィルタ式 (例: '.attrs.status == "draft"')
includeContent: コンテンツを含めるか (default: true)
cwd: 作業ディレクトリ（設定探索の起点）
attrs でフィルタ: '.attrs.status == "draft"'
未完了TODOがあるもの: '.todos | any(.completed == false)'
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | 作業ディレクトリ（設定探索の起点） | |
| filter | No | jq フィルタ式 (例: '.categories | any(. == "feature-spec")') | |
| patterns | Yes | Context Root の rootPath で始まる glob パターン配列 (例: ["knowledge-base/**", "src/plugins/*"]) | |
| includeContent | No | コンテンツを含めるか (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the includeContent default and cwd usage for config discovery, but does not explicitly state read-only behavior, return format, or potential side effects. As a 'get' tool, read-only is implied, but lacking explicit disclosure and output details limits transparency.
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 well-organized with a brief intro, parameter list, and jq filter examples. It is moderately sized and front-loaded, though some content (the jq examples) is example-oriented and could be trimmed without losing core meaning.
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 no output schema, the description should explain what the tool returns, but it does not describe the response structure or content. It covers parameter usage thoroughly but omits return value semantics, leaving agents uncertain about what to expect when calling 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%, providing baseline 3. The description adds value by giving concrete examples for patterns (['project/**', 'docs/*']) and filter ('.attrs.status == "draft"') and clarifying the default for includeContent. This enriches the parameter semantics 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 states 'パターンとフィルタでコンテキストを取得します' (retrieves contexts with patterns and filters), which clearly identifies the operation as a retrieval using specific mechanisms. This distinguishes it from siblings like ocd_get_context_tree (tree retrieval) and ocd_search_contexts (search), though it doesn't explicitly name them.
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 through examples of patterns and filters, but does not explicitly state when to use this tool versus alternatives. No exclusions or alternative recommendations are provided, leaving the agent to infer the appropriate context from the description and tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[OCD] コンテキストツリー(目次)を取得
rootIds: Context Root の id 配列（list_context_roots で取得した id をそのまま使用）
patterns (optional): include glob（rootId 相対）。指定時は depth より優先
exclude (optional): exclude glob（rootId 相対）。tree から除外
重要: list_context_roots で返却された id を使用してください。 path フィールド（実際のファイルシステムパス）は使用しないでください。
例:
単一: rootIds: ["tairikut-docs"]
複数: rootIds: ["tairikut-docs", "CORE-docs-for-ai"]
tree-text (default): Token効率の良いテキストツリー形式
json: 従来のJSON配列形式
デフォルト: "$path: $title $summary" 使用可能な変数: $path, $title, $summary
cwd: 作業ディレクトリ（設定探索の起点）
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | 作業ディレクトリ（設定探索の起点） | |
| depth | No | 深さ制限 (省略時は全階層) | |
| format | No | 出力形式 (default: 'tree-text') | |
| exclude | No | exclude glob patterns (rootId 相対)。指定したパスを結果から除外（glob の ignore に変換） | |
| rootIds | Yes | Context Root の id 配列（list_context_roots で取得した id をそのまま使用） 例: ["tairikut-docs"] または ["tairikut-docs", "CORE-docs-for-ai"] | |
| maxNodes | No | 返却ノード数上限 (default: 1000) | |
| patterns | No | include glob patterns (rootId 相対)。指定時は depth の代わりにこれを使用（空配列は未指定扱い） | |
| treeTextFormat | No | 表示フォーマット (default: "$path: $title $summary"). 変数: $path, $title, $summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses output formats (tree-text vs json), the default format, and the customizable display format using variables, adding behavioral context beyond the schema. It also mentions patterns takes precedence over depth, but does not address rate limits, authorization, or the exact return structure; with no annotations available, this is a moderate but not exhaustive disclosure.
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 well-organized with separate sections for parameters, format, and display format, making it easy to scan. It includes necessary examples and warnings without excessive verbosity, though some information is redundant with the schema (e.g., cwd appears in both).
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 no output schema and no annotations, the description covers the essential aspects comprehensively: parameter usage, format selection, display format configuration, and important pitfalls. It even warns about using the wrong id type. Minor details like depth and maxNodes are only in the schema, but they are self-explanatory and do not hinder 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?
Although schema coverage is 100%, the description adds substantial value by explaining the relationship to list_context_roots and explicitly stating not to use the path field. It provides concrete examples for rootIds, describes patterns/exclude behavior, and elaborates on treeTextFormat variables and defaults, significantly enhancing the schema's brief parameter 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 'コンテキストツリー(目次)を取得' (get context tree/table of contents), which is a specific verb and resource. It differentiates from sibling tools like ocd_get_contexts by focusing on the tree structure, 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 explicit guidance to use IDs from list_context_roots and warns against using the path field, which is a critical usage instruction. It also explains that patterns overrides depth and gives concrete examples for single and multiple roots, but does not explicitly compare against sibling tools like ocd_get_contexts or mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[OCD] Context Root 一覧を取得（cwd から設定を探索）
重要: 返却される id を以下のツールで使用してください:
get_context_tree: rootIds に id を配列で指定 例: rootIds: ["tairikut-docs"]
get_contexts: patterns に "id/" 形式で指定 例: patterns: ["tairikut-docs/"]
mutate_context: path に "id/subpath" 形式で指定 例: path: "tairikut-docs/features/new"
⚠️ 注意: path フィールドは実際のファイルシステムパスです。 ツール引数には使用しないでください。id を使用してください。
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | 作業ディレクトリ（設定探索の起点） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should carry the behavioral burden. It warns that the returned path field is a filesystem path and should not be used as a tool argument, which is a useful behavioral detail. However, it doesn't disclose other aspects such as side effects, sorting, or error conditions, so it's adequate but not comprehensive.
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 structured with a clear main sentence, followed by an important usage section with bullet examples, and a final note. It's a bit long but all content is actionable and not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only listing tool, the description covers the core purpose, usage of the returned value, and a critical caveat about path vs id. It's sufficient given the absence of an output schema, though it could mention the exact return structure more explicitly.
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 schema already describes cwd as the working directory starting point for config search, and the description reinforces this. Since schema coverage is 100%, the description adds minimal extra parameter semantics 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 retrieves the list of context roots, and specifies it searches configuration from the cwd. It distinguishes this as the root-listing operation, separate from sibling tools like get_contexts or get_context_tree.
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 explicitly instructs how to use the returned ids with the sibling tools get_context_tree, get_contexts, and mutate_context, providing examples of parameter formats. This gives clear workflow guidance and distinguishes when to use this tool vs the alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[OCD] コンテキストを変更 (create/update/delete/move 一括実行)
全ての書き込み操作を単一のツールで実行可能。 複数の操作を配列で渡すことで一括処理できます。
cwd: 作業ディレクトリ（設定探索の起点）
重要: path は Context Root の id で始まる完全なパスを指定してください。 例: "knowledge-base/new-doc", "src/plugins/MyPlugin/README"
type | 必須フィールド | オプション |
create | path, title, summary, content | attrs |
update | path | title, summary, attrs, contentUpdates |
delete | path | - |
move | path, to | - |
「ひとつづきのサマリ」として連結して読める形式で記述する
title: 見出し部分（10-50文字）
summary: 詳細部分（50-300文字）
両者の内容重複は禁止
path から想像できる以上の情報を含める
例:
title: "OAuth2.0認証フロー実装"
summary: "Google/GitHub連携対応。JWT発行、リフレッシュトークン管理、セッション有効期限7日。2FAはオプション対応"{ type: 'whole_replace', content: '新しいコンテンツ全体' }
search: '$', replacement: '\n\n追記内容', isRegex: true, flags: 'm'
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | 作業ディレクトリ（設定探索の起点） | |
| operations | Yes | 変更操作の配列 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains path formatting, operation types, and title/summary rules, which are helpful. However, it does not disclose side effects, transactional behavior, permanence, or how the tool interacts with the separate ocd_commit sibling. For a mutation tool, this missing info is a notable gap.
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 long but well-structured with headers, a table, and examples. The main purpose is front-loaded in the first line. Every section provides necessary operational detail, though it could be slightly trimmed without losing value. Overall it is efficient for the complexity it covers.
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?
The tool is complex with 4 operation types and nested contentUpdates, and the description covers these thoroughly. However, it omits what the tool returns, error behavior, and how it relates to the ocd_commit sibling (e.g., are changes staged or immediately applied?). These omissions are significant given the lack of output schema and annotations.
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 all parameters. The description adds substantial meaning beyond the schema: the operation type table clarifies required/optional fields, the path prefix rule is critical, the title/summary composition rules with examples are provided, and contentUpdates operation types are explained in detail. This significantly enhances correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'コンテキストを変更 (create/update/delete/move 一括実行)' which explicitly states the tool changes context and can execute multiple mutation operations in batch. It clearly distinguishes itself from sibling read/search/list tools by being the dedicated write tool.
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 states '全ての書き込み操作を単一のツールで実行可能' (all write operations can be executed in this single tool), strongly implying this is the tool to use for any context mutation. It provides detailed operational constraints like path must start with Context Root id and required fields per operation type, but does not explicitly mention alternatives or when not to use. Sibling tools are read/commit focused, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[OCD] キーワードでコンテキストを検索（cwd から設定を探索）
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | Yes | 作業ディレクトリ（設定探索の起点） | |
| query | Yes | 検索クエリ | |
| scope | No | 検索スコープ (glob パターン) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says it searches settings from cwd, but does not disclose recursive behavior, return format, case sensitivity, whether it searches file names or content, or any side effects. This is insufficient for a search 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 a single, front-loaded sentence with no redundant words. Every word contributes to conveying the core purpose, making it appropriately 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?
The tool has no output schema and no annotations, and the description is too thin to fill the gap. It does not explain what a 'context' is, what the search returns (e.g., context names vs. full objects), or how it fits with siblings like ocd_get_contexts. An agent would need more details to confidently invoke this 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 no new parameter semantics beyond the schema; it merely restates the cwd concept ('cwd から設定を探索') that the schema already covers. No extra value is provided.
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 a specific verb+resource: 'search contexts by keyword' and adds a qualifier about starting from cwd. This distinguishes it from sibling tools like list, get, mutate, and commit, so the purpose is 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 implies usage for keyword-based search with cwd as the starting point, which is clear context. However, it does not explicitly mention when not to use this tool or name alternatives, though the distinct verbs of sibling tools make the intended use apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0ocd_commitocd_get_context_treeocd_get_contextsocd_list_context_rootsocd_mutate_contextocd_search_contextsScored across 6 tools
Each tool has a distinctly defined responsibility: listing roots, retrieving contexts via patterns/filters, searching by keyword, getting a tree view, mutating (create/update/delete/move), and committing. The overlapping retrieval tools (get_contexts vs search_contexts) are differentiated by mechanism and purpose, and all descriptions include clear usage guidance.
All tool names follow a uniform pattern: 'ocd_' prefix + verb_noun in lowercase snake_case (list_context_roots, get_contexts, search_contexts, get_context_tree, mutate_context, commit). The only slight deviation is 'commit' without a noun, but it is still clear and consistent in style.
Six tools is a well-scoped set for a context datastore server. Each tool covers a distinct aspect (roots, retrieval, search, tree, mutation, git commit) without redundancy or bloat, fitting the typical 3-15 range comfortably.
The surface covers the full lifecycle: list/get/search/tree for reading, mutate_context for create/update/delete/move, and commit for persistence in manual git mode. There are no obvious dead ends or missing operations for the stated purpose.
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Your versioned memory across every AI tool — context maps, personal memory, and tasks over MCP.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
