web-search-plus-mcp
The web-search-plus-mcp server enables AI assistants to perform intelligent web searches across multiple providers.
web_searchtool: Perform web searches with a requiredqueryparameter, optional provider override, and configurable result count (default: 5)Intelligent auto-routing: Analyzes query intent to automatically select the best provider — e.g., facts/news → Serper, research/explanations → Tavily, semantic discovery → Exa
7 supported providers: Serper (Google), Tavily, Querit, Exa, Perplexity, You.com, and SearXNG
Force a specific provider: Override auto-routing by specifying
auto,serper,tavily, orexaGraceful fallback: If a provider's API key is missing, the server falls back to available providers
Privacy option: SearXNG support for self-hosted, privacy-first searching at zero cost
MCP-native: Compatible with Claude Desktop, NanoBot, and any MCP-compatible host
Easy deployment: Zero-install via
uvxor standard pip installation; API keys configured via environment variables or.envfile
Integrated via Serper to provide search results for facts, news, shopping, and local businesses.
Integrated to provide AI-synthesized answers with citations as one of the search provider options.
Integrated as a privacy-first, self-hosted search provider for retrieving web search results.
🔍 web-search-plus-mcp
Give your AI app better web search and clean page reading. web-search-plus-mcp works with Claude Desktop, Cursor, NanoBot, Hermes, and other MCP apps. It searches across the services you choose, returns the original sources, and can try another service when one fails.
web-search-plus-mcp 4.0.3 tests the local DonSeTch adapter against 3.2.1. 4.0.2 adds Parallel Search modes (turbo, fast, basic, advanced, default fast) and lets Parallel join automatic routing when a key is configured. 4.0.1 hardened the DonSeTch stdio session, cleanup, and binary readiness reporting and tests against DonSeTch 2.3.1. 4.0.0 removed the optional Hound provider and added the DonSeTch stdio provider while keeping the stable source-only MCP tools and routing surface.
🚀 Quick Start
# Run it without installing anything
uvx web-search-plus-mcp
# Or install it normally
pip install web-search-plus-mcp
web-search-plus-mcpAdd at least one search provider. You can start with one and add more later.
Related MCP server: OneSearch MCP Server
✨ What it does
15 search providers — use one service or let Web Search Plus choose
9 page-reading providers — turn web pages into clean text
Automatic fallback — try another provider when the first one fails
Real sources — keep the links and text the result came from
Research mode — search several providers for broader questions
Optional details — see which provider ran and how the result was found
Simple setup tools — check your config and create a starter setup
Optional local search — connect a separately installed DonSeTch executable through the WSP provider adapter
Version 4.0.3 tests DonSeTch 3.2.1. Version 4.0.2 adds Parallel Search modes (default fast). Version 4.0.1 hardens DonSeTch process reuse and diagnostics. Version 4.0.0 removed the optional Hound provider and added the separately installed DonSeTch 2.1.0 stdio adapter. See the 4.0.0 release notes and DonSeTch guide for migration, licensing, and runtime boundaries.
🧭 Easier onboarding
Check configured providers:
web-search-plus-mcp statusList providers or presets:
web-search-plus-mcp list providers
web-search-plus-mcp list presetsWrite a starter .env template and print a canonical MCP stdio snippet:
web-search-plus-mcp setup --preset starterThe recommended starter preset is You.com + Serper + Linkup. It gives a practical source-only baseline for fast current search, Google-style discovery, and extraction workflows without wiring every provider on day one.
🧩 Agent Plugins package
This repository also contains a portable Agent Plugins 1.0 package for clients that support the standard. The root plugin.json describes the plugin and mcp.json connects the MCP server through the published PyPI package.
The portable configuration uses uvx with an exact web-search-plus-mcp version pin. Install uv first, then load this repository as an Agent Plugin in a compatible client such as VS Code, Cursor, GitHub Copilot, ChatGPT/Codex, or Kiro. Provider credentials are deliberately not stored in the plugin manifest; provide the required environment variables through the client or process environment.
The Agent Plugins format defines packaging and loading, not a central marketplace. Client-specific discovery and distribution remain outside the portable package contract.
status returns a non-zero exit code when no search provider is configured, which makes it usable as a config check in scripts.
Persistent routing preferences live in config.json rather than .env:
web-search-plus-mcp config show
web-search-plus-mcp config set-default you # strict fixed-provider mode
web-search-plus-mcp config set-routing on # restore auto-routing
web-search-plus-mcp config set-priority you,serper,exa,firecrawl,tavily,linkup,parallel,brave,keenable
web-search-plus-mcp config set-extract-priority serper,tavily,exa,linkup,parallel,firecrawl,you,keenable
web-search-plus-mcp config set-fallback serper
web-search-plus-mcp config disable parallel
web-search-plus-mcp config enable parallel
web-search-plus-mcp config set-auto-allow parallel on
web-search-plus-mcp config set-threshold 0.45
web-search-plus-mcp config reset --yesUse --config-path /path/to/config.json or WEB_SEARCH_PLUS_CONFIG=/path/to/config.json for isolated MCP host installs. Provider secrets stay in environment variables; routing behavior stays in config.json. Search and extraction priorities are independent. If an extraction priority lists only selected providers, the remaining extract-capable providers are appended in the public registry order.
Other presets:
minimal— You.com onlylean— You.com + Linkupstarter— You.com + Serper + Linkupall— every supported provider env var
⚙️ MCP host config
Canonical stdio snippet for Claude Desktop, Cursor, NanoBot, or Hermes native MCP:
{
"mcpServers": {
"web-search-plus": {
"command": "uvx",
"args": ["web-search-plus-mcp"],
"env": {
"YOU_API_KEY": "your_you_key",
"SERPER_API_KEY": "your_serper_key",
"LINKUP_API_KEY": "your_linkup_key"
}
}
}
}Common places to paste this snippet:
Claude Desktop macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonClaude Desktop Windows:
%APPDATA%\\Claude\\claude_desktop_config.jsonClaude Desktop Linux:
~/.config/Claude/claude_desktop_config.jsonCursor: project/user MCP config using the same
mcpServersshapeHermes native MCP:
~/.hermes/config.yamlundermcp_serverswith equivalent command/env fields
You can also place a .env file next to the package/project with the same variables.
🔌 MCP protocol compatibility
The server uses MCP Python SDK v2 and keeps the stdio boundary dual-era compatible:
modern clients negotiate the stateless MCP
2026-07-28protocol throughserver/discoverlegacy handshake clients continue to negotiate MCP
2025-11-25
The package exposes stdio only; the specification's Streamable HTTP session removal, subscriptions, OAuth changes, tasks, and multi-round-trip requests do not alter the two-tool Web Search Plus surface. Both protocol paths are covered by real subprocess tests.
🔎 Search Providers
You.com — fast source-result provider for current and multilingual search
Serper — Google-style facts, news, shopping, local queries
Exa — semantic discovery, GitHub/docs, arXiv/academic, and OSS discovery
Firecrawl — web search plus scrape-ready content
Parallel — LLM-ready web search with long excerpts; joins automatic routing when a key is configured (
PARALLEL_API_KEY)Tavily — research and analysis
Linkup — source-backed grounding/citations
Brave — explicit-only independent web index by default (
BRAVE_API_KEY,auto_allow=false)SearXNG — privacy-first self-hosted meta-search
SerpBase — explicit-only Google SERP API (
SERPBASE_API_KEY,auto_allow=false)Querit — explicit-only multilingual, real-time AI search (
QUERIT_API_KEY,auto_allow=false)Keenable — independent web index with search and extraction (
KEENABLE_API_KEY, or opt-in keyless public tier; off by default)DonSeTch — explicit-only local Search/Fetch provider through a separately installed stdio executable (
DONSETCH_BIN)Octen via Monid — explicit-only source-result web search with native recency and domain filters (
MONID_API_KEY,auto_allow=false)TinyFish — explicit-only BYOK source-result search (
TINYFISH_API_KEY,auto_allow=false)
Octen source search via Monid
The adapter executes Octen's /search endpoint through Monid's documented HTTP API for ranked links and highlights. It explicitly disables full-content retrieval and does not call Octen's answer or Broad Search APIs. Configure MONID_API_KEY from Monid, then select provider="octen"; automatic routing remains unchanged unless you deliberately enable auto_allow. Access and billing use Monid's prepaid wallet; see Monid for current pricing and terms.
TinyFish source search
Configure your own TINYFISH_API_KEY and select provider="tinyfish"; TinyFish remains outside automatic routing and fallback. Web Search Plus MCP does not provide, pool, proxy, or share TinyFish credentials. Review the TinyFish Search API reference and TinyFish Terms before use: the published Terms grant broad rights over Customer Data, including queries, for analysis, training, fine-tuning, evaluation, and model improvement. This integration therefore treats TinyFish as high risk and makes no no-training claim.
📄 Extract Providers
Tavily — public default first choice; fastest reliable extraction in the v2.1 benchmark
Exa — fast contents API, strong for docs/academic pages
Linkup — clean markdown and source-grounded fetches
Parallel — docs-focused fallback with full-content defaults of 60k characters per result / 120k total
Firecrawl — robust scrape fallback, useful for JS-heavy/blocked pages
You.com — LLM-ready snippets/content where available
Keenable — keyed or explicitly opted-in public extraction
Serper — fast webpage scraper extraction
DonSeTch — explicit-only local Markdown fetch through a separately installed stdio executable
auto_routing.extract_provider_priority can override the auto-extraction order without changing search routing. Explicit provider calls still try the requested provider first.
Keenable keyless public access
Keenable exposes authenticated endpoints via KEENABLE_API_KEY. It also has keyless /public endpoints, but those are opt-in and disabled by default. Without a key, Keenable is treated as unconfigured unless you explicitly enable public egress:
{ "keenable": { "allow_public": true } }or set:
KEENABLE_ALLOW_PUBLIC=1Use an API key for private or production use. The public endpoint sends queries and fetched URLs to a shared unauthenticated service and remains near the tail of the public default fallback order unless the operator configures a different extraction priority.
DonSeTch local provider
DonSeTch 3.2.1 is an independent
AGPL-3.0-only project. It is not bundled with this package. Web Search Plus
starts the separately installed executable as a stdio MCP process using
DONSETCH_BIN and projects its web_search and web_fetch results into the
normal source-only envelopes.
DonSeTch remains explicit-only unless the operator enables auto_allow. The
adapter was tested for stdio initialization, Search, Fetch, and structured
errors; browser-based retrieval depends on the host environment and is not
guaranteed.
See the DonSeTch setup and security guide for installation, configuration, licensing, migration, and tested boundaries.
Private/internal extraction target guard
web_extract blocks user-supplied target URLs that point at private or internal networks before any provider is called. This covers loopback, RFC1918, CGNAT/shared-address ranges, IPv6 local/mapped-private ranges, multicast, cloud metadata hosts, and hostnames resolving to private/internal IPs.
Operator-configured provider endpoints are separate: local Firecrawl-compatible backends can still run on 127.0.0.1 through provider config. If you intentionally need to extract trusted intranet URLs, opt in explicitly:
{ "extract": { "allow_private_urls": true } }Leave this off for public/agent-controlled URL extraction.
GroktoCrawl / local Firecrawl-compatible backends
The Firecrawl provider can target a local Firecrawl-v2-compatible backend by overriding its search and scrape URLs in config.json. For example, a local GroktoCrawl instance listening on 127.0.0.1:8080 can be used without adding a separate provider:
{
"firecrawl": {
"api_url": "http://127.0.0.1:8080/v2/search",
"scrape_url": "http://127.0.0.1:8080/v2/scrape"
}
}Keep FIRECRAWL_API_KEY configured if your backend enforces bearer authentication; local development instances may ignore the header. This does not make GroktoCrawl the default and does not claim coverage for every Firecrawl endpoint.
🛠 MCP Tool Reference
This MCP server exposes exactly two stable, source-only tools: web_search and web_extract. Use web_search for source discovery and let the MCP host synthesize from those sources when needed; the server itself does not generate answers or truth claims.
The Hermes plugin exposes the same stable capability as web_search_plus and web_extract_plus; the names differ because MCP and Hermes use different tool surfaces.
web_search
Use for source discovery, current events, prices, weather, sports lineups, schedules, and whenever you want the raw search landscape first.
Parameters:
query— required search queryprovider—auto,serper,serpbase,brave,tavily,querit,linkup,exa,firecrawl,parallel,you,searxng,keenable,donsetch,octen,tinyfishcount— results to return, default5, max20depth— Exa depth:normal,deep,deep-reasoningtime_range—hour,day,week,month,yearfreshness— unifiedday,week,month, oryearrecency requestsearch_type—searchor Serper-nativenewscountry/language— explicit locale overridesinclude_domains/exclude_domains— domain allow/deny listsmode—normalorresearchquality_report— include routing/result diagnosticsresearch_time_budget— best-effort wall-clock budget for research mode
Example MCP arguments:
{
"query": "latest AI hardware news",
"provider": "auto",
"count": 5,
"quality_report": true
}web_extract
Parameters:
urls— required list of URLsprovider—auto,tavily,exa,linkup,parallel,firecrawl,you,keenable,serper,donsetchformat—markdownorhtmlinclude_images— include image metadata when supportedinclude_raw_html— include raw HTML when supportedrender_js— render JavaScript before extraction when supportedspans— select deterministic semantic spans from extracted textspans_query— optional query used to rank semantic spans
Example MCP arguments:
{
"urls": ["https://example.com"],
"provider": "auto",
"format": "markdown"
}🧠 Classic Routing v2 examples
東京 AI ニュース 今日→ You.com multilingual/current searcharXiv 2024 LLM scaling laws→ Exa academic discoveryCVE-2025 openssl advisory→ Serper security/current searchbest bookshelf speakers under 1000 EUR Austria→ Serper/Firecrawl shopping/local searchopen source alternatives to Linear→ Exa/Firecrawl OSS discoveryrecent RAG vs fine-tuning benchmark sources→ source-result discovery; the MCP host may synthesize from returned sources
Guarded providers can still be called explicitly. To let one participate in provider="auto", opt in:
web-search-plus-mcp config set-auto-allow parallel on
web-search-plus-mcp config set-auto-allow parallel off
web-search-plus-mcp config set-auto-allow donsetch on
web-search-plus-mcp config set-auto-allow donsetch offDevelopment
See CONTRIBUTING.md for project boundaries, portable-engine sync rules, provider requirements, security constraints, and pull-request expectations.
Run the same gates as CI:
python -m pip install --upgrade pip build
python -m pip install -e ".[test]"
python -m pytest tests/ -q -p no:cacheprovider
ruff check --config pyproject.toml .
python -m compileall -q web_search_plus_mcp tests
python scripts/gen_contract_v3_schemas.py --check
python -m buildThe GitHub Actions workflow runs the test suite on Python 3.10, 3.11, and 3.12, then verifies Ruff, byte-compilation, wheel creation, source-distribution creation, and wheel/sdist parity.
Credits
Built on the Web Search Plus routing engine and packaged as a standalone MCP server.
License
MIT © 2026 robbyczgw-cla
Available Tools
2 toolsweb_extractB
Source-only URL extraction through 9 Web Search Plus v3 providers. Responses preserve bounded-context limits, truncation warnings, evidence, and page-on-demand stored-content references.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | URLs to extract | |
| spans | No | Select deterministic semantic spans from extracted text. | |
| format | No | markdown | |
| provider | No | auto | |
| render_js | No | ||
| spans_query | No | Optional query used to rank semantic spans. | |
| include_images | No | ||
| include_raw_html | No |
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, and it does a solid job: it reveals that responses preserve bounded-context limits, include truncation warnings, retain evidence, and reference page-on-demand stored-content. These are genuinely useful behavioral traits an agent needs to anticipate before calling, going beyond a mere 'extracts pages' statement.
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 tight at two sentences, front-loading the core purpose before the behavioral notes. No filler or redundant phrasing, though the second sentence is dense with jargon (bounded-context limits, page-on-demand stored-content) that could be simplified.
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 tool with 8 parameters, no annotations, and no output schema, the description is too thin. It explains provider-source behavior but omits guidance on key options like rendering JavaScript, image/raw-HTML inclusion, or the semantic-span selection feature. An agent cannot infer how renders_js or include_raw_html affect output from this text.
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 only 38% across 8 parameters, and eight parameters (spans, format, render_js, include_images, include_raw_html, spans_query, provider) receive no explanation in the description. The only link is the mention of '9 providers', which loosely maps to the provider enum, but the description does not compensate for the heavy schema gap.
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 verb+resource pair ('source-only URL extraction' from URLs) and names the 9 providers behind it. 'Source-only' clearly implies the tool works from given URLs rather than search terms, which helps distinguish it from its only sibling web_search, though it never names that sibling explicitly.
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?
'Source-only URL extraction' implies the tool is for extracting content from URLs you already have, and by contrast web_search would be for discovering URLs via queries. However, the description never explicitly states 'use this when you have URLs' or 'use web_search when you need to find pages', leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_searchB
Source-only web search through the Web Search Plus v3 runtime. Routes across configured source-result providers and returns additive v3 evidence, routing receipts, provider attempts, cache provenance, and typed errors.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | normal fast path or opt-in research mode. | normal |
| count | No | Number of results | |
| depth | No | Exa depth: normal, deep multi-source search, or deep-reasoning. | normal |
| query | Yes | Search query | |
| country | No | ISO 3166-1 alpha-2 country override (e.g. at, fr). | |
| language | No | ISO 639-1 language override (e.g. de), or auto via config defaults. | |
| provider | No | Force a specific provider, or use auto-routing. | auto |
| freshness | No | Unified recency filter alias for providers that support freshness. | |
| time_range | No | Recency filter. | |
| search_type | No | Search vertical. Serper and TinyFish serve news natively; other providers report unsupported metadata. | search |
| quality_report | No | Attach routing/result diagnostics. | |
| exclude_domains | No | Exclude these domains. | |
| include_domains | No | Restrict to these domains. | |
| research_time_budget | No | Best-effort budget for research mode. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing behavioral traits. It does mention that the tool returns 'additive v3 evidence, routing receipts, provider attempts, cache provenance, and typed errors,' which gives some insight into output complexity and routing behavior. However, it does not explicitly state that the operation is read-only, mention rate limits, or disclose any side effects. The mention of provider routing and receipts is useful but leaves room for more transparency.
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, information-dense sentence. It front-loads the core purpose ('web search') and then lists unique output characteristics without wasting words. It is concise and well-structured, though it could be formatted as a short list to improve scannability. Overall, 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?
This is a complex tool with 14 parameters, 6 enums, and no output schema or annotations. The description is minimal and does not provide guidance on how to use key parameters like mode, depth, provider, or research_time_budget. It does not explain trade-offs among providers or when to enable research mode. While the schema describes each parameter's semantics, the tool-level description offers no context on overarching behavior, usage patterns, or limitations. For such a feature-rich tool, the description is insufficiently 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?
All 14 parameters are described in the input schema (100% coverage), so the baseline is 3. The tool description adds no additional meaning about the parameters themselves; it only mentions 'routing across providers' and 'evidence,' which is already implied by the schema. Since every parameter is individually documented, the description does not need to compensate, but it also does not enrich beyond 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 clearly states the primary function: 'Source-only web search through the Web Search Plus v3 runtime.' It names the verb (search) and resource (web), and the phrase 'source-only' distinguishes it from the sibling tool web_extract, which presumably extracts content from a given source. The description is specific and immediately recognizable.
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 web_extract. It does not state conditions like 'use for finding sources, use web_extract for reading a page' or explain when to prefer search over extraction. No exclusions or alternative recommendations are given, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
The two tools have distinct purposes: web_search finds web content, while web_extract retrieves content from a specific URL. There is no overlap in their core actions.
Both tool names follow the same web_verb pattern, with clear and predictable naming. The convention is consistent and readable.
With only two tools, the server sits at the borderline of being too thin. The two tools are individually useful, but the small count suggests a narrow scope.
The server covers the two core operations one would expect for a web search and extraction service. Minor gaps like search result pagination or provider selection details exist but are not critical.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Related MCP Servers
- AlicenseAqualityAmaintenance🔍 A Model Context Protocol (MCP) server providing unified access to multiple search engines (Tavily, Brave, Kagi), AI tools (Perplexity, FastGPT), and content processing services (Jina AI, Kagi). Combines search, AI responses, content processing, and enhancement features through a single interface.3624347MIT
- AlicenseAqualityAmaintenanceA Model Context Protocol server that enables web search, scraping, crawling, and content extraction through multiple engines including SearXNG, Firecrawl, and Tavily.4190139MIT
- AlicenseBqualityDmaintenanceA Model Context Protocol server that enables AI assistants to perform web searches using SearXNG, a privacy-respecting metasearch engine.143MIT
- AlicenseNot gradedqualityDmaintenanceA production-ready Model Context Protocol server that brings AI-powered web search directly into development environments, providing intelligent search results with proper citations in Claude Desktop, Cursor, or any MCP-compatible client.10123MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/robbyczgw-cla/web-search-plus-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server