Provides seamless local and remote file search with repository metadata integration, enabling intent-based code research and pattern discovery across GitHub repositories.
Builds and maintains a searchable knowledge base of code patterns and research findings over time for development research purposes.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Enhanced Everything MCP Server find recent Python files modified this week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A comprehensive Model Context Protocol (MCP) server that transforms voidtools Everything search engine into an intelligent development research platform. Integrates with AI assistants like Cursor, Kiro IDE, SpecStory, and Claude to provide lightning-fast file search, GitHub integration, intent-based code research, and spec-driven development tools.
Complete spec-driven development workflow from requirements to implementation
Related MCP server: everything-search-mcp
Lightning Fast Search: Leverages Everything's instant search capabilities
Advanced Filtering: Filter by file types, size, date, and more
Multiple Sort Options: Sort by name, size, date, or path
Regex Support: Use regular expressions for complex searches
Service Health Checks: Verify Everything service status
š§ Intent-Based Code Research: Analyzes specifications and finds matching implementations across GitHub
š GitHub MCP Integration: Seamless local/remote search with repository metadata
š SQLite Knowledge Base: Builds searchable library of code patterns over time
š CSV Export Integration: Structured data export using ES tools
šÆ Implementation Suggestions: AI-powered recommendations based on research findings
š Specification Awareness: Understands requirements, design, and task documents
š Traceability Analysis: Cross-references between specs and implementation
š Progress Tracking: Monitors specification coverage and task completion
š„ļø Terminal UI (TUI): Rich terminal interface for interactive project management
ā” One-Click Kiro Installation: Automated setup and configuration
š§ Comprehensive Logging: Full trace logging with structured debugging
š Easy Integration: Simple setup with Cursor, Kiro, SpecStory, and other MCP clients
Windows OS: Everything only runs on Windows
Python 3.8+: Required for virtual environment management
Python Virtual Environment: All operations must run in an activated venv
Everything Installed: Download from voidtools.com
Node.js 18+: Required for MCP server
es.exe Available: Command-line interface must be accessible
Create and activate Python virtual environment:
python -m venv everything-mcp-env
everything-mcp-env\Scripts\activateInstall Everything from voidtools.com
Ensure the Everything service is running
Verify es.exe exists at: C:\Program Files\Everything\es.exe
Test with: "C:\Program Files\Everything\es.exe" test
ā ļø Important: All commands must be run within the activated virtual environment.
# Ensure virtual environment is activated
python -m venv everything-mcp-env
everything-mcp-env\Scripts\activate
# One command installs and configures everything for Kiro
npm install -g everything-mcp-kiro
kiro-everything --setup# Create and activate virtual environment
python -m venv everything-mcp-env
everything-mcp-env\Scripts\activate
# Clone the repository
git clone https://github.com/SoMaCoSF/mcp-everything.git
cd mcp-everything
# Install dependencies
npm install
# Build the server
npm run build
# Test the installation (includes venv validation)
npm run test:kiro# Ensure virtual environment is activated
python -m venv everything-mcp-env
everything-mcp-env\Scripts\activate
npm install -g everything-mcp-serverAdd to your Cursor settings.json:
{
"mcp": {
"servers": {
"everything-search": {
"command": "node",
"args": ["path/to/everything-mcp/dist/index.js"],
"env": {
"EVERYTHING_PATH": "C:\\Program Files\\Everything\\es.exe",
"TRACE_DIRECTORY": "D:\\outputs\\traces"
}
}
}
}
}Kiro is an agentic IDE that supports MCP servers for external tool integration. To add Everything search to Kiro:
Open Kiro IDE and navigate to your project
Create or edit your MCP configuration following Kiro's MCP documentation
Add the Everything MCP server to your Kiro configuration:
{
"mcpServers": {
"everything-search": {
"command": "node",
"args": ["path/to/everything-mcp/dist/index.js"],
"env": {
"EVERYTHING_PATH": "C:\\Program Files\\Everything\\es.exe",
"TRACE_DIRECTORY": "D:\\outputs\\traces"
},
"description": "Everything search integration for fast file/folder search"
}
}
}Restart Kiro to load the new MCP server
Use Everything search through Kiro's agentic chat interface
Kiro-specific features:
Specs Integration: Use Everything search to find files when planning features with Kiro's spec-driven development
Hooks Automation: Set up automated file searches triggered by development events
Natural Language: Ask Kiro to "find all TypeScript files modified today" and it will use Everything search
Project Context: Kiro understands your project structure and can combine Everything search with its codebase knowledge
SpecStory is a documentation and specification platform designed for LLM integration. To add Everything search to SpecStory workflows:
Set up MCP integration in your SpecStory environment
Add the Everything MCP server to your SpecStory MCP configuration:
{
"mcpServers": {
"everything-search": {
"command": "node",
"args": ["path/to/everything-mcp/dist/index.js"],
"env": {
"EVERYTHING_PATH": "C:\\Program Files\\Everything\\es.exe",
"TRACE_DIRECTORY": "D:\\outputs\\traces"
},
"description": "Everything search for finding specification files and documentation"
}
}
}Restart SpecStory to load the new MCP server
Use Everything search to find relevant specification files, documentation, and project artifacts
SpecStory-specific features:
Specification Search: Quickly find spec files, requirements documents, and related artifacts
Documentation Discovery: Search across all project documentation and markdown files
Cross-Reference Lookup: Find files referenced in specifications using Everything's fast indexing
Version Control Integration: Search for spec files across different versions and branches
Context-Aware Documentation: Combine Everything search with SpecStory's LLM context for comprehensive documentation workflows
Example SpecStory workflows:
{
"query": "user authentication",
"docTypes": ["md", "mdx", "txt"],
"sortBy": "relevance",
"includeArchived": false
}Use the specialized documentation search:
{
"tool": "everything_search_docs",
"query": "API specification",
"docTypes": ["md", "yaml", "json"],
"sortBy": "relevance"
}everything_searchBasic file and folder search with Everything syntax support.
Parameters:
query (required): Search query using Everything syntax
maxResults (optional): Maximum results to return (default: 50)
fileOnly (optional): Search files only (default: false)
folderOnly (optional): Search folders only (default: false)
everything_search_advancedAdvanced search with comprehensive filtering and sorting options.
Parameters:
query (required): Search query
maxResults (optional): Maximum results (default: 50)
sortBy (optional): Sort by 'name', 'size', 'date', or 'path'
fileTypes (optional): Array of file extensions to filter
includeHidden (optional): Include hidden files/folders
regex (optional): Use regex search
caseSensitive (optional): Case sensitive search
everything_check_serviceVerify Everything service is running and accessible.
everything_search_docsSpecialized documentation and specification search optimized for SpecStory workflows.
Parameters:
query (required): Search query for documentation files
maxResults (optional): Maximum results (default: 50)
docTypes (optional): Documentation file types to search ['md', 'mdx', 'txt', 'rst', 'adoc']
includeArchived (optional): Include archived/old documentation (default: false)
sortBy (optional): Sort by 'relevance', 'date', 'name', or 'size'
Features:
Smart categorization: Automatically categorizes docs as specs, requirements, designs, APIs, etc.
Priority ranking: Relevance-based sorting puts most important docs first
Archive filtering: Excludes deprecated/old documentation by default
SpecStory optimization: Designed for specification and documentation workflows
everything_deep_research (Coming Soon)Intent-based code research across public GitHub repositories.
Parameters:
specification (required): Path to specification document or text content
searchDepth (optional): 'shallow', 'medium', or 'deep' research depth
languages (optional): Preferred programming languages
maxRepositories (optional): Maximum repositories to analyze
Features:
Intent Analysis: Parses specifications to understand implementation goals
Pattern Discovery: Finds code patterns that match specification requirements
Quality Assessment: Evaluates code quality, license compatibility, and maintenance status
Knowledge Base: Stores findings in SQLite database for future reference
everything_github_search (Coming Soon)Combined local and GitHub repository search.
Parameters:
query (required): Search query
includeLocal (optional): Include local file search (default: true)
includeGitHub (optional): Include GitHub repository search (default: true)
repositories (optional): Specific repositories to search
everything_tui_launch (Coming Soon)Launch Terminal User Interface for interactive project management.
Features:
Project Dashboard: Overview of specifications, tasks, and progress
Interactive Search: Real-time search with filtering and sorting
Research Interface: Monitor deep research progress and results
Implementation Suggestions: Browse AI-generated recommendations
The server supports full Everything search syntax:
Wildcards: *.txt, project*
Extensions: ext:js, ext:pdf
Size filters: size:>1mb, size:<100kb
Date filters: dm:today, dm:thisweek
Path filters: path:documents, path:"c:\projects"
Boolean operators: AND, OR, NOT
Exact phrases: "exact phrase"
{
"query": "*.py",
"maxResults": 100
}{
"query": "dm:lastweek",
"fileTypes": ["mp4", "mkv", "avi"],
"sortBy": "size"
}{
"query": "component",
"fileTypes": ["jsx", "tsx"],
"caseSensitive": false
}"es.exe not found"
Verify Everything is installed
Check path: C:\Program Files\Everything\es.exe
Try running Everything as administrator
"No results returned"
Ensure Everything database is indexed
Check if Everything service is running
Use everything_check_service tool
"Permission denied"
Run Everything as administrator
Check Windows permissions
Verify Everything service is started
The server logs all operations to the trace directory:
Default Location: D:\outputs\traces\everything-mcp-{timestamp}
Files: Operation logs, development diary, error traces
Use for debugging search queries and server issues
The Enhanced Everything MCP Server transforms simple file search into an intelligent development research platform:
MCP Client (Cursor/Kiro/SpecStory/Claude) sends search requests
MCP Server validates and processes requests
es.exe executes the actual search
Results are parsed and returned as structured JSON
Trace System logs all operations for debugging
Intent-based code research with GitHub discovery and pattern analysis
Interactive terminal dashboard for project management and search
Research Engine: Intent-based code discovery and pattern analysis
Knowledge Base: SQLite database for accumulated research findings
GitHub Integration: Seamless local/remote search capabilities
TUI Controller: Rich terminal interface for interactive development
Spec Awareness: Understanding of requirements, design, and task documents
Basic Everything search integration
Advanced filtering and sorting
Documentation search optimization
MCP protocol implementation
Comprehensive logging and tracing
GitHub MCP integration
Intent-based code research
SQLite knowledge base
CSV export capabilities
Pattern recognition and analysis
Terminal User Interface (TUI)
AI-powered implementation suggestions
Automated specification analysis
One-click Kiro installation
Advanced voidtools integration
The enhanced features are currently in specification phase. See .kiro/specs/enhanced-everything-mcp/ for detailed requirements, design, and implementation plans.
# Run current version in development mode
npm run dev
# Build for production
npm run build
# Start built server
npm start
# View enhancement specifications
# Open .kiro/specs/enhanced-everything-mcp/ in Kiro IDEeverything-mcp/
āāā src/
ā āāā index.ts # Main server implementation
āāā .kiro/specs/ # Enhancement specifications
ā āāā enhanced-everything-mcp/
ā āāā requirements.md # Detailed requirements
ā āāā design.md # Architecture design
ā āāā tasks.md # Implementation plan
āāā dist/ # Built files (generated)
āāā package.json # Dependencies and scripts
āāā tsconfig.json # TypeScript configuration
āāā architecture.svg # Architecture diagram
āāā README.md # This fileMIT License - See LICENSE file for details.
Fork the repository
Create a feature branch: git checkout -b feature/amazing-feature
Commit your changes: git commit -m 'Add amazing feature'
Push to the branch: git push origin feature/amazing-feature
Open a Pull Request
voidtools for the amazing Everything search engine
Model Context Protocol for the MCP specification
The Cursor team for MCP integration
Kiro IDE for agentic development with MCP support
SpecStory for specification and documentation workflows
Made with ā¤ļø for the Everything and AI community
Check if Everything service is running and accessible
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states the check behavior but doesn't disclose return format, error handling, or side effects. For a read-only health check, this is a gap but not severe.
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?
A single sentence with clear structure and no wasted words: verb, resource, and condition. Perfectly concise and front-loaded.
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?
For a simple no-parameter tool with no output schema, the description sufficiently conveys the tool's core purpose. It could add return value semantics, but the simplicity of the operation makes this largely adequate.
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 tool has zero parameters, so baseline is 4. The description adds no parameter-specific details, but none are needed given the empty schema.
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 uses a specific verb 'Check' and a specific resource 'Everything service' with a clear outcome 'running and accessible'. This directly distinguishes the tool from its siblings, which are all search- or launch-related.
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 implies usage is for verifying service status but provides no explicit when-to-use or alternative guidance. Sibling tool names suggest context, but the description itself doesn't state when to prefer this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for files and folders using Everything search engine
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (supports Everything syntax) | |
| fileOnly | No | Search files only (exclude folders) | |
| folderOnly | No | Search folders only (exclude files) | |
| maxResults | No | Maximum number of results to return (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose whether the operation is read-only, any dependencies, or potential side effects. The phrase 'using Everything search engine' hints at an external service but lacks explicit behavioral details.
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 concise sentence that accurately states the tool's purpose. It is appropriately sized with no unnecessary words.
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 absence of an output schema and annotations, the description is too brief to fully convey what results are returned or how the search behaves. It also fails to mention the presence of sibling tools or when to use them.
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 schema already provides 100% coverage with descriptions for all four parameters, so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema offers.
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?
Description clearly states it searches for files and folders using the Everything search engine. However, it does not explicitly differentiate itself from the sibling tool everything_search_advanced.
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?
No guidance is provided on when to use this tool versus alternatives like everything_search_advanced. The description only states the basic function, leaving usage context to the user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advanced search with filtering and sorting options
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| regex | No | Use regex search | |
| sortBy | No | Sort results by field | name |
| fileTypes | No | Filter by file extensions (e.g., ["js", "ts", "md"]) | |
| maxResults | No | Maximum results (default: 50) | |
| caseSensitive | No | Case sensitive search | |
| includeHidden | No | Include hidden files/folders |
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 only mentions 'filtering and sorting options', which are already visible in the schema. It does not state whether the tool is read-only, whether it requires specific permissions, how it handles network or service dependencies, or what the return format is. This is a significant gap for a tool with multiple configuration options.
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 only one sentence, which is concise but not appropriately sized for a tool with seven parameters. It lacks any structure or front-loading of key information, and the brevity primarily reflects under-specification rather than efficiency. It does not 'earn its place' by adding substantial value.
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?
This is a complex tool with seven parameters, an enum, and no output schema. The description provides almost no context beyond the word 'advanced', failing to explain why one would choose this tool, what the results contain, or any constraints (e.g., default behavior, performance considerations). Given the tool's complexity and the absence of annotations, the description is severely incomplete.
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 schema description coverage is 100%, so all seven parameters are individually documented. The description's mention of 'filtering and sorting' adds a high-level summary but does not provide any additional meaning beyond what the schema already provides. It meets the baseline but does not exceed it.
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 states 'Advanced search with filtering and sorting options', which clearly indicates a search operation and distinguishes it from the sibling 'everything_search' by the 'Advanced' qualifier. However, it does not specify what resource is being searched (e.g., files, folders, the Everything index), relying on the tool name for context. The verb is present but the object is vague, making it clear yet not fully precise.
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?
There is no guidance on when to use this tool versus its sibling alternatives. It does not mention that basic search should be used for simple queries, nor does it explain the advantage of the advanced version beyond its name. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for documentation, specifications, and requirement files optimized for SpecStory workflows
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for documentation files | |
| sortBy | No | Sort results by field | relevance |
| docTypes | No | Documentation types to search for: ["spec", "requirements", "design", "api", "readme", "docs"] | |
| maxResults | No | Maximum results (default: 50) | |
| includeArchived | No | Include archived/old documentation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only restates the search action and adds a vague 'optimized' qualifier, with no detail on scope, limitations, return format, or side effects. This leaves the agent with little understanding of the tool's behavior beyond the literal verb/resource.
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, front-loaded sentence with no filler. Every word adds meaning: 'Search', the resource list, and the 'SpecStory' qualifier all contribute to understanding the tool's purpose.
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?
With no output schema and no annotations, the description should compensate by explaining what the tool returns or any operational constraints. It does neither, only stating the search categories. For a specialized search tool with 5 parameters, this is incomplete.
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?
Schema description coverage is 100%, so each parameter already has a description. The tool description adds no extra meaning about parameter usage beyond the general 'SpecStory workflows' hint, which does not clarify any specific parameter. Baseline 3 is appropriate.
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 states a specific action ('Search') and resource ('documentation, specifications, and requirement files'), and distinguishes it from the generic sibling 'everything_search' by adding the 'optimized for SpecStory workflows' qualifier. This gives a clear, non-tautological purpose.
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 phrase 'optimized for SpecStory workflows' provides clear context for when to use this tool, implying it is the docs-focused variant compared to siblings. However, it does not explicitly mention alternatives or when NOT to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch the Terminal User Interface for interactive project management and search
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Initial tab to display (default: dashboard) | dashboard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It states the tool launches an interactive TUI but doesn't disclose potential side effects such as blocking until exit, requiring user input, or modifying state beyond opening the interface.
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, well-structured sentence that immediately conveys the tool's purpose with no wasted words.
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?
For a simple launcher with one optional parameter and no output schema, the description adequately covers the core functionality. However, it could mention that the TUI is interactive and may take over the terminal, which would make it more complete.
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 fully describes the 'mode' parameter with an enum and default value, and schema coverage is 100%. The description adds no additional parameter meaning, so it meets the baseline but doesn't exceed it.
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 identifies the action ('Launch') and the resource ('Terminal User Interface'), and mentions interactive project management and search. This distinguishes it from sibling tools like everything_search and everything_search_advanced, which are likely non-interactive search functions.
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 implies this tool is for interactive use, but it doesn't explicitly state when to use it instead of the sibling search tools or provide exclusions. Users are left to infer that it's for launching a TUI rather than performing a one-off search.
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. Dates show when Glama detected each change.
v1.0.0everything_check_serviceeverything_searcheverything_search_advancedeverything_search_docseverything_tui_launchThe three search tools (everything_search, everything_search_advanced, everything_search_docs) share overlapping purposes, and an agent might struggle to choose the right one. The advanced and docs variants have clear modifiers, but the boundary between basic and advanced is not stark. The service check and TUI launch are clearly distinct.
All tools share the everything_ prefix and use snake_case, which creates a strong family identity. The verb forms are consistent (search, check, launch), though search_advanced and search_docs use different syntactic structures (adjective vs noun). Overall, the naming is predictable and readable.
With 5 tools, the server is well-scoped for its purpose. It provides a reasonable set of search capabilities (basic, advanced, docs-specific), a service health check, and a TUI launcher without bloating the surface. This count is appropriate for an Everything integration.
The tool set covers the core search workflows and includes a service check and TUI launch. Missing operations like starting/stopping the service or updating the index are minor and can be worked around. Overall, the major use cases are addressed with no critical dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analyā¦
Memory, secret scanning and code findings across every AI coding tool
AI-powered intelligence for your development workflow via Indicate.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SoMaCoSF/mcp-everything'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
