MCP 服务器提供与 Everything Search Engine 的集成，通过模型上下文协议实现强大的文件搜索功能。
跨文件和目录的全文搜索
高级搜索选项：
区分大小写的搜索
全词匹配
正则表达式
路径搜索
排序选项：
按名称
按路径
按尺寸
按修改日期
结果格式：
人类可读的文件大小
格式化日期
完整文件路径
Related MCP server: Everything Search MCP Server
Node.js 16 或更高版本
启用 HTTP 服务器的 Everything 搜索引擎
打开所有搜索
转至工具 > 选项 > HTTP 服务器
启用 HTTP 服务器
将 HTTP 服务器端口设置为 8011（这是此 MCP 服务器使用的默认端口）
单击“确定”保存更改
注意：如果需要使用其他端口，则需要修改src/server.ts中连接到http://127.0.0.1:8011/端口
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
}国际学习中心
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…