Summary: everything-mcp is a Windows MCP server that searches millions of files in milliseconds via voidtools Everything's real-time NTFS index.
everything_search — Instant file/folder search with Everything syntax: wildcards, regex, ext:, size:, dm:/dc:, path:, content:, boolean AND/OR/!, plus sorting, pagination, and case/whole-word/path/regex matching (1–500 results).
everything_search_by_type — Category search across audio, video, image, document, code, archive, executable, font, 3d, and data.
everything_find_recent — Find files modified in a recent window (1min → 1year, or today/yesterday), optionally filtered by path, extensions, or query.
everything_file_details — Deep metadata for 1–20 paths (size, dates, type, permissions, hidden status); directory item counts and listings; optional first N lines of text files.
everything_count_stats — Count and total size for a query without listing files, with optional per-extension breakdown to scope large searches first.
All five tools are read-only, idempotent, and non-destructive — ideal for locating files, checking what changed, inspecting contents, and measuring disk usage from any MCP client.
Click on "Deploy 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., "@everything-mcp search for .pdf files modified today"
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.
/plugin marketplace add elis132/everything-mcp
/plugin install everything-mcp@everything-mcpThat's it for Claude Code - the plugin bundles the MCP server and a skill that teaches the query syntax. For every other client, see Installation below.
Related MCP server: mcp-everything-search
everything-mcp (this) | mamertofabian (342⭐) | Josephur (26⭐) | essovius | |
Tools | 5 | 1 | 1 | 16 |
Setup | Auto-detects es.exe | Manual SDK DLL path | Manual HTTP server + host/port | Manual es.exe in PATH |
Everything 1.5 | Auto-detects instance | Not supported | Untested | Manual flag |
Talks to Everything via |
| Everything SDK (DLL) | Everything's HTTP server plugin (unauthenticated) |
|
Tests / CI | pytest, GitHub Actions | None visible | None visible | None visible |
es.exe (Everything's real-time NTFS index) vs. a naive filesystem walk, same query:
everything-mcp: 220 ms avg (5 runs)
Naive walk of C:\: 66,539 ms
~300x faster
@'
import os, subprocess, time, statistics
ES = os.path.expandvars(r"%LOCALAPPDATA%\Everything\es.exe")
QUERY = "everything.exe"
es_runs = []
for _ in range(5):
t0 = time.perf_counter()
subprocess.run([ES, "-n", "100", QUERY], capture_output=True, text=True)
es_runs.append((time.perf_counter() - t0) * 1000)
t0 = time.perf_counter()
matches = []
for dirpath, _, filenames in os.walk(r"C:\\"):
for name in filenames:
if name.lower() == QUERY:
matches.append(os.path.join(dirpath, name))
walk_ms = (time.perf_counter() - t0) * 1000
es_avg = statistics.mean(es_runs)
print("ES avg ms:", round(es_avg, 2))
print("Walk ms:", round(walk_ms, 2))
print("Speedup x:", round(walk_ms / es_avg, 1))
print("Matches:", len(matches))
'@ | python -Windows with Everything installed and running
es.exe (Everything's command-line interface) - included with Everything 1.5 alpha, or install separately:
winget install voidtools.Everything.Cli
scoop install everything-cli
choco install es
or download from github.com/voidtools/es and place it in your PATH
Python 3.10+ or uv
uvx everything-mcp # recommended, no install needed
pip install everything-mcp # or via pipFrom source:
git clone https://github.com/elis132/everything-mcp.git
cd everything-mcp && pip install -e ".[dev]"Every client below uses the same MCP server definition:
{
"mcpServers": {
"everything": {
"command": "uvx",
"args": ["everything-mcp"]
}
}
}Client | How to add it |
Claude Code |
|
Claude Desktop | Paste the JSON above into |
Codex CLI |
|
Gemini CLI |
|
Kimi CLI |
|
Qwen CLI |
|
Cursor | Paste the JSON above into Cursor's MCP settings UI |
Windsurf | Paste the JSON above into |
Any other MCP client | Use the JSON above verbatim |
{ "mcpServers": { "everything": { "command": "everything-mcp" } } }Or with explicit Python: {"command": "python", "args": ["-m", "everything_mcp"]}
Everything MCP auto-detects your setup, but you can override:
Variable | Description | Example |
| Path to es.exe |
|
| Named Everything instance |
|
| Hard cap on results per search (default |
|
Only set
EVERYTHING_INSTANCEif you explicitly configured a named instance in Everything (Tools → Options → General → Instance). Most installs - including most Everything 1.5 installs - run on the default instance; setting this unnecessarily breaks the connection. If in doubt, leave it out.
{
"mcpServers": {
"everything": {
"command": "uvx",
"args": ["everything-mcp"],
"env": { "EVERYTHING_INSTANCE": "1.5a" }
}
}
}everything_search - the workhorseParameter | Default | Description |
| (required) | Everything search query |
| 50 | 1-500 |
|
| name, path, size, date-modified, date-created, extension (+ |
| false | Match modifiers |
| 0 | Pagination offset |
Query syntax:
*.py all Python files
ext:py;js;ts multiple extensions
ext:py path:C:\Projects Python files under a path
size:>10mb larger than 10 MB
size:1kb..1mb between 1 KB and 1 MB
dm:today / dm:last7days modified today / in the last 7 days
path:D:\Photos dc:2024 created in 2024 (slow function, see below)
"exact name.txt" exact filename match
project1 | project2 OR search
!node_modules exclude a term
ext:py path:C:\proj content:TODO files containing TODO (slow function, see below)
regex:^test_.*\.py$ regex search
parent:src ext:py files directly inside 'src' folders
dupe: / empty: duplicate filenames / empty foldersSlow functions. content:, width:/height:, music tags (artist:, album:, ...) and, unless
their property is indexed (Everything > Tools > Options > Indexes), dc:, da: and attrib: (and
dm:/size: if you turned their indexing off) make Everything read every candidate file from disk -
and Everything answers no other search until it is done. On Everything 1.4 the server therefore runs
these terms last and only when the rest of the query narrows the candidates enough (1,000 files and
100 MB for content:; 1,000 files for image and tag functions; 30,000 for dates, attributes and
sizes). Otherwise it refuses and reports the candidate count, so add path:, ext: or a name.
everything_search_by_type - category searchCategories: audio, video, image, document, code, archive, executable, font, 3d, data
Parameters: file_type (required), query, path, max_results, sort
everything_find_recent - what changed?Periods: 1min … 12hours, today, yesterday, 1day … 1year
Parameters: period (default 1hour), path, extensions, query, max_results
everything_file_details - deep inspectionParameters: paths (required, 1-20), preview_lines (0-200)
Returns full metadata; for directories, item count and listing; for text files with a preview, the first N lines.
everything_count_stats - quick analyticsParameters: query (required), include_size (default true), breakdown_by_extension
Count and size stats without listing every file - check scope before a big search.
Ask | Call |
Python files modified today in my project |
|
How much space do my log files use? |
|
First 50 lines of a config file |
|
Duplicate filenames in Documents |
|
Images larger than 5MB |
|
"es.exe not found" - Install Everything and es.exe, or set EVERYTHING_ES_PATH.
"Everything IPC window not found" - Make sure Everything is running (check the system tray). If you set EVERYTHING_INSTANCE, try removing it - most installs don't need it. Everything Lite doesn't support IPC.
No results for valid queries - Confirm Everything's index has finished building, try the same query in Everything's GUI, and check the drive/path is included in Everything's index settings.
Debugging:
everything-mcp 2>everything-mcp.log # server logs
npx @modelcontextprotocol/inspector uvx everything-mcp # MCP Inspectorpip install -e ".[dev]" # install with dev dependencies
pytest # run tests
ruff check src/ tests/ # lintContributions welcome - see CLAUDE.md for the architecture and design decisions. Areas of interest: direct named-pipe IPC, Everything SDK3 for 1.5, content search, file-watching, bookmark/tag support.
MIT - see LICENSE
voidtools for Everything, Anthropic for the Model Context Protocol, and the MCP community.
Get count and size statistics for files matching a query.
Fast way to understand the scope of a query without listing every file. Optionally breaks down by extension for a high-level overview.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the useful behavioral context that no file list is returned and that breakdowns are high-level, but it does not disclose the top-200 sampling behavior for breakdowns, which is left to the parameter schema. No contradictions exist.
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?
Three short, purposeful sentences. The main purpose is front-loaded, the second sentence establishes when to use it, and the third maps to an optional parameter. There is no filler or redundant explanation.
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?
The description, combined with the rich parameter schema, safety annotations, and available output schema, gives an agent everything needed to select and invoke this tool correctly. No critical usage or behavioral information is missing.
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 visible nested schema actually provides strong descriptions for all three parameters: query syntax examples, the include_size boolean, and the breakdown_by_extension behavior. The description itself only echoes the extension-breakdown option and adds no extra meaning beyond the schema, so the baseline 3 applies.
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 opens with a concrete verb and resource: 'Get count and size statistics for files matching a query.' It also distinguishes itself from sibling search tools by explicitly saying it works 'without listing every file,' so an agent can tell it apart from everything_search and similar listing-oriented tools.
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 gives a clear decision context: use it as a 'fast way to understand the scope of a query without listing every file.' This implies the main alternative is a file-listing search, but it does not name sibling tools explicitly or state exclusions, so it stops 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.
Get detailed metadata and optional content preview for specific files.
Returns: full path, size, dates, type, permissions, hidden status. For directories: item count, subdirectories, file listing. For text files with preview_lines > 0: first N lines of content.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive, so the description does not need to restate that. It adds meaningful behavioral details beyond the annotations: directory previews include item counts and listings, and text files can return the first N lines. No contradiction with annotations.
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 compact: a purpose sentence followed by short return/conditional bullets. Every sentence adds value, and there is no fluff or tautological restatement of the tool name.
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 that an output schema is present and the annotations cover the safety profile, the description is complete enough for correct invocation. It covers files, directories, and textual previews, which are the main paths through this tool.
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 description adds semantic meaning to preview_lines by explaining that it returns the first N lines for text files, and clarifies that paths refer to specific files/folders. The schema supplies the numeric constraints, so the description complements rather than merely repeats the 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 opens with a concrete verb-and-resource statement: 'Get detailed metadata and optional content preview for specific files.' It then enumerates exactly what is returned, which makes the tool's purpose unmistakable and distinguishes it from the sibling search/count tools.
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 communicates a clear context: use this when you have specific file or folder paths and want metadata or a preview. It does not explicitly name alternatives or state 'don't use for search,' but the 'for specific files' scope and the sibling tool names make the boundary obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find files modified within a recent time period.
Ideal for discovering what changed in a project, tracking recent downloads, finding today's log files, etc. Sorted newest-first.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive behavior. The description adds useful behavior beyond annotations: results are 'Sorted newest-first' and the scope is modification time within a window. No contradiction with the annotations.
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?
Three short front-loaded sentences with no filler: purpose, use cases, and sort order. Every sentence earns its place.
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 read-only search tool with a full input schema and output schema, the description supplies the missing conceptual context (use cases and ordering) without needing to restate return values. It could add a note about defaults or combining filters, but those are covered in the schema.
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 reported at 0%, so the prose should compensate, but it never mentions path, query, period syntax, extensions, or max_results. The schema does provide property descriptions, yet the description itself adds no parameter guidance beyond 'recent time period.'
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 opens with a specific verb and resource: 'Find files modified within a recent time period.' It also gives concrete use cases and notes the sort order, which clearly separates it from siblings like everything_search or everything_search_by_type.
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?
It explicitly frames when the tool is appropriate ('Ideal for discovering what changed... tracking recent downloads, finding today's log files'). It does not, however, name sibling alternatives or state when not to use it, so it stops short of full routing guidance.
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 instantly using voidtools Everything.
Leverages Everything's real-time NTFS index for sub-millisecond search across all local and mapped drives. Supports wildcards, regex, size/date filters, extension filters, and path restrictions.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds real behavioral context beyond that – it searches a live real-time NTFS index, so results reflect current disk state, and it enumerates what query capabilities exist (wildcards, regex, size/date, extension, path). It does not discuss result volume, paging behavior, or that the query language differs from plain text.
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?
Three short, front-loaded sentences with the verb and resource first and no filler. 'Sub-millisecond' is mildly promotional but still conveys a useful performance trait, so it earns its place.
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?
An output schema exists, so return values need not be explained, and annotations carry the safety profile. What is missing is routing information relative to the four sibling search/stats/details tools, which is the main context an agent needs to pick this tool correctly.
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 reported coverage of 0% understates reality: the nested SearchInput schema richly documents every parameter (query syntax with examples, sort enums, max_results bounds, pagination offset). The description's capability list ('wildcards, regex, size/date filters, extension filters, and path restrictions') largely mirrors what the schema already explains, so it adds little new parameter meaning. Baseline 3 is appropriate when the schema does the heavy lifting.
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 first sentence gives a clear verb+resource ('Search for files and folders') and names the underlying engine (voidtools Everything), which tells an agent exactly what domain this covers. It does not, however, differentiate itself from siblings like everything_search_by_type or everything_find_recent, so an agent must infer where this general search ends and the specialized tools begin.
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 explicit when-to-use or when-not-to-use guidance, and none of the four sibling tools are named as alternatives. Usage is only implied by the word 'Search', leaving the agent to guess whether this or everything_search_by_type/find_recent is the right entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for files by type category.
Categories: audio, video, image, document, code, archive, executable, font, 3d, data. Each maps to a curated list of file extensions.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the useful detail that each category resolves to a curated extension list (explaining why results may not match a naive extension guess), but says nothing about result limits or pagination behavior.
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?
Two short sentences, purpose front-loaded and the category vocabulary listed compactly. The trailing clause about curated extension lists earns its place, though the category list is redundant with the schema.
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 rich annotations, an output schema, and per-parameter schema descriptions, the description only needs to establish purpose and the category vocabulary, which it does. It is complete enough to call correctly; only the interplay with the general search sibling and result-limiting behavior are unaddressed.
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 file_type parameter's own schema description already lists the exact same ten categories, and path/sort/query are documented in the schema as well, so the description largely duplicates structured data rather than adding meaning. It adds nothing about that duplication problem or about max_results, which has no description anywhere.
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?
States a specific verb and resource ('Search for files by type category') and enumerates the ten valid categories, so an agent knows exactly what the tool returns. It stops short of contrasting itself with the sibling everything_search, which is a plain query-based search, so the differentiation must be inferred.
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?
Usage is implied by the category framing – call this when you want files of a known media/type class rather than matching arbitrary name patterns. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g. use everything_search for text queries), so the routing decision is left to inference.
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.
v1.0.9everything_search5 fields changedInput schema / $defs / SearchInput / properties / query / descriptionPrevious value: -"Search query using Everything syntax. Examples: '*.py' (all Python files), 'ext:py;js path:C:\\Projects' (Python/JS in Projects), 'size:>10mb ext:log' (large logs), 'dm:today ext:py' (Python files modified today), 'content:TODO ext:py' (files containing TODO - requires content indexing), '\"exact phrase\"' (exact filename match), 'regex:test_\\d+\\.py$' (regex). Combine with space (AND) or | (OR). Prefix ! to exclude."New value: +"Search query using Everything syntax. Examples: '*.py' (all Python files), 'ext:py;js path:C:\\Projects' (Python/JS in Projects), 'size:>10mb ext:log' (large logs), 'dm:today ext:py' (Python files modified today), '\"exact phrase\"' (exact filename match), 'regex:test_\\d+\\.py$' (regex). Combine with space (AND) or | (OR). Prefix ! to exclude. Functions that read files from disk (content:, width:, height:, music tags, and dc:/da:/attrib: unless indexed) need a path:/ext: filter and only run on small candidate sets."Input schema / $defs / SearchInput / properties / sort / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / $defs / SearchInput / properties / sort / defaultPrevious value: -"date-modified-desc"New value: +nullInput schema / $defs / SearchInput / properties / sort / descriptionPrevious value: -"Sort order. Options: date-created, date-created-asc, date-created-desc, date-modified, date-modified-asc, date-modified-desc, extension, name, name-desc, path, path-desc, size, size-asc, size-desc"New value: +"Sort order. Options: date-created, date-created-asc, date-created-desc, date-modified, date-modified-asc, date-modified-desc, extension, name, name-desc, path, path-desc, size, size-asc, size-desc. Default: date-modified-desc (name if Everything does not index date modified)."Input schema / $defs / SearchInput / properties / sort / typeRemoved value: -"string"everything_search_by_type4 fields changedInput schema / $defs / SearchByTypeInput / properties / sort / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / $defs / SearchByTypeInput / properties / sort / defaultPrevious value: -"date-modified-desc"New value: +nullInput schema / $defs / SearchByTypeInput / properties / sort / descriptionAdded value: +"Sort order. Options: date-created, date-created-asc, date-created-desc, date-modified, date-modified-asc, date-modified-desc, extension, name, name-desc, path, path-desc, size, size-asc, size-desc. Default: date-modified-desc (name if Everything does not index date modified)."Input schema / $defs / SearchByTypeInput / properties / sort / typeRemoved value: -"string"v1.0.7everything_count_statseverything_file_detailseverything_find_recenteverything_searcheverything_search_by_typeScored across 5 tools
Each tool has a reasonably distinct role, but everything_search_by_type and everything_find_recent are essentially presets of everything_search (extension filters, date filters), so an agent could occasionally wonder which to pick. The descriptions do clarify the convenience intent, keeping ambiguity minor.
All tools share a consistent 'everything_' prefix with snake_case verb/noun structure (search, search_by_type, count_stats, file_details, find_recent). The pattern is predictable throughout.
Five tools is well-scoped for a file-search server: general search, type-filtered search, statistics, detailed metadata, and recency. Each earns its place without redundancy bloat.
The surface covers the core lifecycle of finding and inspecting files (search, filter, count, inspect, recent). Minor gaps exist, e.g. no direct content/grep search beyond preview lines, and no index/volume management, but these are largely workable.
AI tool directory MCP server, live since July 2026. Tools, agents, models, companies, services.
MCP registry & directory: search, find & install 31k+ MCP servers & tools. Catalog and marketplace.
MCP server for agentverse documentation, generated by doc2mcp.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
