Loading ToolBench
Deploy tools for ANY MCP-capable agent harness (stdio, open standard). Agent-native deployment control plane exposing the same governed capabilities as the CLI as standard MCP tools. Deliberately absent: an approve tool. Approving production actions is human-only.
OpenPouch MCP server demonstrates strong tool naming conventions (verb_noun pattern), comprehensive parameter descriptions, and well-documented input schemas. All 14 tools use clear action verbs (openpouch_init, openpouch_deploy, openpouch_inspect, etc.). Tool descriptions are detailed and explain purpose, prerequisites, and behavior. However, output schemas are not visible in the source code provided, and error handling guidance is not explicit in tool definitions. The server shows good adherence to pattern:tool and pattern:tool-description, with most tools having 50-250 character descriptions. Parameter descriptions explain format, constraints, and context well (e.g., openpouch_deploy's 'env' parameter explains that values are secrets and never surfaced). Tool composition is sound, each tool has a single responsibility, and chaining is enabled through shared 'cwd' parameter and clear response shapes (url, status, summary documented in descriptions).
Manage persistent app data (the /data volume, paid tiers only). Commands: `list` (show files), `upload` (write a file into /data), `download` (fetch a file from /data), `delete` (remove a file). Read-only for list/download; requires approval for upload/delete. Returns status + file list or data payload.
Delete a preview deployment (the instant lane only; git-backed services like Render/Vercel are not deletable via openpouch — use their own dashboards). Requires an existing delete approval; instantly removes the deployment and frees the slot. Returns status + summary.
Zero-config INSTANT preview on openpouch's own infra — the `openpouch deploy` command (was CLI-only; Codex 2026-07-04). No account, no provider key, no manifest needed (a saved openpouch API key lifts the deploy into your tier; otherwise anonymous). Uploads the folder, builds on deploy (dynamic Node apps run in a container), probes health, and returns top-level `url`, `healthStatus` (+ `pending`), and a plain-language `summary` to relay to your human. The private claim link (a save token — like a password) is REDACTED from the result BY DEFAULT here, because tool results flow through chat context; it is saved locally to .openpouch/claim.json (0600, gitignored), so nothing is lost. Env var VALUES are secrets: injected into the container only, never in output or evidence (names only). For a full-stack app set healthPath (e.g. /api/health) so the deploy is held to its API too, not just `/`.
Deploy the preview environment through the governed pipeline (policy check → deploy → poll → smoke → evidence). Default policy allows previews autonomously (no human approval needed); a custom policy can require it. Returns top-level `url`, `status`, and a plain-language `summary` to relay to your human. Read-only from a policy standpoint: the pipeline is deterministic, not agent-overridable — policy + readiness + approval checks happen INSIDE the command, which either succeeds (agent can claim and act on the live URL) or fails with an honest fix. The claim link is REDACTED by default (same rule as `openpouch_deploy`); set `redactSecrets: false` only in a private context. Env vars passed at deploy time appear as `deployProvided` in the inspect output.
Output schemas are not documented in tool definitions. Tool descriptions mention response fields (e.g., openpouch_deploy returns 'url', 'healthStatus', 'summary', 'pending'), but no formal schema definitions are visible in the source code. LLMs need documented output types to plan downstream calls.
Error handling guidance is not explicit in tool descriptions. Tools do not state what errors might occur, how to recover, or what the LLM should do if a deployment fails. openpouch_deploy mentions 'denied with an honest fix' for unavailable tier features but does not document error structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | 2026-07-28+ | v2 |
Deploy the production environment through the governed pipeline. Unlike preview, production is approval-gated by default (policy check → approval wait → deploy → smoke → evidence). An agent CANNOT approve — approvals are human-only (interactive terminal or hosted approval UI). If the policy allows production autonomously, the pipeline runs without an approval step. Returns the same shape as preview; the `summary` relays readiness, approval status, and next steps. If approval is required, the result includes a local file path to an approval request (plus `openpouch_approve_production` shows the hosted link if available).
Initialize a project for openpouch: detects framework/build/env vars, writes deploy.manifest.json + deploy.policy.json (default policy: previews autonomous, production requires human approval), auto-matches an existing provider service by name. Idempotent.
Answer: what is deployed, where, on which commit, which required env vars are missing (names only — never values), and what drift exists between manifest and provider. Env vars passed at deploy time (--var/--env-file) appear as `deployProvided` (names from local evidence — the instant lane never exposes them via the API). Read-only. The result carries a plain-language `summary` you can relay directly to a non-technical human.
List all deployments under the current openpouch account (requires an API key). Returns live + recently-expired previews, slots, tier, and quota summary. Read-only.
Stream build/runtime logs from a deployment. For the instant lane: shows build output (if currently building) and recent container logs. For git-backed services (Render/Vercel): shows recent deploy logs. Read-only.
Per environment: the policy decision (allowed / requires-approval / denied), blockers, readiness, and concrete next steps including the human-approval path. Read-only — reports, never acts.
Rollback a production deployment to a previous commit. Requires an existing rollback approval (same approval handshake as deploy-production); the pipeline rolls back to the commit you specify (or the previous one), then re-runs deploy/smoke/evidence. Returns status + summary.
Upgrade the openpouch CLI/core version. When called, checks for a newer release, downloads it, and updates the binary. Returns status + version info.
Verify the manifest, policy, and current state: checks that the deployed service matches the manifest, env vars are present (names only), health checks pass, and no drift exists. Returns detailed validation results + a summary of any issues.
Show the current openpouch account (requires an API key). Returns account ID, email/identities, tier, usage (live deployments, quota remaining), and signup/link status. Read-only.
openpouch_list and openpouch_whoami lack pagination parameters (limit, offset, page_size). If account quotas are large, results could exceed context window. No indication of result limits in descriptions.
openpouch_upgrade has a minimal description ('Upgrade the openpouch CLI/core version...') with no context on when/why to call it, whether it affects running deployments, or what happens during the upgrade. Below the 50-200 character LLM-friendly range.
openpouch_delete requires an approval but the description does not explain the approval workflow or how the agent learns that an approval is pending. Similar issue with openpouch_deploy_production. No multi-step input/confirmation pattern documented.