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., "@Everything MCP Enhanced find all *.ps1 files under D:\Projects, excluding noise"
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.
适用于 Windows voidtools Everything 的高性能 Model Context Protocol (MCP) 服务器，专为大模型 Agent 与 DeepSeek-Harness (DSH) 深度定制优化。
传统 AI 编程助手在 Windows 环境下查找文件时，通常依赖终端执行 dir /s、PowerShell Get-ChildItem -Recurse 或 Python 递归扫描。这种传统方式存在致命痛点：
极度耗时 & 易超时：递归遍历磁盘经常耗时数十秒甚至数分钟，极易触发 MCP / Agent 的执行超时。
严重消耗磁盘 I/O：海量的小文件随机读取会导致磁盘持续高负载甚至系统卡顿。
盲人摸象：如果模型不知道文件在哪一盘符或哪级目录，就必须反复多轮探测，严重消耗思考轮数。
接入 Everything MCP 后的质变：
⚡ 毫秒级极速检索：直接读取 Everything 的内存索引数据库（基于 NTFS USN 日志）。面对全盘 千万级（10,000,000+） 文件，搜索仅需 5 ~ 30 毫秒 即可完成！
🌐 全盘全局视野：无需预先猜测目录，跨驱动器瞬时定位代码、配置、脚本或文档，大幅提升 Agent 决策与执行效率。
🍃 零磁盘 I/O 磨损：在内存中完成高速模式匹配，不产生密集磁盘读写，保护固态硬盘寿命。
🧩 大模型专属优化：结合本增强版提供的依赖噪音过滤与单行紧凑模式，自动剔除几十万个 node_modules/.venv 垃圾项，节省 75% 以上的 Token 消耗，让大模型只接收最高价值的上下文信息。
⚡ 毫秒级极速响应：千万级文件 5~30ms 极速检索，无需等待漫长的递归扫描。
🚀 突破百条硬限制：单次最高支持返回 5000 条记录（原生社区版硬编码限 100 条），彻底避免分页往返导致模型上下文崩溃。
🎯 专属 path 参数支持：模型可直接传入 path: "D:\\" 或 path: "D:\\Projects"，服务端自动合成为 Everything 高性能语法，杜绝路径被丢弃误搜 C 盘的问题。
🛡️ 智能噪音过滤 (exclude_noise: true)：默认开启工程依赖过滤（自动排除 node_modules、.git、.venv、dist、build、__pycache__ 等），让搜索结果瞬时净化为业务源码文件。
📉 Token 极致节省 (format: "compact")：默认采用紧凑单行格式输出绝对路径，相比原始 4 行元数据格式节省 75% 以上的 Token。亦可通过 format: "detailed" 获取大小与修改时间。
🔍 智能端口探测：支持自动扫描 Everything 常用端口（8011、80、8080、54321）及读取 Everything.ini 配置，开箱即用。
操作系统：Windows (x64 / ARM64)。
安装并运行 Everything。
开启 Everything 的 HTTP 服务器：
打开 Everything 软件：菜单栏 工具 (Tools) → 选项 (Options) → HTTP 服务器 (HTTP Server)；
勾选 启用 HTTP 服务器，端口设为 8011（或保持默认 80）；
确定保存。
在 ~/.dsh/mcp-manager.json（或 DSH Web 界面 设置 → MCP）中添加：
{
"servers": [
{
"id": "everything-search",
"name": "everything",
"type": "stdio",
"command": "node",
"args": [
"C:\\path\\to\\everything-mcp\\dist\\index.js"
],
"env": {
"EVERYTHING_BASE_URL": "http://127.0.0.1:8011"
}
}
]
}在配置文件中添加：
{
"mcpServers": {
"everything": {
"command": "node",
"args": ["C:\\path\\to\\everything-mcp\\dist\\index.js"]
}
}
}everything_search参数名 | 类型 | 默认值 | 描述 |
| string | (必填) | 搜索关键词、通配符或扩展名（如 |
| string | 可选 | 限定搜索盘符或子目录（如 |
| boolean |
| 是否自动排除 |
| string / string[] | 可选 | 自定义额外排除的关键词或后缀 |
| number |
| 返回结果数量（1~5000） |
| number |
| 分页偏移量 |
| string |
| 输出格式： |
| string | 可选 | 排序字段： |
| boolean |
| 是否升序 |
everything_health检查本地 Everything HTTP 服务的连通性、响应延迟以及已索引的文件数据库总数。
Related MCP server: Enhanced Everything MCP Server
High-performance Model Context Protocol (MCP) server for voidtools Everything on Windows, specifically optimized for AI Agents, DeepSeek-Harness (DSH), Claude, and Cursor.
Traditional AI agents on Windows typically search files using commands like dir /s, PowerShell Get-ChildItem -Recurse, or recursive directory walks. This suffers from major drawbacks:
Painfully slow & error-prone: Recursive walks through large disks easily take 30+ seconds or time out.
Heavy disk I/O: Scanning millions of small files degrades system responsiveness and wears down SSDs.
Blind trial-and-error: Agents waste multiple round-trips guessing folder locations across drives.
With Everything MCP:
⚡ Millisecond-level latency: Direct access to Everything's memory-indexed database (powered by NTFS USN Journal). Searches across 10,000,000+ files take only 5 ~ 30 ms!
🌐 Global instant visibility: Locate any code, config, or script across all mounted drives in a single shot.
🍃 Zero disk thrashing: All matching happens in RAM—no disk I/O bottlenecks.
🧩 Agent-first enhancements: Automatic filtering of node_modules and virtual environments, plus a 1-line-per-path compact format that cuts token consumption by over 75%.
⚡ Sub-second response: Instant search across millions of files in 5~30ms.
🚀 No 100-item hard limit: Supports up to 5,000 items in a single query (or custom limit).
🎯 Dedicated path parameter: Scopes into folders/drives accurately without Everything syntax confusion.
🛡️ Smart noise filtering: Automatically excludes node_modules, .git, .venv, dist, __pycache__, etc.
📉 Token-optimized compact format: 1 line per path, saving 75%+ LLM context tokens.
🔍 Auto port detection: Probes ports 8011, 80, 8080, 54321 and inspects Everything.ini.
MIT License
Check connectivity to local voidtools Everything HTTP server and report index statistics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 that the tool both probes connectivity and returns index statistics, which is useful, but says nothing about failure behavior (e.g., what happens when the server is unreachable) or whether the reported statistics are live or cached. The read-only nature is strongly implied by 'check' and 'report' but never 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?
A single front-loaded sentence with no filler; the action (check connectivity) and the output (report index statistics) both earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only diagnostic with no output schema, the description covers what an agent needs to decide to call it. It could be slightly stronger by noting behavior on failure, but nothing essential 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?
The tool takes zero parameters, so the baseline is 4. The description correctly implies no inputs are needed, targeting only the locally configured server.
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+resource: checking connectivity to the local voidtools Everything HTTP server and reporting index statistics. It is clearly distinct from the sibling everything_search, which performs queries rather than a health probe, though it does not name the sibling 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 implied: an agent would call this to verify the server is reachable before attempting a search. However, there is no explicit when-to-use guidance, no mention of a fallback such as everything_search, and no stated conditions for when a health check is warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Windows files and folders instantly via voidtools Everything index with millisecond latency. Features:
Ultra-fast millisecond-level response (5-30ms) across 10M+ indexed files, eliminating slow recursive terminal scans (dir /s, Get-ChildItem).
Zero disk I/O thrashing (queries in-memory index directly).
Supports dedicated 'path' parameter to scope into specific drive or folder (e.g. 'D:\Projects').
Built-in 'exclude_noise' filter (default: true) to eliminate node_modules/.git/.venv clutter.
Token-saving 'compact' format (default: true, 1 line per file path) saving 75%+ tokens.
Max count up to 5000 results without artificial hard 100-item cutoff.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Optional drive or folder path to scope the search into (e.g. 'D:\' or 'C:\Projects'). | |
| sort | No | Sort by field: 'name', 'path', 'date_modified', or 'size'. | |
| count | No | Maximum number of results to return. Default is 100, max is 5000. | |
| query | Yes | Search expression, filename keywords, or wildcards (e.g. '*.ps1', 'config'). | |
| regex | No | Treat query as a regular expression. | |
| format | No | Output format. 'compact' returns 1 line per file path (token-optimized); 'detailed' returns file size and modified dates. Default is 'compact'. | compact |
| offset | No | Pagination offset (0-indexed). Default is 0. | |
| exclude | No | Optional extra keyword or pattern to exclude (e.g. ['dist', '.cache']). | |
| ascending | No | Sort ascending when true, descending when false. | |
| match_case | No | Case sensitive search. | |
| match_path | No | Match search query against full path. | |
| whole_word | No | Match whole words only. | |
| exclude_noise | No | Whether to automatically exclude noise dependencies (node_modules, .git, .venv, etc.). Default is true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden and does a lot: it discloses latency (5-30ms), that queries hit an in-memory index with no disk I/O, the non-obvious defaults (exclude_noise=true, compact=true), and that there is no hard 100-item cutoff up to 5000. It omits prerequisites and failure behavior, e.g. what happens if the Everything service is not running, which the everything_health sibling implies is a real concern.
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 core purpose is front-loaded in sentence one and the feature bullets are scannable. Several bullets are promotional restatements ('zero disk I/O thrashing', 'eliminating slow recursive terminal scans') that pad length without adding agent-relevant 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?
For a 13-parameter read-only search tool with no output schema and no annotations, the description covers performance characteristics, defaults, and result limits well enough to invoke correctly. It leaves minor gaps around environment prerequisites and error signaling, but nothing that would cause a mis-call.
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 documents all 13 parameters, making 3 the baseline. The feature bullets for path, exclude_noise, compact, and count largely restate what the schema already says, adding rationale (token savings, clutter removal) but little new semantic guidance beyond it.
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 first sentence states a specific verb and resource ('Search Windows files and folders') and names the backing engine (voidtools Everything index), which immediately distinguishes it from the only sibling, everything_health. An agent can tell what it does and does not need to open the schema to disambiguate.
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 gives clear context for use by contrasting against the alternative an agent would otherwise reach for ('eliminating slow recursive terminal scans (dir /s, Get-ChildItem)'), effectively telling the agent to prefer this over shell-based scanning. It stops short of explicit exclusion criteria, such as when a live index isn't available or when everything_health should be checked first.
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.0everything_healtheverything_searchScored across 2 tools
The two tools have clearly distinct purposes: everything_search performs file/folder queries against the Everything index, while everything_health reports connectivity and index statistics. There is no plausible scenario where an agent would confuse them.
Both tools follow the same snake_case convention with a consistent 'everything_' prefix (everything_search, everything_health). The verb/noun structure is predictable and readable.
With only 2 tools, the surface is thin for a server that advertises enhanced Everything functionality. The search and health tools are well-scoped, but the small count limits the value proposition compared to typical 3-15 tool servers.
Search plus health covers the core workflow of querying the Everything index and verifying the backend is alive. Minor gaps exist—such as no dedicated tool for retrieving file metadata or enumerating indexed drives—but agents can work around these via search parameters.
Securely search and manage workspace context files for AI agents and teams.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Connect AI agents to Exa for web search, content fetching, and multi-step research.
Artifact store for AI agents — read, write, and search files by path; share by rendered URL.
