Loading ToolBench
A Model Context Protocol server that can access Tor/onion services with configurable settings, content filtering, and safety guardrails
This server has moderate definition quality with several significant gaps. Tool names are reasonably clear (verb-noun pattern mostly followed), but descriptions vary widely in quality and completeness. Parameter schemas are present and typed, but many lack sufficient constraints and guidance. Output schemas are not documented. Error handling is minimal. The server exposes configuration paths as parameters (get_config), which is a design smell. Overall, this is a fair-to-poor implementation that would require substantial revision before production use.
Analyze content for safety issues, blocked keywords, and potentially harmful patterns
Check if an onion service (.onion domain) is accessible and return basic information
Fetch and return the content of a URL, with optional Tor routing and content filtering
Get current configuration settings using dot notation path (e.g., 'tor_settings.socks_port')
Get information about the Tor connection status and configuration
Reload content filtering configuration from the JSON config file without restarting the server
get_config tool exposes internal configuration path structure as a parameter (dot notation like 'tor_settings.socks_port'). This breaks the abstraction layer, agents should request semantic information (e.g., 'get_tor_socks_port'), not navigate config file internals. This forces LLMs to know internal naming conventions and risks exposing sensitive configuration paths.
No output schemas documented for any tool. LLMs cannot reason about what fields to expect, cannot plan downstream tool calls, and cannot extract the right data from responses. For example, fetch_url description says 'return the content' but does not specify if it returns {content: string, status: int, headers: object} or just raw text.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | <=2025-11-25 | v2 |
Parameter descriptions lack constraint details. 'timeout' in fetch_url says '(default: 60)' but does not specify numeric range, units, or minimum/maximum values. LLMs may pass invalid values (e.g., 999999 or 0.001) that break the tool. Baseline rubric requires 'minute 1 - 365' or 'seconds 1 - 300' format.
Tool descriptions are too brief and lack WHEN/WHY guidance. fetch_url says 'Fetch and return the content of a URL, with optional Tor routing and content filtering' but does not explain: When should an agent call this vs a standard HTTP client? What does 'content filtering' mean to the LLM? Does it block, redact, or warn? Baseline rubric expects 50 - 200 character descriptions that answer what/when/why.
Error handling is absent from tool definitions. No guidance on retryability, user-fixable vs fatal errors, or recovery steps. For example, if fetch_url times out, should the agent retry, increase the timeout parameter, or ask the user? The tool definition provides no hints.
No tool annotations present. None of the tools declare readOnlyHint, destructiveHint, or idempotentHint. For example, reload_filter_settings is marked REVERSIBLE in risk metadata but the tool definition does not include destructiveHint: true, leaving the LLM unable to reason about safety.
reload_filter_settings and get_config have empty input schemas ({}). While these are valid, they offer no guidance to LLMs on what they do or when to call them. Description is vague ('Reload content filtering configuration', what does reload mean to an agent? How does it differ from get_config?)
Parameter 'use_tor' in fetch_url is a boolean with no default declared in the schema. Description says '(default: false)' in text but schema should specify default: false explicitly. This risks LLMs omitting the parameter and then being surprised by default behavior.