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 search for .pdf files modified today"
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.
/plugin marketplace add elis132/everything-mcp
/plugin install everything-mcp@everything-mcpThat's it for Claude Code - the plugin bundles the MCP server and a skill that teaches the query syntax. For every other client, see Installation below.
Related MCP server: mcp-everything-search
everything-mcp (this) | mamertofabian (342⭐) | Josephur (26⭐) | essovius | |
Tools | 5 | 1 | 1 | 16 |
Setup | Auto-detects es.exe | Manual SDK DLL path | Manual HTTP server + host/port | Manual es.exe in PATH |
Everything 1.5 | Auto-detects instance | Not supported | Untested | Manual flag |
Talks to Everything via |
| Everything SDK (DLL) | Everything's HTTP server plugin (unauthenticated) |
|
Tests / CI | pytest, GitHub Actions | None visible | None visible | None visible |
es.exe (Everything's real-time NTFS index) vs. a naive filesystem walk, same query:
everything-mcp: 220 ms avg (5 runs)
Naive walk of C:\: 66,539 ms
~300x faster
@'
import os, subprocess, time, statistics
ES = os.path.expandvars(r"%LOCALAPPDATA%\Everything\es.exe")
QUERY = "everything.exe"
es_runs = []
for _ in range(5):
t0 = time.perf_counter()
subprocess.run([ES, "-n", "100", QUERY], capture_output=True, text=True)
es_runs.append((time.perf_counter() - t0) * 1000)
t0 = time.perf_counter()
matches = []
for dirpath, _, filenames in os.walk(r"C:\\"):
for name in filenames:
if name.lower() == QUERY:
matches.append(os.path.join(dirpath, name))
walk_ms = (time.perf_counter() - t0) * 1000
es_avg = statistics.mean(es_runs)
print("ES avg ms:", round(es_avg, 2))
print("Walk ms:", round(walk_ms, 2))
print("Speedup x:", round(walk_ms / es_avg, 1))
print("Matches:", len(matches))
'@ | python -Windows with Everything installed and running
es.exe (Everything's command-line interface) - included with Everything 1.5 alpha, or install separately:
winget install voidtools.Everything.Cli
scoop install everything-cli
choco install es
or download from github.com/voidtools/es and place it in your PATH
Python 3.10+ or uv
uvx everything-mcp # recommended, no install needed
pip install everything-mcp # or via pipFrom source:
git clone https://github.com/elis132/everything-mcp.git
cd everything-mcp && pip install -e ".[dev]"Every client below uses the same MCP server definition:
{
"mcpServers": {
"everything": {
"command": "uvx",
"args": ["everything-mcp"]
}
}
}Client | How to add it |
Claude Code |
|
Claude Desktop | Paste the JSON above into |
Codex CLI |
|
Gemini CLI |
|
Kimi CLI |
|
Qwen CLI |
|
Cursor | Paste the JSON above into Cursor's MCP settings UI |
Windsurf | Paste the JSON above into |
Any other MCP client | Use the JSON above verbatim |
{ "mcpServers": { "everything": { "command": "everything-mcp" } } }Or with explicit Python: {"command": "python", "args": ["-m", "everything_mcp"]}
Everything MCP auto-detects your setup, but you can override:
Variable | Description | Example |
| Path to es.exe |
|
| Named Everything instance |
|
| Hard cap on results per search (default |
|
Only set
EVERYTHING_INSTANCEif you explicitly configured a named instance in Everything (Tools → Options → General → Instance). Most installs - including most Everything 1.5 installs - run on the default instance; setting this unnecessarily breaks the connection. If in doubt, leave it out.
{
"mcpServers": {
"everything": {
"command": "uvx",
"args": ["everything-mcp"],
"env": { "EVERYTHING_INSTANCE": "1.5a" }
}
}
}everything_search - the workhorseParameter | Default | Description |
| (required) | Everything search query |
| 50 | 1-500 |
|
| name, path, size, date-modified, date-created, extension (+ |
| false | Match modifiers |
| 0 | Pagination offset |
Query syntax:
*.py all Python files
ext:py;js;ts multiple extensions
ext:py path:C:\Projects Python files under a path
size:>10mb larger than 10 MB
size:1kb..1mb between 1 KB and 1 MB
dm:today / dm:last1week modified today / in the last week
dc:2024 created in 2024
"exact name.txt" exact filename match
project1 | project2 OR search
!node_modules exclude a term
content:TODO files containing TODO (needs content indexing)
regex:^test_.*\.py$ regex search
parent:src ext:py files directly inside 'src' folders
dupe: / empty: duplicate filenames / empty folderseverything_search_by_type - category searchCategories: audio, video, image, document, code, archive, executable, font, 3d, data
Parameters: file_type (required), query, path, max_results, sort
everything_find_recent - what changed?Periods: 1min … 12hours, today, yesterday, 1day … 1year
Parameters: period (default 1hour), path, extensions, query, max_results
everything_file_details - deep inspectionParameters: paths (required, 1-20), preview_lines (0-200)
Returns full metadata; for directories, item count and listing; for text files with a preview, the first N lines.
everything_count_stats - quick analyticsParameters: query (required), include_size (default true), breakdown_by_extension
Count and size stats without listing every file - check scope before a big search.
Ask | Call |
Python files modified today in my project |
|
How much space do my log files use? |
|
First 50 lines of a config file |
|
Duplicate filenames in Documents |
|
Images larger than 5MB |
|
"es.exe not found" - Install Everything and es.exe, or set EVERYTHING_ES_PATH.
"Everything IPC window not found" - Make sure Everything is running (check the system tray). If you set EVERYTHING_INSTANCE, try removing it - most installs don't need it. Everything Lite doesn't support IPC.
No results for valid queries - Confirm Everything's index has finished building, try the same query in Everything's GUI, and check the drive/path is included in Everything's index settings.
Debugging:
everything-mcp 2>everything-mcp.log # server logs
npx @modelcontextprotocol/inspector uvx everything-mcp # MCP Inspectorpip install -e ".[dev]" # install with dev dependencies
pytest # run tests
ruff check src/ tests/ # lintContributions welcome - see CLAUDE.md for the architecture and design decisions. Areas of interest: direct named-pipe IPC, Everything SDK3 for 1.5, content search, file-watching, bookmark/tag support.
MIT - see LICENSE
voidtools for Everything, Anthropic for the Model Context Protocol, and the MCP community.
Get count and size statistics for files matching a query.
Fast way to understand the scope of a query without listing every file. Optionally breaks down by extension for a high-level overview.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the useful behavioral context that no file list is returned and that breakdowns are high-level, but it does not disclose the top-200 sampling behavior for breakdowns, which is left to the parameter schema. No contradictions exist.
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, purposeful sentences. The main purpose is front-loaded, the second sentence establishes when to use it, and the third maps to an optional parameter. There is no filler or redundant explanation.
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 description, combined with the rich parameter schema, safety annotations, and available output schema, gives an agent everything needed to select and invoke this tool correctly. No critical usage or behavioral information 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 visible nested schema actually provides strong descriptions for all three parameters: query syntax examples, the include_size boolean, and the breakdown_by_extension behavior. The description itself only echoes the extension-breakdown option and adds no extra meaning 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?
The description opens with a concrete verb and resource: 'Get count and size statistics for files matching a query.' It also distinguishes itself from sibling search tools by explicitly saying it works 'without listing every file,' so an agent can tell it apart from everything_search and similar listing-oriented tools.
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 gives a clear decision context: use it as a 'fast way to understand the scope of a query without listing every file.' This implies the main alternative is a file-listing search, but it does not name sibling tools explicitly or state exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed metadata and optional content preview for specific files.
Returns: full path, size, dates, type, permissions, hidden status. For directories: item count, subdirectories, file listing. For text files with preview_lines > 0: first N lines of content.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive, so the description does not need to restate that. It adds meaningful behavioral details beyond the annotations: directory previews include item counts and listings, and text files can return the first N lines. No contradiction with 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 compact: a purpose sentence followed by short return/conditional bullets. Every sentence adds value, and there is no fluff or tautological restatement of the tool name.
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 that an output schema is present and the annotations cover the safety profile, the description is complete enough for correct invocation. It covers files, directories, and textual previews, which are the main paths through 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?
The description adds semantic meaning to preview_lines by explaining that it returns the first N lines for text files, and clarifies that paths refer to specific files/folders. The schema supplies the numeric constraints, so the description complements rather than merely repeats 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 opens with a concrete verb-and-resource statement: 'Get detailed metadata and optional content preview for specific files.' It then enumerates exactly what is returned, which makes the tool's purpose unmistakable and distinguishes it from the sibling search/count tools.
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 communicates a clear context: use this when you have specific file or folder paths and want metadata or a preview. It does not explicitly name alternatives or state 'don't use for search,' but the 'for specific files' scope and the sibling tool names make the boundary obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find files modified within a recent time period.
Ideal for discovering what changed in a project, tracking recent downloads, finding today's log files, etc. Sorted newest-first.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive behavior. The description adds useful behavior beyond annotations: results are 'Sorted newest-first' and the scope is modification time within a window. No contradiction with the 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?
Three short front-loaded sentences with no filler: purpose, use cases, and sort order. Every sentence 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?
For a read-only search tool with a full input schema and output schema, the description supplies the missing conceptual context (use cases and ordering) without needing to restate return values. It could add a note about defaults or combining filters, but those are covered in the schema.
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 reported at 0%, so the prose should compensate, but it never mentions path, query, period syntax, extensions, or max_results. The schema does provide property descriptions, yet the description itself adds no parameter guidance beyond 'recent time period.'
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 a specific verb and resource: 'Find files modified within a recent time period.' It also gives concrete use cases and notes the sort order, which clearly separates it from siblings like everything_search or everything_search_by_type.
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 frames when the tool is appropriate ('Ideal for discovering what changed... tracking recent downloads, finding today's log files'). It does not, however, name sibling alternatives or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for files and folders instantly using voidtools Everything.
Leverages Everything's real-time NTFS index for sub-millisecond search across all local and mapped drives. Supports wildcards, regex, size/date filters, extension filters, path restrictions, and content search.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as a safe, idempotent read operation, so the description's main contribution is the NTFS-index backend and the supported filter families. That is useful context, but it omits behavioral details like failure modes, dependency on the Everything service running, or the content-indexing prerequisite for content search, so it is only a modest addition beyond 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?
Two tight sentences front-load the core purpose and then add the capability list that helps an agent decide what queries are possible. There is no filler or redundant restating of the name or annotations.
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 rich input schema and output schema, plus annotations covering safety, the description supplies enough context to invoke the tool correctly. It lacks only sibling-routing guidance and a caveat that content search depends on indexing, which are not fatal gaps for execution.
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 signal reports 0% schema description coverage, but the actual input schema carries rich per-field descriptions and query examples. The tool description adds a high-level capability summary (wildcards, regex, filters, content search) but does not comment on sort, offset, max_results, or the boolean flags; the schema fills those gaps, making this adequate but not exceptional.
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 names a specific verb ('Search'), a resource ('files and folders'), and the underlying engine (voidtools Everything), so the tool's function is unambiguous. It does not explicitly distinguish itself from sibling tools such as everything_search_by_type or everything_count_stats, so it falls short of a 5.
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 gives no explicit when-to-use or when-not-to-use guidance and never names an alternative tool. The broad wording implies this is the general search entry point, but an agent cannot tell from the description whether to prefer it over search_by_type or find_recent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for files by type category.
Categories: audio, video, image, document, code, archive, executable, font, 3d, data. Each maps to a curated list of file extensions.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the behavioral detail that each category maps to a curated list of file extensions, which is useful context. However, it doesn't disclose details like whether the search is case-insensitive, how the curated lists are defined, or what the output format looks like. With annotations covering the safety profile, a 3 is appropriate.
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 concise and front-loaded: the first sentence states the core purpose, and the second sentence provides the essential category list. Every sentence earns its place, and there is no wasted text.
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 an output schema, so return values are presumably documented there. The description covers the key input (file_type categories) and the annotations cover the safety profile. The main gap is that the description doesn't explain how the curated extension lists work or how to combine the query parameter with the type filter, but for a simple search tool with an output schema, this is adequate.
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 0%, so the description must compensate. The description explains the file_type parameter by listing valid categories, which adds meaning beyond the schema's bare list. However, it doesn't explain the other parameters (path, sort, query, max_results) beyond what the schema provides. The schema does have descriptions for path and query, but sort and max_results lack descriptions. The description's category list is helpful but doesn't fully compensate for the 0% 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 clearly states the tool's purpose: 'Search for files by type category.' It lists the available categories and explains that each maps to a curated list of file extensions. This distinguishes it from sibling tools like everything_search (general search) and everything_find_recent (recent files).
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 when to use this tool: when you want to search by a file type category. It lists the categories, which helps the agent select the right file_type value. However, it doesn't explicitly state when not to use it or mention alternatives like everything_search for more general queries. The sibling context provides some differentiation, but the description itself could be more explicit.
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.7everything_count_statseverything_file_detailseverything_find_recenteverything_searcheverything_search_by_typeScored across 5 tools
The tools are mostly distinct: generic search, type-category search, recency search, metadata/details, and stats each have clear intended use cases. The minor overlap is that everything_search itself supports date, extension, and content filters, so the specialized variants could sometimes be redundant, but their descriptions make the boundaries clear enough.
All tools share a consistent everything_ prefix and mostly use descriptive action-oriented wording. The main deviations are the synonymous 'search' vs 'find' verbs and the noun-phrase style of everything_file_details, but the overall pattern remains predictable and readable.
Five tools is well-scoped for a file-search server: query, type filter, recency filter, detail retrieval, and aggregation/statistics. Each tool covers a distinct practical need without excessive fragmentation or bloat.
The surface covers the core functions of an Everything-based search utility: general searches with rich filters, convenience searches by type and recency, per-file metadata and previews, and query-level statistics. There are no obvious dead ends or missing operations for this domain.
MCP registry & directory: search, find & install 31k+ MCP servers & tools. Catalog and marketplace.
MCP server for agentverse documentation, generated by doc2mcp.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
