Loading ToolBench
CodeSandbox MCP presents a well-structured toolkit with 11 tools covering sandbox lifecycle and file operations. Strengths: all tools have descriptions (10-200 chars), input schemas are comprehensive with Zod validation, tool names follow verb_noun convention clearly (createSandbox, resumeSandbox, readFile, writeFile), parameters have type definitions and descriptions. Critical weaknesses: (1) Output schemas are completely undocumented, tools return JSON text but no structured response field descriptions are provided; (2) Error handling lacks recovery guidance, toPublicError() strips context and offers no actionable next steps; (3) Security parameter naming is inconsistent, env and git parameters accept sensitive data (accessToken) without warnings in descriptions; (4) Some parameter descriptions are vague or incomplete (e.g., 'ipcountry' described only as 'Two-letter country code' with no guidance on when/why to use it); (5) No confirmation/dry-run pattern for destructive operations (hibernateSandbox, rename with overwrite=true). STDIO transport caps practical utility despite good definition quality. Average per-tool score: 62/100 across all 11 tools.
Create a CodeSandbox sandbox (optionally from a template) and optionally start with custom VM settings.
Create a CodeSandbox session for a sandbox. Returns the sessionId without storing state on the server.
Get metadata for a sandbox by ID without resuming the VM (title, description, privacy, tags).
Hibernate a sandbox (saves files and puts VM to sleep).
Read a file from the sandbox filesystem. Stateless: connects per call using sandboxId+sessionId.
List files and directories at a given path in the sandbox filesystem. Stateless: connects per call using sandboxId+sessionId.
Output schemas completely undocumented. Tools return text/JSON via MCP ToolResult content blocks, but no schema describes what fields the JSON contains, their types, or when they are present. LLMs cannot infer output structure and must parse unstructured JSON or rely on trial-and-error.
Error handling provides no recovery guidance. toPublicError() in errors.ts strips context and returns only code + message. LLMs cannot determine if an error is retryable, requires user input, or is fatal. No actionable next steps (e.g., 'Try calling searchChannels() first').
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Rename (move) a file or directory within the sandbox filesystem. Stateless: connects per call using sandboxId+sessionId.
Resume a hibernated sandbox or start it if shut down.
Connect to an existing session by sandboxId + sessionId. If the session does not exist, it will be created with optional permission/env.
Update VM settings for a running sandbox: tier and/or hibernation timeout.
Write a file in the sandbox filesystem. Stateless: connects per call using sandboxId+sessionId.
Sensitive parameters lack security warnings. createSession and resumeSession accept 'accessToken' in git.accessToken without a description warning that this is a secret and must not be logged. Similarly, env parameter accepts arbitrary environment variables without guidance on avoiding secrets.
No confirmation or dry-run pattern for destructive operations. hibernateSandbox and rename with overwrite=true are irreversible but offer no dry-run mode or explicit confirmation step. Agents could accidentally destroy work.
Vague or incomplete parameter descriptions limit LLM guidance. ipcountry is described as 'Two-letter country code' but no explanation of what it controls or when it's needed. vmTier has no explanation of tier tradeoffs or performance implications. hibernationTimeoutSeconds lacks guidance on reasonable values or implications of choosing too short/long.
Response field naming inconsistencies risk broken tool chains. createSandbox returns {sandboxId, bootupType, cluster, isUpToDate} but other tools require 'sandboxId' parameter. No guarantee that all response fields use consistent naming (snake_case vs camelCase) or that returned IDs match parameter names.
Missing parameter constraints. encoding parameter accepts 'utf8' or 'base64' but is described as an enum without explaining when to use each. maxItems on tags array (10) is enforced but not explained (is this an API limit? a convention?).