Loading ToolBench
MCP server exposing 10 platform tools over the public /api/v1 surface for managing VMs, containers, and code execution on the PequeRoku platform
Strong tool naming (verb_noun pattern consistently applied: list_*, get_*, run_*, create_*, exec, write_*, read_*, destroy_*). Descriptions are detailed and contextual (avg ~180 chars), explaining WHAT, WHEN, and prerequisites. All 10 tools have input schemas with typed parameters. However, several parameters lack descriptions (e.g., 'files' array items not documented), and output schemas are not formally documented. Error handling guidance is minimal, no recovery hints or categorization. Security considerations (API key injection, destructive operations) are mentioned in descriptions but not enforced via tool annotations.
Run a shell command in an existing container (Debian). Each call runs in a fresh shell with no retained cwd or shell state, so `cd /app && ...` if you depend on the working directory. `background=true` starts a detached process and returns a process_id you poll with process_status — use it for servers or long jobs, and bind apps to 0.0.0.0 so get_preview can reach them.
Destroy a container. Requires `confirm=true` — this is irreversible.
Return the container named `name`, creating it (needs `type`) if absent. Idempotent way to get a stable Debian workspace (working dir `/app`, files persist across reboots) to come back to across calls. `type` is a flavor name or id from `list_types`; it is required only when the container must be created. Returns its `id`, used by the other container tools.
Inspect or fetch a web app running inside the container. - No `port`: list the ports an app is listening on. Each entry includes a ready-to-use absolute `preview_url`. Empty until your app is actually listening — start it (e.g. `container_exec(..., background=true)`) bound to 0.0.0.0 on a high port first. - With `port` (and optional `path`, default `/`): fetch the LIVE response the app serves and return its `status`, `content_type` and `body` — so you can verify the app end-to-end, not just that a port is open. Auth is automatic: the preview is reached with your own API key. To hand the URL to a human/browser instead, append `?__pk_token=<your key>` to the `preview_url` (or send `Authorization: Bearer <your key>`); it authenticates the same owner-only preview and drops a short-lived cookie so the page's assets load too.
Output schemas not documented. Tools return structured data (status, content_type, body, etc.) but LLMs cannot see the expected response shape. This forces agents to guess field names and risks extraction errors.
Array parameter items lack descriptions. 'files' parameter in run_code and write_files is typed as array but the schema for each file object (path, content) is not documented. LLMs cannot infer the structure.
No error recovery guidance. Descriptions mention constraints (e.g., timeout_seconds max 600) but do not guide LLMs on what to do if a call fails. No categorization of retryable vs. fatal errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
List your persistent containers with their status, flavor and specs.
List the VM flavors your API key may use, with specs and credit cost. Call this before creating anything: it returns each allowed type's `id`, `name`, `vcpus`, `memory_mb`, `disk_gib` and `credits_cost`. The `name` (or `id`) is what you pass as `type` to `run_code` / `get_or_create_container`.
Get the status and recent output of a background process.
Read a path: file → its contents; directory → its listing. Project files live under `/app`. File contents are truncated past the output limit (a `truncated` flag marks it).
Run a command in a fresh throwaway Debian VM and return its output. Best for one-shots: PequeRoku boots the VM, writes `files` ([{path, content}]) into `/app` (the working directory), runs `command`, returns stdout/stderr/exit_code, and destroys the VM. No state survives — use a persistent container (`get_or_create_container`) if you need it to. `type` is a flavor name or id from `list_types`; omit it for the cheapest allowed type. `timeout_seconds` is a hard cap (max 600).
Write a batch of files into a container. `files` is [{path, content}]. Relative paths resolve under `/app`, the working directory. Use this to seed or update a workspace, then drive it with `container_exec`.
Destructive operations lack confirmation pattern. destroy_container requires confirm=true but no dry-run or preview capability. Agents cannot safely plan destruction without executing.
Tool annotations missing. No readOnlyHint, destructiveHint, or idempotentHint declared. LLMs cannot infer which tools are safe to retry or which modify state without reading descriptions.