Everything Search MCP Server
모든 검색 MCP 서버
Everything Search Engine과 통합을 제공하는 MCP 서버로, Model Context Protocol을 통해 강력한 파일 검색 기능을 제공합니다.
특징
파일 및 디렉토리 전체에서 전체 텍스트 검색
고급 검색 옵션:
대소문자 구분 검색
전체 단어 일치
정규 표현식
경로 검색
정렬 옵션:
이름으로
경로로
크기별로
수정된 날짜 기준
결과 형식:
사람이 읽을 수 있는 파일 크기
형식화된 날짜
전체 파일 경로
Related MCP server: Everything Search MCP Server
필수 조건
Node.js 16 이상
HTTP 서버가 활성화된 모든 검색 엔진
모든 검색 구성
모든 검색 열기
도구 > 옵션 > HTTP 서버로 이동하세요.
HTTP 서버 활성화
HTTP 서버 포트를 8011로 설정합니다(이것은 이 MCP 서버에서 사용하는 기본 포트입니다)
변경 사항을 저장하려면 확인을 클릭하세요.
참고: 다른 포트를 사용해야 하는 경우 src/server.ts 에서 http://127.0.0.1:8011/ 에 연결되는 포트를 수정해야 합니다.
설치
지엑스피1
용법
서버는 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
}특허
아이에스씨
Available Tools
1 toolsearchC
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 |
TDQS
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
search
TDQS
Scored 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.
Maintenance
Related MCP Connectors
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…
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceEnables instant file and folder searching on Windows using Everything's blazing-fast search engine, supporting powerful search syntax including wildcards, regex, size filters, date filters, and comprehensive file information retrieval.74 npm12MIT
- AlicenseNot gradedqualityDmaintenanceIntegrates with Everything Search Engine to provide lightning-fast file search capabilities across Windows systems using natural language queries and advanced filtering options through MCP-compatible applications.1ISC
- AlicenseNot gradedqualityDmaintenanceEnables instant file searches on Windows using Everything's native SDK, supporting advanced filters, duplicate detection, and content search through MCP tools.5MIT
- AlicenseAqualityDmaintenanceEnables lightning-fast file searching on Windows using Everything SDK, with tools for search, version check, status, and file info retrieval.414 npmMIT