Skip to main content
Glama
elis132

everything-mcp

by elis132
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

everything_search

Read-onlyIdempotent

Search files and folders across local and mapped drives using a real-time NTFS index. Filter results by wildcards, regex, size, date, extension, or path.

Instructions

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, and path restrictions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.0.9
    • changedInput schema / $defs / SearchInput / properties / query / description
      Previous value: -"Search query using Everything syntax. Examples: '*.py' (all Python files), 'ext:py;js path:C:\\Projects' (Python/JS in Projects), 'size:>10mb ext:log' (large logs), 'dm:today ext:py' (Python files modified today), 'content:TODO ext:py' (files containing TODO - requires content indexing), '\"exact phrase\"' (exact filename match), 'regex:test_\\d+\\.py$' (regex). Combine with space (AND) or | (OR). Prefix ! to exclude."New value: +"Search query using Everything syntax. Examples: '*.py' (all Python files), 'ext:py;js path:C:\\Projects' (Python/JS in Projects), 'size:>10mb ext:log' (large logs), 'dm:today ext:py' (Python files modified today), '\"exact phrase\"' (exact filename match), 'regex:test_\\d+\\.py$' (regex). Combine with space (AND) or | (OR). Prefix ! to exclude. Functions that read files from disk (content:, width:, height:, music tags, and dc:/da:/attrib: unless indexed) need a path:/ext: filter and only run on small candidate sets."
    • addedInput schema / $defs / SearchInput / properties / sort / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / $defs / SearchInput / properties / sort / default
      Previous value: -"date-modified-desc"New value: +null
    • changedInput schema / $defs / SearchInput / properties / sort / description
      Previous value: -"Sort order. Options: date-created, date-created-asc, date-created-desc, date-modified, date-modified-asc, date-modified-desc, extension, name, name-desc, path, path-desc, size, size-asc, size-desc"New value: +"Sort order. Options: date-created, date-created-asc, date-created-desc, date-modified, date-modified-asc, date-modified-desc, extension, name, name-desc, path, path-desc, size, size-asc, size-desc. Default: date-modified-desc (name if Everything does not index date modified)."
    • removedInput schema / $defs / SearchInput / properties / sort / type
      Removed value: -"string"
  2. First observedv1.0.7

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds real behavioral context beyond that – it searches a live real-time NTFS index, so results reflect current disk state, and it enumerates what query capabilities exist (wildcards, regex, size/date, extension, path). It does not discuss result volume, paging behavior, or that the query language differs from plain text.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, front-loaded sentences with the verb and resource first and no filler. 'Sub-millisecond' is mildly promotional but still conveys a useful performance trait, so it earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. What is missing is routing information relative to the four sibling search/stats/details tools, which is the main context an agent needs to pick this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The reported coverage of 0% understates reality: the nested SearchInput schema richly documents every parameter (query syntax with examples, sort enums, max_results bounds, pagination offset). The description's capability list ('wildcards, regex, size/date filters, extension filters, and path restrictions') largely mirrors what the schema already explains, so it adds little new parameter meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a clear verb+resource ('Search for files and folders') and names the underlying engine (voidtools Everything), which tells an agent exactly what domain this covers. It does not, however, differentiate itself from siblings like everything_search_by_type or everything_find_recent, so an agent must infer where this general search ends and the specialized tools begin.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance, and none of the four sibling tools are named as alternatives. Usage is only implied by the word 'Search', leaving the agent to guess whether this or everything_search_by_type/find_recent is the right entry point.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools