
Onion Search
io.github.farbodghasemluPublished by GitHub account farbodghasemluv1.0.1Updated Oct 24, 2026
Local, read-only onion search and text retrieval over Tor with content filtering.
Overview
A local, read-only MCP server that searches onion services and retrieves page text through Tor, with content filtering on by default.
- What you can do
- Search onion services across eight configured engines, with ranked results, engine agreement and per-engine failures. Fetch a page as Markdown text with title, links and response metadata, or check reachability, HTTP status and latency. List onion and optional clearnet links from a page without following them. Check Tor health: SOCKS handshake, bootstrap percentage and version. Read two in-memory resources listing enabled engines and the last 100 queries in the process.
- When to use it
- Useful for research that needs to query and read onion sites through Tor from an AI assistant, with text-only retrieval and filtering. Suited to users who can run Docker or a local Python environment with Tor and accept the legal and privacy responsibility of such searches.
- Requirements
- Runs as a local stdio process, typically via Docker Compose with a Tor sidecar, a bundled container, or a local Python install with Tor and libseccomp2. Tor must expose SOCKS and control ports; TOR_CONTROL_PASSWORD or TOR_COOKIE_FILE may be needed. Optional settings include TOR_BRIDGES, ENGINES, CONTENT_FILTER and cache and timeout variables. Initial Tor bootstrap can take several minutes.
Installation
In SourceWeft
- Open Onion Search in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
darkweb-mcp (onion-search-mcp)
A local Python stdio MCP server for searching onion services and reading pages through Tor. It provides five tools, eight search adapters, memory caches, and two MCP resources.
[!IMPORTANT] Privacy: Use a local model for sensitive searches. Cloud models may receive your queries and fetched content through the MCP client. Check the client's logging, telemetry, and cloud fallback settings.
[!WARNING] User responsibility: You are responsible for your actions and compliance with applicable laws. The authors and contributors disclaim liability for use or misuse of this software to the extent permitted by law.
Run
The two-container setup gives the MCP process an internal Docker network. Only the Tor container has an external route.
Wait for docker compose ps to show Tor as healthy before starting the server. The server uses stdin and stdout for MCP messages. Keep stdout attached to the client.
For a single container with Tor included:
The bundled container has an external route because Tor needs one. Use Compose for network isolation between the server and Tor. Initial Tor bootstrap can take several minutes.
For a local Python installation on Linux, install Tor and libseccomp2, then:
To use an existing Tor process, configure SocksPort 9050 IsolateSOCKSAuth, ControlPort 9051, and control authentication, then run uv run onion-search-mcp. Set TOR_CONTROL_PASSWORD or TOR_COOKIE_FILE if needed.
Content filtering switch
Filtering is enabled by default. Turn it off or on for the process with either environment configuration or CLI options:
Each content tool also accepts content_filter. Pass false to disable filtering for that call, true to enable it, or omit it to use the process setting.
The switch controls domain blocklists and keyword rules. Tor routing, URL validation, text-only retrieval, parser limits, and untrusted-content wrapping always apply. Search engines may apply their own filtering. Cache entries are separated by filter setting.
MCP client configuration
Start the Tor sidecar with docker compose up -d tor, then configure a stdio client:
For the bundled image, use docker run -i --rm onion-search-mcp:local as the command and arguments. For Python, use uv --directory /absolute/path/to/onion run --frozen onion-search-mcp. Tool approval is configured in the client.
Tools
Configuration
Privacy and limits
All HTTP requests use remote DNS through SOCKS, with credentials derived from a random process session and each destination. Tor must use IsolateSOCKSAuth. A SOCKS credential separates streams but does not guarantee a new physical circuit for every request. NEWNYM is requested at shutdown; Tor may rate limit that signal.
The HTTP client stores no cookies and sends no Referer. It performs GET requests only. It does not execute JavaScript, submit forms, follow links automatically, render images, or decode media. Responses are streamed with byte limits and read and total deadlines. Redirect targets are validated before a request is made.
HTML parsing runs in a separate Linux process with a 384 MiB address-space limit, 8 seconds of CPU, a 10-second deadline, and seccomp rules that deny network syscalls. Scripts, styles, comments, embedded objects, and hidden elements are removed. Untrusted text is wrapped with a fresh delimiter. These measures do not prove that a page contains no prompt injection or that a link is legitimate.
Query history and caches stay in memory and are cleared on shutdown. No telemetry, query logging, disk cache, or runtime update checks are implemented. The MCP client and model runtime have their own storage and network behavior; see the privacy notice above.
Blocklists and literal keywords do not detect all abusive content. Links are research leads; engine agreement is a ranking signal.
Development
The unit suite uses saved parser fixtures and a local SOCKS simulator. The leak test stops the proxy and asserts that connections target only the local proxy, with no destination DNS or direct HTTP connection. CI runs integration on a private local Tor network. The test publishes a temporary onion service containing only fixtures. It never queries public search engines or reads third-party onion pages.
An existing test Tor instance can be supplied with TEST_TOR_SOCKS and TEST_TOR_CONTROL. Integration requires a usable Tor circuit and can fail when the network is unavailable. See testing.
Stable errors include TOR_UNAVAILABLE, INVALID_ONION, BLOCKED, TIMEOUT, ALL_ENGINES_FAILED, UNSUPPORTED_CONTENT, INVALID_QUERY, INVALID_ENGINE, INVALID_INPUT, CONFIG_ERROR, RESPONSE_TOO_LARGE, REDIRECT_LIMIT, PARSE_FAILED, and PARSE_TIMEOUT. Tool errors contain scrubbed code and message JSON. Partial searches include per-engine codes and return completed results.
License
MIT. See LICENSE.
Source: README.md at commit eff821c
Tools
0Version history
1- v1.0.1LatestOct 15, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts