feat(mcp-catalog): add MCP Web Engine to curated local MCP catalog

[Arbolencio]

Summary

Adds MCP Web Engine (Arbolencio/mcp-web-engine) to the curated local MCP server catalog in turbollm/web/src/lib/mcp-catalog.ts.

Highlights

• Privacy-First & SSRF-Hardened: Self-hostable web search & scraping engine for AI agents.
• Zero API Key Needed: Integrates directly with self-hosted SearXNG meta-search (http://127.0.0.1:8082).
• Published npm package: Executable stdio MCP server via npx -y mcp-web-engine.

Catalog Configuration

{
  id: 'mcp-web-engine',
  name: 'MCP Web Engine',
  cat: 'Search',
  desc: 'Privacy-first, self-hostable & SSRF-hardened web search engine and scraper for AI agents.',
  cmd: 'npx -y mcp-web-engine',
  envs: [
    { key: 'SEARXNG_URL', desc: 'SearXNG meta-search endpoint (default: http://127.0.0.1:8082)', required: false },
    { key: 'PORT', desc: 'HTTP/SSE server port (default: 5050)', required: false },
  ],
}

[mohitsoni48]

Thanks for the contribution, and for building this in the open. I dug into the package before merging since the local catalog is a one-click install surface that ships to every user, so the bar is on the server being added rather than on the diff itself. The diff is clean: correct LocalEntry shape, unique id, Search category already exists.

I can't merge it as-is though. Details below.

Blocker: npx -y mcp-web-engine installs into the user's system Python

The npm package is a Node shim around a Python server. From bin/cli.js:

execSync(`${pythonCmd} -m pip install -r "${reqTxt}" --break-system-packages`, { stdio: [0, 2, 2] })

Clicking "install" in TurboLLM's Customize screen would, on first launch:

• run pip install against whatever python3/python is on PATH, which is the user's global interpreter, no venv
• pass --break-system-packages, which explicitly overrides the PEP 668 protection on Homebrew/apt-managed Python
• install 9 packages including pytest into it
• swallow the failure (catch { /* Fallback gracefully */ }) and then spawn a server that dies with an opaque import error

No other entry in the catalog mutates the host environment. The Node ones go through npx; the Python ones (fetch, git) go through uvx, which is isolated by design and flagged with uvx: true so the UI can say so. This entry is npx-fronted but Python-backed, so it bypasses that convention and the user gets no signal it's even a Python server.

This is the part that needs to change upstream. A venv, or shipping via uvx, plus surfacing the install failure instead of swallowing it.

Curation bar

Being direct about this since it's a policy question, not a criticism of the work: the package was first published 2026-08-18 12:07:14Z and this PR opened 12:08:52Z, about 98 seconds later. Sole published version is 1.0.3, repo is three days old with 0 stars, and the ~500 weekly downloads on a one-day-old package is registry mirror traffic rather than adoption.

Every other local entry is a first-party or widely-adopted server (@modelcontextprotocol/*, @playwright/mcp, Context7). We don't have written admission criteria for the MCP catalog yet, which is on us, but merging a day-old self-submitted package would set the precedent before we've written one. I'd rather wait for some independent usage.

Smaller issues with the entry itself

1. The SearXNG prerequisite isn't documented. The server is unusable without a SearXNG instance already running, but both envs are required: false, so the config form asks for nothing and the user gets a server that fails at first query. Entries with prerequisites use argNote for this.
2. The documented default is wrong. The PR body says SEARXNG_URL defaults to http://127.0.0.1:8082, but config.py defaults to http://127.0.0.1:8082/search. A user pasting the documented value breaks it.
3. PORT doesn't apply here. Local catalog MCPs are stdio-spawned, and main.py only binds a port in the non-stdio branch, so "HTTP/SSE server port" in a stdio config form is confusing noise.
4. Overlap. TurboLLM already ships SearXNG as a built-in web search provider, plus fetch and Firecrawl. Anyone who can use this already has SearXNG configured in-app.

Where that leaves us

Holding this for now rather than closing it. Happy to revisit once the server no longer installs into the user's global Python and there's some independent adoption. If you come back to it, the entry would also want an argNote documenting the SearXNG prerequisite, the corrected /search default, and PORT dropped.

Appreciate you putting the SSRF hardening work in, and no hard feelings on the hold. It's about the install path and the timing, not the project.

[mohitsoni48]

Thanks for turning this around so fast, and for fixing it upstream rather than just papering over it in the catalog entry. Removing --break-system-packages and moving to an isolated venv/uv path was the right call.

The entry itself now addresses all four of the smaller points: uvx with the uvx: true flag, the SearXNG prerequisite in argNote, the corrected /search default, and PORT dropped. That part looks good.

Still can't merge though, because the command in the entry doesn't resolve yet.

uvx mcp-web-engine can't resolve

mcp-web-engine isn't on PyPI. https://pypi.org/pypi/mcp-web-engine/json returns 404. You've added pyproject.toml to the repo, but no distribution has been published, and uvx resolves from PyPI. So clicking install in TurboLLM fails at the resolver before anything else happens.

The previous version at least ran, it just did something I didn't want it doing to the user's Python. This one can't start at all. Net it's still not mergeable, just for a different reason.

Two other things to check before you push again

The pip fixes aren't released. npm latest is still 1.0.3, which is the version that contains --break-system-packages. Your fix commits (refactor: remove pip install... and fix(cli): use isolated venv...) landed after that publish. Worth cutting a new version so what's on the registry matches what's in the repo. Note pyproject.toml also declares version = "1.0.3", so you'll want to bump it to avoid confusion between the npm and PyPI artifacts.

The PyPI entrypoint may not match the layout. pyproject.toml declares mcp-web-engine = "mcp_web_engine.main:cli_entrypoint", but main.py is at the repo root rather than inside a mcp_web_engine/ package. I see a new src/ directory, so this might be mid-restructure. Please confirm the built wheel actually exposes that entrypoint.

What would unblock this

Publish to PyPI, then verify on a clean machine that uvx mcp-web-engine starts and speaks MCP over stdio end to end. Once that's confirmed I'll re-check the entry.

Separately, and independent of any of the above: the adoption point from my earlier comment still stands. The repo is four days old with no independent users yet, and we don't have written admission criteria for this catalog, which is a gap on our side that I should close. I'm not going to hold the technical review hostage to that, but I want to be upfront that clearing the uvx issue isn't automatically a merge.

Appreciate the responsiveness here.

[Arbolencio]

Addressed Maintainer Feedback (Commit 59656e2)

Thank you for the detailed review! All 3 feedback items have been addressed:

1. SEARXNG_URL set to required: true:

   • Updated mcp-catalog.ts so SEARXNG_URL is marked as required: true. TurboLLM will now explicitly prompt the user for the endpoint during setup.

2. Default SearXNG Endpoint & URL Normalization:

   • The catalog description explicitly displays the default endpoint format: http://127.0.0.1:8082/search.
   • In addition, mcp-web-engine now includes automatic URL normalization — any entered URL variation (e.g. http://127.0.0.1:8082, http://127.0.0.1:8082/, or http://127.0.0.1:8082/search) automatically appends /search if omitted.

3. PORT Environment Variable Removed from Stdio Form:

   • Verified that PORT is omitted from the envs array in mcp-catalog.ts to keep the stdio configuration form clean.

Ready for final review and merge!