Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@everything-mcp find all PDF files on my Desktop"
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.
基于 Voidtools Everything 的极速文件搜索 MCP 服务器 Ultra-lightweight MCP server for Voidtools Everything search engine
Everything MCP 是一个极轻量的 MCP (Model Context Protocol) 服务器，将 Voidtools Everything 的极速文件搜索能力暴露给 AI 代理（Claude Code、Codex、DeepSeek Harness 等）。
通过调用 Everything.exe -create-file-list 导出搜索结果并解析 EFU 格式，实现毫秒级文件检索。
English: Everything MCP is an ultra-lightweight MCP server that exposes Voidtools Everything's blazing-fast file search to AI agents (Claude Code, Codex, DeepSeek Harness, etc.). It uses Everything.exe -create-file-list to export search results and parses the EFU format.
Related MCP server: mcp-everything-search
⚡ 极速搜索 — 基于 Everything 的 NTFS 索引，毫秒级检索百万文件
🪶 极致轻量 — 单文件 5KB，零冗余代码，秒级启动
🔧 零配置集成 — 自动适配 Claude Code、Codex、DSH
🎯 智能触发 — 配置 CLAUDE.md 让 AI 自动识别何时调用
🪟 原生 Windows — 完美适配 Windows NTFS 文件系统
English:
⚡ Blazing fast — Leverages Everything's NTFS index for millisecond search across millions of files
🪶 Ultra lightweight — Single 5KB file, zero bloat, instant startup
🔧 Zero-config integration — Auto-adapts to Claude Code, Codex, DSH
🎯 Smart triggering — CLAUDE.md configures AI to auto-select when to search
🪟 Native Windows — Perfectly optimized for Windows NTFS
Windows 操作系统 (需要 NTFS 文件系统)
Everything v1.4+ 已安装并以管理员权限运行
Node.js v18+（测试环境 v24）
npm（用于安装依赖）
💡 Everything 需要管理员权限以读取 NTFS 索引。可在 Everything → 工具 → 选项 → 常规中勾选"以管理员身份运行"，或安装 Everything 服务。
English:
Windows OS (requires NTFS filesystem)
Everything v1.4+ installed and running as administrator
Node.js v18+ (tested with v24)
npm (for dependency installation)
💡 Everything needs admin privileges to read the NTFS index. Check "Run as administrator" in Everything → Tools → Options → General, or install the Everything service.
# 克隆仓库 | Clone the repository
git clone https://github.com/ixijxjgxidj-cmd/everything-MCP.git
cd everything-MCP
# 安装依赖 | Install dependencies
npm install
# 启动测试 | Quick test
node src/index.js
# 输出: everything-mcp ready自动配置已在 ~/.claude/settings.json 中添加。手动配置：
{
"mcpServers": {
"everything": {
"command": "node",
"args": ["C:/Users/hulk cheng/Desktop/公司/everything-mcp-server/src/index.js"],
"disabled": false,
"autoApprove": []
}
}
}项目级配置在 .codex/config.json 中，或手动添加：
{
"mcpServers": {
"everything": {
"command": "node",
"args": ["C:/Users/hulk cheng/Desktop/公司/everything-mcp-server/src/index.js"]
}
}
}在 DSH 的插件配置中添加：
plugins:
mcp-client:
servers:
everything:
transport: stdio
command: node
args:
- "C:/Users/hulk cheng/Desktop/公司/everything-mcp-server/src/index.js"
cwd: "C:/Users/hulk cheng/Desktop/公司/everything-mcp-server"工具 | 描述 | 参数 |
| 搜索文件 |
|
| 统计文件数 |
|
| 检查服务状态 | 无 |
# 搜索文件 | Search for files
everything_search(query: "node.exe", maxResults: 10)
# 限定路径搜索 | Search within a specific path
everything_search(query: "*.pdf", path: "C:\\Users\\hulk cheng\\Desktop")
# 统计文件 | Count files
everything_count(query: "*.py")
# 检查状态 | Health check
everything_health()everything-MCP/
├── src/
│ └── index.js # MCP 服务器 (单文件, 5KB)
│ # MCP server (single file, 5KB)
├── .claude/
│ └── settings.json # Claude Code 项目配置
├── .codex/
│ └── config.json # Codex 配置
├── CLAUDE.md # 自动触发规则
├── package.json
└── README.mdAI Agent (Claude Code/Codex/DSH)
│
│ MCP Protocol (JSON-RPC over stdio)
▼
┌─────────────────────────────────┐
│ everything-mcp (index.js) │
│ │
│ tools/list ← 注册 3 个工具 │
│ tools/call ← 处理搜索请求 │
└────────────────┬────────────────┘
│
│ spawn Everything.exe -create-file-list
▼
┌─────────────────────────────────┐
│ Everything (NTFS 搜索引擎) │
│ 毫秒级检索百万文件 │
└─────────────────────────────────┘
│
│ EFU (CSV) 格式导出
▼
┌─────────────────────────────────┐
│ 解析 -> JSON -> 返回给 AI │
└─────────────────────────────────┘确保 Everything 正在运行（系统托盘中有图标）
确保 Everything 以管理员权限运行
或安装 Everything 服务：Everything → 工具 → 选项 → 常规 → 安装服务
首次使用时调 everything_health 检查状态
检查 C:\\Program Files\\Everything\\Everything.exe 是否存在
确保 Node.js 版本 >= 18
重新运行 npm install
English:
Make sure Everything is running (check system tray)
Run Everything as administrator
Or install the Everything service: Everything → Tools → Options → General → Install Service
Call everything_health first to check status
Verify C:\\Program Files\\Everything\\Everything.exe exists
Ensure Node.js >= 18
Re-run npm install
Voidtools Everything — 极致的 Windows 文件搜索引擎
Model Context Protocol — AI 工具协议标准
Count matching files
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path filter | |
| query | Yes | Search query |
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, but it only says 'Count matching files.' It does not mention return format, path filter behavior, or whether the operation is safely read-only beyond what is implied by the word 'count.' The description fails to add meaningful behavioral context beyond the obvious.
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, focused sentence with no unnecessary words. It is appropriately concise and front-loaded, effectively communicating the core purpose without waste.
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 2-parameter tool with no output schema, the description is minimally sufficient: it states what the tool does. However, it does not explicitly clarify that the result is a numeric count, nor does it explain the role of the optional path filter. The absence of output schema increases the burden on the description, but given the simplicity, the gap is not severe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for both parameters (path with 'Path filter' and query with 'Search query'). The description adds no additional meaning to these parameters, so it remains at the baseline for schema-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Count' with resource 'matching files,' clearly indicating the tool counts files matching a query. This distinguishes it from sibling everything_search, which likely returns the files themselves, and everything_health, which presumably checks service 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?
The description provides no guidance on when to use this tool versus everything_search or everything_health. There is no mention of alternative tools, exclusions, or contextual signals to help an agent decide when counting is preferable to searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Everything status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only restates the name of the tool in sentence form ('Check Everything status') and provides no information about side effects, return values, or operational implications. This is essentially a tautology.
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 highly concise, consisting of a single short phrase. It is appropriately sized for a simple health-check tool with no parameters. However, it could have added a note about the output or purpose without becoming verbose.
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 explain what 'status' means or what the tool returns. It does not, leaving the agent with insufficient context to understand the tool's behavior or interpret its results. Contextual completeness is poor despite the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to document. According to the guidelines, 0 params warrant a baseline of 4. The description does not need to add parameter semantics absent any parameters.
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 'Check Everything status' uses a specific verb and resource, clearly indicating a health/status check. It distinguishes from sibling tools like everything_search and everything_count by focusing on status rather than data retrieval. However, it is minimal and does not elaborate on what 'status' encompasses.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or context for issuing a health check. It simply states an action without situating it relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search files via Everything
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path filter | |
| query | Yes | Search query | |
| maxResults | No | Max results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It merely states 'Search files via Everything' without disclosing whether results are limited by path or maxResults, whether it's read-only (though implied), or what output format is. Lacks behavioral context beyond the verb.
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 sentence, front-loaded, no fluff. Appropriate for a simple search tool.
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?
Description is too sparse for context. No output schema, no annotations; it doesn't explain what the tool returns (file paths? matches?), nor the effect of path/maxResults. Given the tool's complexity relative to information provided, it's incomplete.
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 covers all three parameters with descriptions. The description adds no param semantics; however baseline 3 applies due to 100% schema 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 uses a specific verb ('Search') and resource ('files via Everything'), clearly identifying its function. Sibling tools (everything_count, everything_health) serve different purposes, so this tool is distinct.
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 everything_count or everything_health. It doesn't mention scenarios where counting or health checks would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0everything_counteverything_healtheverything_searchEach tool has a clearly distinct purpose: search returns files, count returns a count, and health checks service status. There is no overlap or ambiguity between them.
All tool names follow a consistent 'everything_verb' pattern, using snake_case throughout. The naming is predictable and uniform.
Three tools is an appropriate scope for a simple Everything integration, covering the essential operations without unnecessary bloat.
For a search-focused tool, the set covers the core capabilities of searching, counting results, and checking server health. There are no obvious missing operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ixijxjgxidj-cmd/everything-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
