Loading ToolBench
A gRPC server that hosts Lua script execution with tool registration, policy enforcement, and security sandboxing capabilities
Moonbunny exposes 21 tools via gRPC with basic descriptions and input schemas. However, critical gaps undermine production readiness: (1) Transport is gRPC/STDIO only, not HTTP/SSE, violating current MCP spec. (2) Tool descriptions are present but generic (avg ~80 chars, well below the 194-char baseline for A+ tools). (3) Input schemas lack depth, most parameters have type and description, but no enums, ranges, or validation constraints. (4) No error handling guidance; tools return raw gRPC errors without recovery hints. (5) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite 9 WRITE-risk tools. (6) Output schemas are not documented, LLMs cannot predict response structure. (7) Composition issues: LoadScript + RegisterTool + CallTool form a multi-step workflow that should be wrapped into a single 'ExecuteScriptTool' for agent usability. (8) Security: SetPolicy and Execute accept arbitrary Lua code, no input sanitization or dry-run confirmation documented.
Execute a registered tool with named arguments
Cancel an active execution by its execution ID
Execute Lua code with optional policy override and execution options
Execute multiple Lua code snippets in sequence
Execute Lua code and stream output events (status, output chunks, completion)
Retrieve detailed execution statistics including average execution time
Retrieve status and output preview for a specific execution
Retrieve a security policy by name
No output schemas documented. LLMs cannot predict response structure for any tool, forcing them to guess field names and types for downstream chaining.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Nine WRITE-risk tools (LoadScript, UnloadScript, RegisterTool, UnregisterTool, CallTool, UpdateTool, Execute, ExecuteBatch, ExecuteStream, SetPolicy, CancelExecution) lack destructiveHint, preventing agents from understanding irreversibility.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 38 | 2025-06-18+ | v2 |
Retrieve audit log entries for a specific policy
Retrieve aggregate server, VM, and execution statistics
Retrieve detailed information about a specific registered tool
Retrieve Lua VM pool statistics
List execution history with optional status filtering
List all security policies
List registered tools with optional filtering by category, enabled status, or script name
Load a Lua script into the engine by name and source code
Register a tool that invokes a function from a loaded Lua script
Create or update a security policy
Unload a previously loaded Lua script and cascade-remove its registered tools
Unregister a previously registered tool
Update properties of a registered tool (description, category, enabled status, input schema, metadata)
No error handling guidance. Tools return raw gRPC errors without recovery hints. E.g., 'script not found' should suggest 'Call ListTools() to see available scripts' or 'Call LoadScript() to register a new script'.
Descriptions are generic and under-optimized for LLM selection. Average ~80 chars vs. 194-char baseline. E.g., 'Execute Lua code with optional policy override and execution options' does not explain WHEN to use Execute vs. ExecuteBatch vs. ExecuteStream, or what each returns.
Multi-step workflow not wrapped. LoadScript → RegisterTool → CallTool requires three sequential calls. Should offer a single 'ExecuteScriptTool' that loads, registers, and invokes in one step, reducing latency and token waste.