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., "@voidtools-everything-mcp find 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.
Local MCP server for searching a voidtools Everything 1.5a index from Codex, Claude, and other MCP clients.
This server uses the Everything HTTP Server and exposes read-only MCP tools. It does not download, open, modify, delete, rebuild, or reindex files.
Windows with Everything 1.5a running.
Everything HTTP Server enabled.
Node.js 20.11 or newer.
Related MCP server: mcp-everything-search
In Everything:
Open Tools > Options > HTTP Server.
Enable HTTP Server.
Note the port. The official default URL is http://127.0.0.1, while this machine is currently serving Everything HTTP on http://127.0.0.1:8011.
Disable file download unless you explicitly need browser downloads.
Keep the HTTP Server off public networks.
git clone <this-repository-url>
cd voidtools-everything-mcp
npm install
npm run buildDuring local development, configure your MCP client to run the built local file with node. MCP clients start this process on demand and communicate with it over stdio; you do not need to keep this server running manually.
Variable | Default | Description |
|
| Everything HTTP Server URL |
|
| Default returned result count |
|
| Maximum returned result count |
|
| HTTP timeout in milliseconds |
{
"mcpServers": {
"everything": {
"command": "node",
"args": [
"C:\\Users\\KU\\project\\Everything-SDK\\dist\\index.js"
],
"env": {
"EVERYTHING_BASE_URL": "http://127.0.0.1:8011"
}
}
}
}Use an absolute path in args. Many MCP clients launch the command directly without a shell, so variables such as %USERPROFILE%, $env:USERPROFILE, or ~ may not be expanded inside args. If your MCP client explicitly documents environment-variable expansion in command arguments, you can use it; otherwise the absolute path is the safest option.
If you move this repository to C:\Users\KU\project\voidtools-everything-mcp, update the path like this:
{
"mcpServers": {
"everything": {
"command": "node",
"args": [
"C:\\Users\\KU\\project\\voidtools-everything-mcp\\dist\\index.js"
],
"env": {
"EVERYTHING_BASE_URL": "http://127.0.0.1:8011"
}
}
}
}After this package is published to npm, MCP clients can run it with npx instead of a local path:
{
"mcpServers": {
"everything": {
"command": "npx",
"args": [
"-y",
"voidtools-everything-mcp"
],
"env": {
"EVERYTHING_BASE_URL": "http://127.0.0.1:8011"
}
}
}
}With this setup, the MCP client starts npx only when it needs the MCP server. npx downloads or reuses the package from the npm cache, runs the package binary locally, and the process exits when the MCP client disconnects.
This package is set up for npm Trusted Publishing from GitHub Actions. The workflow lives at .github/workflows/publish.yml and publishes when a v* tag is pushed.
Push this repository to GitHub.
Create the package name on npm, or publish the first version manually once with npm publish --access public.
Open the package page on npmjs.com.
Go to package settings and find Trusted Publisher.
Choose GitHub Actions.
Fill in:
Organization or user: your GitHub username or organization.
Repository: the GitHub repository name.
Workflow filename: publish.yml.
Environment name: leave blank unless you add a GitHub deployment environment.
Allowed actions: npm publish.
Trusted Publishing uses GitHub Actions OIDC, so you do not need to create an NPM_TOKEN secret.
npm version patch
git push
git push origin --tagsThe pushed v* tag starts the publish workflow. The workflow installs dependencies, runs tests, typechecks, builds, shows npm pack --dry-run, and then runs npm publish --access public.
For a minor or major release, use npm version minor or npm version major.
everything_searchSearches the Everything index and returns bounded file/folder paths.
Input:
{
"query": "invoice ext:pdf",
"count": 20,
"sort": "date_modified",
"ascending": false,
"matchPath": true
}everything_healthChecks whether the Everything HTTP Server is reachable.
npm test
npm run typecheck
npm run buildKeep Everything HTTP Server bound to localhost for personal agent usage.
Do not expose the HTTP Server to a public network.
Add authentication, path allowlists, and audit logging before any remote deployment.
Add a separate allowlisted file-reading tool only if an agent truly needs file contents.
MIT
Check whether the Everything HTTP Server is reachable.
| 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 full burden. It indicates a non-destructive read check, but does not specify return format (e.g., boolean, status code) or behavior when unreachable. Minimal but adequate for a simple health check.
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 sentence that is front-loaded and contains no extraneous information. Every word 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?
Given no parameters, no output schema, and simple purpose, the description is nearly complete. It could mention what the response indicates, but overall it sufficiently describes the tool's function.
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 has no parameters and schema coverage is 100%. Baseline for zero parameters is 4; description adds no param info but none is needed.
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 checks reachability of the Everything HTTP Server with a specific verb and resource. It is distinct from the sibling tool 'everything_search' which implies search functionality.
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 implicitly suggests using this tool to verify server availability before performing searches, but it does not explicitly state when to use or when not to use it. The context with sibling helps, but lacks formal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search local Everything index. Read-only. Returns bounded file and folder paths.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort field. | |
| count | No | Maximum number of results. | |
| query | Yes | Everything search query. | |
| regex | No | Treat query as a regular expression. | |
| offset | No | Zero-based result offset. | |
| ascending | No | Sort ascending when true. | |
| matchCase | No | Match case-sensitive text. | |
| matchPath | No | Search the full path. | |
| wholeWord | No | Match whole words only. | |
| diacritics | No | Match diacritics. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses read-only behavior and return types, but lacks details on rate limits, authentication needs, or error behavior. With no annotations, the description carries the full burden; it covers basic safety but is not comprehensive.
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 extremely concise with three short sentences, each providing critical information: purpose, safety, and output. No redundancy or fluff.
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 10 parameters and no output schema or annotations, the description is minimal. It does not explain pagination, error conditions, or the meaning of 'bounded'. Given the tool's complexity, more detail is needed.
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%, with each parameter having a description in the input schema. The description adds no additional meaning beyond what is already in the schema, warranting a baseline score of 3.
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 specifies the verb 'Search', the resource 'local Everything index', and the return type 'bounded file and folder paths'. It clearly distinguishes from the sibling tool 'everything_health', which is for health checks.
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 states 'Read-only', implying it is safe and suitable for search operations. While it does not explicitly state when not to use it, the sibling context makes the intended usage clear.
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.
v0.1.1everything_healtheverything_searchThe two tools have clearly distinct purposes: one checks server health, the other performs searches. No overlap or ambiguity.
Both tools follow the consistent pattern 'everything_<action>', using snake_case and the same prefix for clear grouping.
Two tools is minimal but appropriate for a simple read-only search interface with a health check. Just above the threshold for being too few.
The set covers the essential operations: verifying connectivity and searching. Missing advanced search features but adequate for basic usage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Serve a folder of Markdown notes as an MCP server: hybrid search, reading, and sourced answers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nanpuhaha/voidtools-everything-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
