Loading ToolBench
MCP server that composes tools from multiple MCP servers for unified code execution
This server has critical structural flaws that make it unsuitable for production agent use. Tool 1 (execute_composed_code) lacks a proper input schema definition in the visible code, only Pydantic annotations are shown, not the JSON Schema that would be exposed to clients. Tool 2 (list_available_tools) has minimal documentation. Neither tool has output schemas documented. The execute_composed_code tool is fundamentally unsafe for agent use: it accepts arbitrary Python code execution with minimal safety guardrails, making it impossible for LLMs to reason about side effects or error recovery. Tool naming is reasonable but descriptions are insufficient for safe orchestration.
Execute Python code that orchestrates tools from multiple MCP servers. Used to automate a heuristic search or sequential execution using loops and error handling. Example: ```python from unified_api import * items = ["item_a", "item_b", "item_c"] results = [] for item in items: server__prepare(target=item, mode="sim") result = server__execute_action(name=item, value=123, mode="sim") if result.get("result") != "success": server__restore_state() continue server__finalize(item=item) results.append({"item": item, "status": "success"}) print(f"Processed {len(results)}/{len(items)} successfully") ``` Returns: output: stdout/stderr from execution (partial results if aborted/timed out) returncode: 0=success, 1=error, -1=timeout status: "success" | "failed" | "aborted" | "timeout" session_id: present when persistent=True and status="success" session_vars: list of saved variable names, present with session_id reason: present when status="aborted" — user cancelled operation. Do not retry. tool: present when status="aborted" — which tool was cancelled
List all available tools from connected MCP servers with their signatures. Returns dict with keys: servers (dict mapping server name to tool list), total_servers (int), total_tools (int).
execute_composed_code accepts arbitrary Python code execution with no sandboxing, validation, or static analysis. This is fundamentally unsafe for autonomous agent use, agents cannot reason about what code will do before executing it, making error recovery and safety guarantees impossible.
No output schemas documented for either tool. LLMs cannot plan downstream operations or extract required fields. execute_composed_code returns a dict with dynamic keys (output, returncode, status, session_id, session_vars, reason, tool) but the schema structure, field types, and presence conditions are not formally documented.
Input schemas are not visible as JSON Schema in the source code. Only Pydantic type annotations are shown (Annotated[str, Field(...)]), which are framework-specific and may not be correctly transpiled to the MCP JSON Schema format that clients consume. Cannot verify schema completeness.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
execute_composed_code description (193 chars) is vague about error handling and recovery. It states what the tool does but does not explain when LLMs should call it, how to handle failures, or what happens if code times out. Description does not guide LLM decision-making.
list_available_tools has a minimal, generic description (81 chars) that barely explains what the tool does. No guidance on when to call it, what to do with the results, or how the output structure is organized.
execute_composed_code parameters lack clear constraints. session_id defaults to empty string; persistent defaults to False. The relationship between these parameters is underdocumented, what happens if you set persistent=True but omit session_id? Does it auto-generate one? The code field requires min_length=1 but no max_length is set, leaving potential for unbounded large payloads.
Tool annotations are present (readOnlyHint, destructiveHint, idempotentHint) but are incorrectly set. execute_composed_code is marked destructiveHint=False and idempotentHint=False, yet the tool performs arbitrary code execution that can have ANY side effect. These annotations are misleading, the tool should not be marked as safe to retry or analyze for side effects.
No error handling guidance for LLMs. The tool returns status='timeout' or status='failed' but provides no recovery hints. When an agent receives status='failed', it does not know whether to retry, contact the user, or abort the entire plan.
Tool descriptions include example code with variable names (item_a, item_b, server__prepare) that LLMs may attempt to reuse literally rather than adapt to actual context. Examples should use abstract placeholders or be replaced with parameter constraints.