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., "@dsh-local-rag 帮我翻一下之前的会话，看看上周定的索引重建方案是怎么说的"
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.
给 DSH 一个能翻旧账的本地记忆。纯 Node 内置 node:sqlite + FTS5，零外部依赖、不联网、不要 API key。
DSH 的会话是散落在磁盘上的 zstd 文件。会话一关，模型就看不见了 —— 上周讨论过的方案、三天前定下的结论，都得你重新讲一遍。
这个 MCP 服务把这些文件（加上你的工作区文档、技能库、人设文件）切成块建全文索引，让模型能用一句话把旧事翻出来。
中文能搜到是这里最花心思的地方：SQLite 自带的 unicode61 分词器不切中文，检索 和 记忆 这种词进去等于没索引。所以入库前先切成 bigram（双字），检索时同样切，再按来源加权。
Related MCP server: workspace-search
工具 | 干什么 |
| 全文检索，返回带来源、标题、片段的条目。 |
| 取某条结果的相邻片段（前后各 N 块），用来看完整上下文 |
| 增量重建（只处理改动过的文件）；可只重建某一类来源 |
| 索引状态：总块数、文本量、各类来源分布、上次构建时间 |
id | 内容 | 默认 |
|
| 开 |
| 你自己指定的工作区目录 | 要配 |
|
| 开 |
|
| 开 |
doc 源这样配（二选一）：
# 环境变量，多个用系统路径分隔符（Windows 是 ;，Linux/macOS 是 :）
export DSH_RAG_DOCS="D:/proj;D:/notes"// ~/.dsh/rag/config.json
{ "docs": ["D:/proj", "D:/notes"] }不配也不会报错，只是不索引工作区文档。
命中分数按来源加权 —— 记住"她说过什么"比记住某段代码更值钱：
source | 权重 |
persona | 1.6 |
session | 1.45 |
doc | 0.75 |
skill | 0.6 |
把仓库放进 ~/.dsh/rag（或者任何地方，路径写进下面的配置）：
git clone https://github.com/fanfan14543/dsh-local-rag.git ~/.dsh/rag建索引（全量第一次会慢一点，之后都是增量的）：
cd ~/.dsh/rag
node --no-warnings build.js在 DSH 的 profile 的 cordis.patch.yml 里挂成 MCP server：
- id: mcp-rag
name: "@deepseek-ai/dsh-mcp-client"
config:
servers:
rag:
command: node
args:
- "--no-warnings"
- "C:/Users/<你>/.dsh/rag/server.js"改完重启 DSH，MCP 页里就会出现 rag_search / rag_open / rag_index / rag_stats。
一台用了两个多月的机器上：133 个会话 + 若干工作区文档 → 39,121 块 / 33MB 文本 / 165MB 库，全量重建 4.5 秒，增量重建通常几百毫秒。
只用 Node 自带的 node:sqlite，所以要 Node 22+（DSH 自带的就是）。
不联网，也不调模型。纯 FTS5 + BM25，检索质量靠分词和权重，不靠 embedding。想要语义检索得自己接向量库。
索引是本地文件，别提交进 git（.gitignore 里已经排掉了）。
会话文件里的思考过程、工具调用参数会被过滤掉，只留正文，不然索引里全是噪音。
MIT
增量更新索引：只重建有改动的内容，没变的文件跳过。首次建库或改动很多时用命令行跑全量更快。不传 source 则更新全部四类来源。
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | 只更新某一类来源，可选 session / doc / skill / persona。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does real work: it discloses incremental rebuild behavior, skipping unchanged files, and the default that omitting source updates all four source types. It does not mention permissions, expected duration, or side effects beyond index mutation, but it covers the core behavior well.
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 short sentences, no filler, and the incremental behavior is front-loaded. Each sentence adds operational value: behavior, alternative, and default scope.
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 one-parameter indexing tool with full schema coverage and no output schema, the description covers the essential decision points: incremental update, full-rebuild alternative, and default scope. It could say more about mutation side effects or permissions, but nothing critical is missing.
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 baseline is 3, but the description adds useful semantics beyond the schema by stating that omitting source updates all four source categories. That default behavior is not fully conveyed by the schema alone.
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 a specific verb and resource: incrementally updating the RAG index. It immediately clarifies the key behavior—only changed content is rebuilt, unchanged files are skipped—and distinguishes this from a full CLI rebuild, which is enough to separate it from the read-oriented siblings rag_open, rag_stats, and rag_search.
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?
It explicitly says when to use this tool versus an alternative: use it for incremental updates, but use the command line for initial indexing or when many files changed. That is concrete when/when-not guidance rather than implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
取某一条检索结果的相邻片段（前后各若干块），用于看完整上下文。id 来自 rag_search 的返回。
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | rag_search 返回的 id。 | |
| span | No | 前后各扩展几块，默认 1，最大 5。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The wording '取' and the retrieval context imply a read-only operation, and the description says the result is adjacent chunks for viewing context, but it does not explicitly confirm read-only behavior, error handling, or output shape.
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 short sentences with no wasted wording. The core action and context are front-loaded, followed by the id provenance note.
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 two-parameter retrieval tool with full schema coverage and no output schema, the description is mostly complete: it explains the operation, its purpose, and where the id comes from. The main remaining gap is the lack of explicit behavioral details such as read-only confirmation or error behavior.
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 schema already fully documents both id and span, including span's default of 1 and maximum of 5. The description adds that id comes from rag_search's return, which is helpful provenance, but otherwise relies on the schema for parameter meaning.
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 a specific action: retrieve adjacent chunks before and after a given retrieval result, in order to view fuller context. It also establishes the relationship to rag_search by saying the id comes from rag_search's return, which helps distinguish this tool from its siblings, though it does not explicitly contrast use cases.
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?
It clearly indicates when to use the tool: to view the complete context around a search result. It also says where the required id comes from, which is a useful prerequisite. It does not state when not to use it or name alternatives beyond the implied rag_search dependency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在本地资料库里做全文检索（中文按二字组切分，SQLite FTS5 + BM25 排序）。资料库包含：历史会话记录、工作区文档、技能库、人设与记忆文件。当需要回忆以前聊过什么、翻某个项目的旧决定、查文档里的细节时用它。返回按相关度排序的片段，带来源和 id，可用 rag_open 取上下文。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 检索词，自然语言即可，中文英文混排也行。 | |
| top_k | No | 返回条数，默认 6，最大 30。 | |
| source | No | 限定来源，可选 session / doc / skill / persona，不填则全库搜。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the retrieval mechanism (SQLite FTS5 + BM25 ranking), the CJK bigram tokenization that explains Chinese matching behavior, and the return shape (relevance-sorted snippets with source and id). It does not cover empty-result behavior or any limits on the corpus (e.g. staleness, indexing requirements), which keeps it short of a 5.
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 sentences, front-loaded with the core action and corpus scope, then use cases, then return format. The implementation parenthetical (FTS5 + BM25) earns its place by explaining ranking and Chinese tokenization, though it is the one part an agent could live without.
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 correctly compensates by describing return values (ranked snippets with source and id) and the natural follow-up via rag_open. For a 3-parameter read tool this is nearly complete; only edge behavior (no hits, index freshness) is unaddressed.
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 all three parameters (query, top_k, source) are already documented in the schema, including the source enum values and top_k bounds. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb and resource ('在本地资料库里做全文检索') and immediately scopes the corpus (session logs, workspace docs, skill library, persona/memory files). It also distinguishes itself from rag_open by noting that rag_open is what you use to pull surrounding context, so an agent can separate the two without opening either schema.
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?
Gives concrete use cases: recalling past conversations, retrieving old project decisions, looking up document details. This is clear positive guidance, but it never states when NOT to use it or contrasts it with rag_index / rag_stats, so a small inference gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查看索引状态：总块数、文本量、各类来源的块数、上次构建时间。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the behavioral load. It does disclose the shape of what is returned (all metrics, read-only inspection implied), which is the main behavioral fact needed for a zero-parameter tool, but it never states that the call is side-effect free, whether it is expensive on large indexes, or what an empty/unbuilt index returns.
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?
A single front-loaded sentence with the purpose first and the returned fields after a colon. No filler, nothing that fails to earn 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?
With no output schema and no annotations, the description usefully compensates by listing the return values, which is the key gap for a stats tool. What remains missing is a note on the read-only nature and on behavior when no index has been built.
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 tool takes no parameters at all, so there is nothing for the description to disambiguate; the baseline for zero-param tools applies. The enumerated return fields are a bonus rather than parameter documentation.
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 gives a specific verb-plus-resource ("查看索引状态") and then enumerates exactly what status fields are exposed: total chunks, text volume, per-source chunk counts, and last build time. This clearly separates it from rag_index (which presumably builds) and rag_search, though it never names those siblings explicitly.
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?
Usage is only implied: an agent can infer this is the tool to call when it needs to inspect index health or readiness before searching. There is no explicit statement of when to call it instead of rag_index or rag_search, and no preconditions (e.g. whether an index must already exist) are given.
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.
v1.0.0rag_indexrag_openrag_searchrag_statsScored across 4 tools
Each tool maps to a distinct operation in the RAG lifecycle: rag_search retrieves, rag_open expands context around a hit, rag_index rebuilds, and rag_stats reports status. Descriptions explicitly cross-reference each other (rag_open consumes ids from rag_search; rag_index notes the full-rebuild CLI alternative), leaving no overlap.
All four tools use the same rag_ prefix plus a short lowercase verb (open, index, stats, search), fully consistent snake_case with no stray styles. The namespace prefix also makes the tools instantly recognizable as belonging to one server.
Four tools is on the thin side, but each covers a genuinely needed verb (search, fetch-context, build, inspect) with no filler. It is well-scoped for a local index server, though one or two more operations (e.g. source listing or pruning) would not feel redundant.
The read path (search → open for context) and the maintenance path (index → stats) are both covered, which handles the core recall and rebuild workflows. Minor gaps remain: no way to remove or exclude stale content, and no listing of which sources exist beyond the aggregate counts in rag_stats.
Ingest and search LogsLoom logs from coding agents.
Securely search and manage workspace context files for AI agents and teams.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Read and search folders on your own computer with explicit consent. Files are never uploaded.