Everything Search Engine との統合を提供し、モデル コンテキスト プロトコルを通じて強力なファイル検索機能を可能にする MCP サーバーです。
ファイルとディレクトリ全体の全文検索
詳細検索オプション:
大文字と小文字を区別した検索
単語全体の一致
正規表現
パス検索
並べ替えオプション:
名前で
パス別
サイズ別
更新日順
結果のフォーマット:
人間が読めるファイルサイズ
フォーマットされた日付
完全なファイルパス
Related MCP server: Everything Search MCP Server
Node.js 16以上
HTTP サーバーが有効な Everything Search Engine
すべてを開く検索
ツール > オプション > HTTPサーバーに移動します
HTTPサーバーを有効にする
HTTP サーバーのポートを 8011 に設定します (これはこの MCP サーバーで使用されるデフォルトのポートです)
変更を保存するには[OK]をクリックします
注: 別のポートを使用する必要がある場合は、 http://127.0.0.1:8011/ 8011/ に接続するsrc/server.tsのポートを変更する必要があります。
npm install
npm run buildサーバーは、MCP を通じて単一のツールを提供します。
use_mcp_tool:
- server_name: everything-search
- tool_name: search
- arguments:
{
"query": "search string", // Required: Text to search for
"scope": "C:", // Optional: Search scope (default: C:)
"caseSensitive": false, // Optional: Match case
"wholeWord": false, // Optional: Match whole words only
"regex": false, // Optional: Use regular expressions
"path": false, // Optional: Search in paths
"maxResults": 100, // Optional: Max results (1-1000, default: 100)
"sortBy": "name", // Optional: Sort by name/path/size/date_modified
"ascending": true // Optional: Sort direction
}基本的なファイル検索:
{
"query": "*.txt",
"maxResults": 5
}フィルターを使用した高度な検索:
{
"query": "test",
"scope": "C:\\Users",
"caseSensitive": true,
"wholeWord": true,
"maxResults": 10,
"sortBy": "date_modified",
"ascending": false
}パス内の正規表現検索:
{
"query": ".*\\.js$",
"regex": true,
"path": true,
"maxResults": 5
}ISC
Search for files using Everything Search
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search query | |
| scope | No | Search scope (default: C:) | |
| caseSensitive | No | Match case | |
| wholeWord | No | Match whole words only | |
| regex | No | Use regular expressions | |
| path | No | Search in paths | |
| maxResults | No | Maximum number of results (1-1000, default: 100) | |
| sortBy | No | Sort results by | |
| ascending | No | Sort in ascending order |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Everything Search' which implies a file search tool, but doesn't describe what the tool returns (e.g., list of files, metadata), error conditions, performance characteristics, or any limitations. This leaves significant gaps in understanding how the tool behaves beyond basic functionality.
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, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy for an agent to quickly understand the core functionality.
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 tool's complexity (9 parameters, no output schema, and no annotations), the description is insufficient. It doesn't explain what the tool returns, how results are formatted, any limitations of 'Everything Search', or error handling. For a search tool with many parameters, more context is needed to help the agent use it effectively.
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 100% description coverage, providing clear documentation for all 9 parameters. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting without compensating for any gaps.
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 verb ('Search for') and resource ('files') using a specific technology ('Everything Search'), which gives a good sense of what the tool does. However, without sibling tools to differentiate from, it cannot achieve a perfect score of 5, as there's no explicit distinction from alternatives.
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 alternatives, prerequisites, or specific contexts. It simply states what the tool does without any usage instructions or exclusions, leaving the agent without direction on appropriate application.
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.
searchScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The single 'search' tool has a clear and distinct purpose that cannot be confused with any other tool in this set.
A single tool inherently exhibits perfect naming consistency, as there are no other tools to compare it against. The name 'search' follows a simple, clear verb pattern appropriate for its function.
A single tool is too few for most server purposes, as it severely limits functionality and flexibility. While it matches the server's name ('Everything Search'), a search-focused server could benefit from additional tools like filtering, sorting, or advanced query options to enhance usability.
The tool surface is severely incomplete for a search domain. With only a basic search tool, there are significant gaps such as no ability to configure search parameters, handle search results (e.g., pagination or sorting), or perform related operations like indexing management or search history.
Securely search and manage workspace context files for AI agents and teams.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Search remote Model Context Protocol servers and tools discovered by BuiltWith, without an API key.
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…