Loading ToolBench
MCP server that routes LLM tool requests through Tor for anonymous web access
tor-mcp has well-structured tool definitions with complete input schemas and descriptions. All 4 tools follow verb_noun naming (tor_private_fetch, tor_check_anonymity, tor_new_identity, tor_privacy_status). Descriptions are substantive (100-200 chars), explaining WHAT the tool does and WHEN to use it. Input parameters have types, descriptions, and constraints (enums, patterns, min/max). However, output schemas are not documented, responses are formatted as JSON/Markdown strings rather than structured objects with typed fields. Error handling is present but generic. No per-tool risk annotations visible in schema definitions.
Verify Tor connection and show exit IP. Checks if Tor is running and returns the current exit IP address to verify anonymity.
Request a new Tor circuit (new exit IP). Rotates to a new Tor exit node, changing the exit IP address. Requires Tor control port access. Respects 10-second rate limit between rotations.
Show routing config and connection status. Displays the current Tor connection status, routing rules, and configuration.
Fetch a URL with privacy-aware routing through Tor. Automatically decides whether to route through Tor or direct based on URL pattern matching. Built-in rules route .onion through Tor, localhost direct, OSINT domains (Shodan, HIBP) through Tor, and Tor-blocking domains (GitHub, OpenAI) direct.
Output schemas not documented. Tools return formatted strings (JSON/Markdown) rather than structured objects with typed fields. LLMs cannot plan downstream tool calls or extract specific fields without parsing unstructured text.
Error handling returns generic error payloads without structured recovery guidance. Errors like 'Tor connection failed' include hints but are not categorized as retryable/user-fixable/fatal, limiting agent decision-making.
tor_private_fetch accepts both force_tor and force_direct as booleans. If both are true, behavior is undefined. Parameter relationship should be documented or enforced as mutually exclusive.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
tor_new_identity is a WRITE operation (rotates Tor circuit) but lacks idempotency guarantees or confirmation step. Agents retrying on ambiguous failures could rotate circuits multiple times unintentionally.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in schema definitions. tor_new_identity should be marked destructiveHint=true to signal side effects to agents.