mcp-everything-search
Explicitly supports installation on Debian Linux systems via apt package manager
Explicitly supports installation on Fedora Linux systems via dnf package manager
Provides file searching capabilities on Linux systems using the locate/plocate command
Provides file searching capabilities on macOS systems using the built-in mdfind command (Spotlight)
Uses macOS Spotlight database (via mdfind) to provide file searching capabilities on macOS systems
Explicitly supports installation on Ubuntu Linux systems via apt package manager
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., "@mcp-everything-searchfind all PDF files modified this week"
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.
Everything Search MCP Server
An MCP server that provides fast file searching capabilities across Windows, macOS, and Linux. On Windows, it uses the Everything SDK. On macOS, it uses the built-in mdfind command. On Linux, it uses the locate/plocate command.
Requires Python 3.10+. Since 0.3.0 the server is built on the MCP Python SDK 2.x. See CHANGELOG.md for release notes.
Tools
search
Search for files and folders across your system. The search capabilities and syntax support vary by platform:
Windows: Full Everything SDK features (see syntax guide below)
macOS: Basic filename and content search using Spotlight database
Linux: Basic filename search using locate database
Arguments are grouped into a base object (all platforms) and a platform-specific object. The server advertises only the current platform's object in its tool schema.
base (required):
query(required): Search query string. See the syntax guide.max_results(optional): Maximum number of results to return (default: 100, range: 1-1000)
windows_params (optional, Windows only):
match_path: Match against full path instead of filename only (default: false)match_case: Enable case-sensitive search (default: false)match_whole_word: Match whole words only (default: false)match_regex: Enable regex search (default: false)sort_by: Sort order for results (default: 1). Available options:
- 1: Sort by filename (A to Z)
- 2: Sort by filename (Z to A)
- 3: Sort by path (A to Z)
- 4: Sort by path (Z to A)
- 5: Sort by size (smallest first)
- 6: Sort by size (largest first)
- 7: Sort by extension (A to Z)
- 8: Sort by extension (Z to A)
- 11: Sort by creation date (oldest first)
- 12: Sort by creation date (newest first)
- 13: Sort by modification date (oldest first)
- 14: Sort by modification date (newest first)mac_params (optional, macOS only):
search_directory: Limit the search to a directory (mdfind -onlyin).~is expanded; the directory must exist.literal_query: Treat the query as a literal Spotlight query string (-literal)interpret_query: Interpret the query as if typed in the Spotlight menu (-interpret)live_updates: Not supported.mdfind -livenever exits, so setting it returns an error.
By default the query is a filename search (mdfind -name). Setting literal_query or interpret_query passes the query to Spotlight as-is instead; such a query must not start with -, because mdfind would read it as an option.
linux_params (optional, Linux only):
ignore_case: Case-insensitive search,-i(default: true)regex_search: Treat the query as a regular expression (default: false)existing_files: Only list files that still exist,-e(default: true)count_only: Return only the number of matches,-c(default: false)
Examples:
{
"base": {"query": "*.py", "max_results": 50},
"windows_params": {"sort_by": 6}
}{
"base": {"query": "ext:py datemodified:today", "max_results": 10}
}{
"base": {"query": "ENABLE", "max_results": 50},
"mac_params": {"search_directory": "/Users/me/code/myrepo"}
}Each result includes:
Path: full pathFilename: name, with the extension in parentheses when presentSize: size in bytesCreated,Modified,Accessed: timestamps, orN/Awhen unavailable
If a search fails (invalid arguments, Everything not running, a search command taking longer than 30 seconds, and so on), the tool returns an error result (isError: true) whose text starts with Search failed:.
On Windows, if some matches cannot be read from Everything (for example a file with a corrupt timestamp), the readable results are returned and the output ends with Warning: N matching result(s) could not be read and were omitted.
Search Syntax Guide
For detailed information about the search syntax supported on each platform (Windows, macOS, and Linux), please see SEARCH_SYNTAX.md.
Related MCP server: everything-mcp
Prerequisites
Windows
Everything search utility:
Download and install from https://www.voidtools.com/
Make sure the Everything service is running
Everything SDK:
Download from https://www.voidtools.com/support/everything/sdk/
Extract the SDK files to a location on your system
The same SDK DLL (
Everything64.dll) also works with Everything 1.5
Linux
Install and initialize the
locateorplocatecommand:Ubuntu/Debian:
sudo apt-get install plocateorsudo apt-get install mlocateFedora:
sudo dnf install mlocate
After installation, update the database:
For plocate:
sudo updatedbFor mlocate:
sudo /etc/cron.daily/mlocate
macOS
No additional setup required. The server uses the built-in mdfind command.
Installation
Using uv (recommended)
When using uv no specific installation is needed. We will
use uvx to directly run mcp-server-everything-search.
Upgrading from 0.2.x: uvx may keep using a cached 0.2.1, which fails to start with the current MCP SDK ('Server' object has no attribute 'list_resources', see #39). Run it once with the latest version to refresh the cache:
uvx mcp-server-everything-search@latestUsing PIP
Alternatively you can install mcp-server-everything-search via pip:
pip install -U mcp-server-everything-searchAfter installation, you can run it as a script using:
python -m mcp_server_everything_searchConfiguration
Windows
Set EVERYTHING_SDK_PATH to the full path of Everything64.dll from the Everything SDK. It is required: the server stops at startup with an error naming the variable if it is unset or does not point to a file.
EVERYTHING_SDK_PATH=C:\path\to\Everything-SDK\dll\Everything64.dllLinux and macOS
No additional configuration required.
Tool name
The tool is called search by default. If that name collides with another MCP server's tool in your client, rename it:
EVERYTHING_SEARCH_TOOL_NAME=everything_searchThe name may use letters, digits, _ and - (1-64 characters). An invalid value stops the server at startup.
Usage with Claude Code
Windows:
claude mcp add everything-search -e EVERYTHING_SDK_PATH="C:\path\to\Everything-SDK\dll\Everything64.dll" -- uvx mcp-server-everything-searchLinux and macOS:
claude mcp add everything-search -- uvx mcp-server-everything-searchUsage with Claude Desktop
Add one of these configurations to your claude_desktop_config.json based on your platform:
{
"mcpServers": {
"everything-search": {
"command": "uvx",
"args": ["mcp-server-everything-search"],
"env": {
"EVERYTHING_SDK_PATH": "path/to/Everything-SDK/dll/Everything64.dll"
}
}
}
}{
"mcpServers": {
"everything-search": {
"command": "python",
"args": ["-m", "mcp_server_everything_search"],
"env": {
"EVERYTHING_SDK_PATH": "path/to/Everything-SDK/dll/Everything64.dll"
}
}
}
}{
"mcpServers": {
"everything-search": {
"command": "uvx",
"args": ["mcp-server-everything-search"]
}
}
}Or if using pip installation:
{
"mcpServers": {
"everything-search": {
"command": "python",
"args": ["-m", "mcp_server_everything_search"]
}
}
}Debugging
You can use the MCP inspector to debug the server. For uvx installations:
npx @modelcontextprotocol/inspector uvx mcp-server-everything-searchOr if you've installed the package in a specific directory or are developing on it:
git clone https://github.com/mamertofabian/mcp-everything-search.git
cd mcp-everything-search
npx @modelcontextprotocol/inspector uv run mcp-server-everything-searchTo view server logs:
Linux/macOS:
tail -f ~/.config/Claude/logs/mcp*.logWindows (PowerShell):
Get-Content -Path "$env:APPDATA\Claude\logs\mcp*.log" -Tail 20 -WaitDevelopment
If you are doing local development, there are two ways to test your changes:
Run the MCP inspector to test your changes. See Debugging for run instructions.
Test using the Claude desktop app. Add the following to your
claude_desktop_config.json:
{
"mcpServers": {
"everything-search": {
"command": "uv",
"args": [
"--directory",
"/path/to/mcp-everything-search",
"run",
"mcp-server-everything-search"
],
"env": {
"EVERYTHING_SDK_PATH": "path/to/Everything-SDK/dll/Everything64.dll"
}
}
}
}Tests and checks
uv run pytest
uv run ruff check
uv run pyrightCI runs the tests on Windows, macOS and Linux (Python 3.10 and 3.13). Code changes are planned as MAID manifests in manifests/; see CLAUDE.md/AGENTS.md and run scripts/maid validate before opening a pull request.
License
This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.
Disclaimer
This project is not affiliated with, endorsed by, or sponsored by voidtools (the creators of Everything search utility). This is an independent project that utilizes the publicly available Everything SDK.
Available Tools
1 toolsearchB
Universal file search tool for Linux
Current Implementation: Using locate with Unix-style search capabilities
Search Syntax Guide: Linux Locate Search Syntax:
Basic Usage:
Simple pattern: locate filename
Case-insensitive: -i pattern
Regular expressions: -r pattern
Existing files only: -e pattern
Count matches: -c pattern
Pattern Wildcards:
matches any characters
? matches single character
[] matches character classes
Examples:
locate -i "*.pdf"
locate -r "/home/.*.txt$"
locate -c "*.doc"
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | Base search parameters common to all platforms. | |
| linux_params | No | Linux-specific search parameters for locate. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the backend implementation ('using locate') and that matches can be counted or limited to existing files, but says nothing about permissions, performance on large filesystems, error behavior, or result ordering.
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?
It is front-loaded and headed clearly, but a large portion duplicates flag semantics already present in the schema (e.g. -i, -c, -r) and repeats the same examples in two formats. Roughly a third of the text is redundant with structured data.
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 a nested parameter object and no output schema, so the description should explain what comes back. It never states the result format, ordering, or how max_results truncates, and it omits how regex_search interacts with the wildcard syntax it documents.
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 already 100%, so the baseline is 3. The description goes beyond the schema by documenting pattern syntax (wildcards, character classes) and concrete regex examples, which the schema's one-line 'query' description does not provide.
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 opening line states a specific verb and resource: a file search tool, scoped to Linux, backed by locate. That is enough for an agent to know what the tool does, though the 'Universal ... for Linux' phrasing is slightly self-contradictory and no sibling tools exist to differentiate against.
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 is rich on how to construct a search (flags, wildcards, examples) but gives no task-level when-to-use guidance, no when-not-to-use conditions, and no alternatives to prefer. Usage is only implied by the fact that it is a file searcher.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
search
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of confusing it with another. Its purpose (universal file search on Linux via locate) is unambiguous.
A single tool named 'search' is a clean, conventional name with no competing conventions to clash with. Nothing inconsistent exists in the set.
One tool is borderline thin for a server, though a single 'search' entry point is a defensible design. Supporting operations around the search lifecycle (e.g. index refresh) would justify a slightly larger surface.
Search itself is well-documented with wildcard and regex syntax, but the surface is a thin wrapper over locate with no index-update/reindex operation, which is a real gap since locate results depend on a current database. No output-filtering or result-paging operations are exposed either.
Maintenance
Related MCP Connectors
Agentic search over your Dewey document collections from any MCP-compatible client.
MCP server for Firecrawl — web search, scraping, and biomedical/arXiv paper search.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables instant file searches on Windows using Everything's native SDK, supporting advanced filters, duplicate detection, and content search through MCP tools.5MIT
- AlicenseAqualityDmaintenanceMCP server that integrates Everything file search engine on Windows, enabling fast file and folder searches using Everything syntax, plus version and status checks.411 npmMIT
- AlicenseAqualityDmaintenanceEnables lightning-fast file searching on Windows using Everything SDK, with tools for search, version check, status, and file info retrieval.414 npmMIT
- AlicenseNot gradedqualityDmaintenanceProvides lightning-fast filesystem search on Windows via the Everything SDK, with fallback to HTTP API.91 npm3MIT
Appeared in Searches
- What is a filesystem server and how to find one? A filesystem server implements a protocol like 9P, NFS, or SMB to serve files to clients. Search GitHub for 'filesystem server', look at projects such as pyd-fuse servers, Go-based go-fuse servers, Rust 'fuser' servers, or Python 'mux9p'. The query 'filesystem server' commonly refers to the Model Context Protocol (MCP) filesystem server, an open-source reference implementation (e.g., from the modelcontextprotocol/servers repository) that exposes local files to AI assistants.
- A server that supports using a Python debugger for tasks like finding memory leaks
- General Search Query
- Searching for specific library documentation and implementation code in a codebase
- How to get the file tree structure of a folder