Loading ToolBench
Meta-MCP code-mode gateway: connect many MCP servers, expose one execute_python tool. Agents write Python that calls all upstream tools as typed functions.
Single tool 'execute_python' has a well-structured schema with three parameters (code, allow_mutations, dry_run), all with type definitions and descriptions. The tool description is comprehensive (194 chars) and explains the dual-mode execution model (dry_run preview). However, the description is embedded in the parameter documentation rather than as a standalone tool-level docstring, and lacks explicit guidance on error recovery or when to use this tool vs. alternatives. The schema is complete and properly constrained (additionalProperties: false), but the tool lacks output schema documentation, LLMs cannot predict what fields to expect from execution results. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite the tool being marked WRITE risk. Parameter descriptions are actionable but could benefit from examples of allow_mutations usage.
Python source to execute. SDK functions are preloaded; assign to `result` or leave a final expression to return a value. Supports allow_mutations (array of SDK function names for mutating tools you authorize) and dry_run (preview mode where mutating calls return stubs but read calls execute).
Missing output schema documentation. LLMs cannot infer what fields the execution result contains (e.g., stdout, stderr, return_value, execution_time). This forces agents to guess at response structure.
No tool-level description; description is buried in parameter docs. Tool descriptions should be standalone and answer: What does it do? When to use it? What does it return? Current placement makes discovery harder.
Missing tool annotations despite WRITE risk classification. Should include destructiveHint=true and idempotentHint=false to signal to LLMs that mutations are irreversible and retries may cause duplicates.
No error handling guidance in description. If Python execution fails (syntax error, timeout, permission denied), the description does not explain what the LLM should do next or how to recover.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2025-06-18+ | v2 |
allow_mutations parameter lacks concrete examples. Description says 'e.g. ["github_create_pull_request"]' but does not explain how LLMs discover valid SDK function names or what happens if an invalid name is passed.