Un servidor MCP que proporciona integración con Everything Search Engine, lo que permite potentes capacidades de búsqueda de archivos a través del Protocolo de contexto de modelo.
Búsqueda de texto completo en archivos y directorios
Opciones de búsqueda avanzada:
Búsqueda que distingue entre mayúsculas y minúsculas
Coincidencia de palabras completas
Expresiones regulares
Búsqueda de ruta
Opciones de clasificación:
Por nombre
Por camino
Por tamaño
Por fecha de modificación
Formato del resultado:
Tamaños de archivos legibles por humanos
Fechas formateadas
Rutas de archivo completas
Related MCP server: Everything Search MCP Server
Node.js 16 o superior
Todo motor de búsqueda con servidor HTTP habilitado
Abrir todo Buscar
Vaya a Herramientas > Opciones > Servidor HTTP
Habilitar servidor HTTP
Establezca el puerto del servidor HTTP en 8011 (este es el puerto predeterminado utilizado por este servidor MCP)
Haga clic en Aceptar para guardar los cambios.
Nota: Si necesita utilizar un puerto diferente, deberá modificar el puerto en src/server.ts donde se conecta a http://127.0.0.1:8011/
npm install
npm run buildEl servidor proporciona una única herramienta a través de 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
}Búsqueda básica de archivos:
{
"query": "*.txt",
"maxResults": 5
}Búsqueda avanzada con filtros:
{
"query": "test",
"scope": "C:\\Users",
"caseSensitive": true,
"wholeWord": true,
"maxResults": 10,
"sortBy": "date_modified",
"ascending": false
}Búsqueda de expresiones regulares en rutas:
{
"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…