Loading ToolBench
IronCurtain provides 3 proxy management tools with clear, action-oriented names and structured JSON schemas. All tools have descriptions and input schemas with typed parameters. However, the server exhibits significant gaps typical of mid-tier implementations: (1) No output schemas are documented, LLMs cannot infer what fields will be returned or plan downstream chaining; (2) Error handling is not evident from the source, no recovery guidance or categorization visible; (3) Parameter descriptions are minimal and lack detail about constraints, expected formats, or when to use each tool; (4) No tool annotations (destructiveHint, readOnlyHint, idempotentHint) are present, forcing LLMs to guess which operations are safe to retry. The three tools are well-named (add_*, remove_*, list_*) and follow the verb_noun convention, but descriptions need expansion and output schemas must be added.
Request access to an additional internet domain through the network proxy. This will be reviewed by a human before being granted. Provide a clear justification for why the domain is needed.
List all domains currently accessible through the network proxy. Includes both built-in provider domains and dynamically added domains.
Remove a previously approved domain from the proxy allowlist. Only dynamically added domains can be removed; built-in provider domains cannot.
No output schemas documented. LLMs cannot determine what fields list_proxy_domains or add_proxy_domain return, preventing downstream tool chaining and forcing wasteful follow-up calls.
Tool descriptions lack context about when to use each tool and consequences of actions. 'Request access to an additional internet domain' does not explain that the tool is async (requires human review) or how long approval takes. This leaves LLMs unaware of the tool's operational semantics.
No tool annotations (destructiveHint, readOnlyHint, idempotentHint) present. LLMs cannot determine which tools are safe to retry. 'remove_proxy_domain' is destructive but unmarked, and 'add_proxy_domain' is idempotent but not annotated.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Parameter descriptions are terse (8 - 46 chars) and lack detail. 'justification' in add_proxy_domain is described as 'Explanation of why this domain is needed for the current task. This text is shown to the human reviewer.', this is adequate but could specify minimum length, format, or examples of strong justifications to guide LLM input.
No error handling or recovery guidance visible. What happens if a domain is rejected by the reviewer? What error does the LLM see? Can it retry? The tool interface provides no guidance.