Loading ToolBench
MCP server that exposes a single 'run_go_code' tool over MCP (stdio transport). Each running server holds one Kubernetes Agent Sandbox, lazily created on first tool call and reused across calls — files and build cache persist within a session.
Single tool 'run_go_code' has a well-structured description (340 chars, within 10-1024 range) with clear examples and state persistence explanation. Input schema is present with two parameters: 'files' (object) and 'command' (string), both with descriptions. However, the schema lacks formal type constraints (no minLength, maxLength, pattern for command; no additionalProperties constraint for files object). Parameter descriptions are adequate but could be more prescriptive about constraints. No output schema is documented, callers must infer the response structure from examples. Error handling is mentioned implicitly (exit code, stdout, stderr) but lacks recovery guidance. The tool is well-intentioned but falls short of production-grade definition quality due to missing output schema documentation and incomplete input validation constraints.
Build and run Go code in an isolated Kubernetes sandbox. How it works: - Optionally write a set of files under /app (the sandbox's working directory). Paths may be nested (e.g. "greet/greet.go"). - Then run a shell command in /app via 'sh -c'. - Get back the exit code, stdout, and stderr. State persists across calls within this session: files you wrote stay, the Go build cache stays warm, and binaries you compiled remain executable. To start fresh, run a command like "rm -rf -- *". Examples: - {files: {"go.mod":"module x\ngo 1.26\n","main.go":"package main\nimport \"fmt\"\nfunc main(){fmt.Println(\"hi\")}\n"}, command: "go run main.go"} - {command: "go build -o app . && ./app"} - {files: {"greet/greet.go":"package greet\n..."}, command: "go test ./..."}
Output schema not documented. Tool description mentions 'exit code, stdout, stderr' but no formal schema defines the response structure, field types, or whether stderr is always present.
Input parameter 'command' lacks format constraints. No minLength, maxLength, or pattern specified. LLMs may pass empty strings or excessively long commands without validation.
No error recovery guidance. If a command fails (non-zero exit code), the description does not explain what the LLM should do next or how to interpret stderr.
Files parameter lacks validation constraints. No specification of allowed file paths (e.g., no absolute paths, no traversal outside /app), max file size, or max number of files.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Tool name 'run_go_code' is generic. More specific names like 'execute_go_sandbox' or 'build_and_run_go' would better signal the isolated execution context and state persistence.