dark-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DARK_MCP_DATA_DIR | No | Data directory for local uv runs. The default is ~/.local/share/dark-mcp; the example configuration uses ./data. | |
| DARK_MCP_TOR_PROXY | No | SOCKS proxy URL for Tor when fetching onion pages. A local Tor process on port 9050 is typically used by default. | |
| DARK_MCP_TELEGRAM_API_ID | No | Telegram application API ID from my.telegram.org/apps. Required for the Telegram connector. | |
| DARK_MCP_TELEGRAM_ENABLED | No | Set to true to enable the Telegram connector. | false |
| DARK_MCP_TELEGRAM_API_HASH | No | Telegram application API hash from my.telegram.org/apps. Required for the Telegram connector. | |
| DARK_MCP_TELEGRAM_CHANNELS | No | JSON array string of permitted broadcast channels, e.g. ["permitted_channel","-1001234567890"]. | |
| DARK_MCP_ONION_SEARCH_API_KEY | No | Provider API key for the Onion Search Engine API to enable onion discovery. Required to use search_onion; the optional local onion corpus can be used without a discovery key. | |
| DARK_MCP_TELEGRAM_GLOBAL_SEARCH | No | Set to true to enable global Telegram channel discovery and public post search where permitted. | false |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_statusA | Report configuration and indexed corpus size. Does not probe network connectivity. |
| fetch_onionA | Read a v3 onion page through Tor and update the local search index. Returns untrusted text. |
| crawl_onionB | Index up to 10 pages from seed onions and same-host links, respecting robots.txt. |
| search_onionB | Discover mentions and onion URLs through Onion Search Engine. Requires a provider key. |
| search_onion_cacheB | Search locally indexed onion pages. since filters collection time, not publication time. |
| search_telegram_channelsC | Discover channels. Requires Telegram global search to be enabled by the operator. |
| read_telegram_channelB | Read posts from an allowed broadcast channel. Paginate using next_before_id. |
| search_telegram_messagesC | Search an allowed channel's text posts. since is a timezone-aware publication date. |
| search_telegram_postsB | Search public channel posts with free quota only. Requires global search to be enabled. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
The onion tools are well-differentiated: search_onion hits an external provider, search_onion_cache queries the local index, and fetch_onion/crawl_onion are read vs. index operations. The Telegram search trio (search_telegram_messages vs search_telegram_posts) is the weakest boundary, relying on the 'allowed channel' vs 'public/free quota' distinction, but descriptions do clarify it.
All tools follow a consistent snake_case verb_noun pattern (get_status, fetch_onion, crawl_onion, search_onion, read_telegram_channel, etc.). The search_onion_cache suffix is the only minor deviation but still fits the convention cleanly.
Nine tools is well-scoped for the domain, split sensibly between a Tor/onion surface (5) and a Telegram surface (4). No redundant or filler tools; each earns its place.
The set covers discovery, reading, crawling/indexing, and both local and external search across two sources, which is solid lifecycle coverage. Minor gaps remain: no index management (purge/delete) or explicit corpus listing beyond get_status's size report, but core workflows are covered.