Loading ToolBench
MCP server for BasicDeploy: lets AI coding agents deploy and manage containers, each with Postgres, S3-compatible storage, and a Kafka broker.
BasicDeploy MCP demonstrates solid tool definitions with consistent naming, descriptions, and schemas across 16 tools. Naming follows verb_noun conventions well (list_containers, create_container, delete_topic). All tools have descriptions ranging 37-847 characters. Input schemas are present and properly typed for all tools. However, several gaps prevent a higher score: (1) output schemas are not documented, responses are described narratively but no structured schema is provided for LLMs to parse fields; (2) parameter descriptions lack detail about formats, ranges, and constraints, e.g., memoryMb accepts specific values (256/512/1024/2048) but this is buried in tool description, not param schema; (3) error handling is minimal, no recovery guidance or actionable error messages visible in source; (4) no support for confirmation workflows on destructive operations (delete_container, delete_topic); (5) some descriptions are unnecessarily long and verbose (deploy_app at 847 chars could be more concise). Tools are well-composed and single-responsibility. Baseline: 90% start with action verbs (actual: 100%), average param count is 4 (actual: 1.9, good). All tools have descriptions (94% baseline met). However, 0% of tools have documented return types (100% baseline expected).
Create a new empty BasicDeploy container. A PostgreSQL database and an S3 bucket are provisioned automatically for it. Returns the container's id, subdomain, and public URL. Its public URL is proxied to PORT 8080 inside the container, so whatever you deploy MUST listen on 0.0.0.0:8080 (any other port/binding returns 503). Use deploy_app or exec_command afterwards to put an application in it. Optional memoryMb (256/512/1024/2048) and alwaysOn require the plan/add-ons to allow them (see get_account); larger sizes need Pro/Scale, and always-on on Free consumes a paid add-on slot.
Create a Kafka topic (POST /api/kafka/topics). Optional label -> suffix. Returns { name }.
PERMANENTLY delete a container. This destroys the container, its database, and all its files (S3 bucket contents included) and cannot be undone. Only call this when the user has clearly asked for the container to be removed.
Delete a Kafka topic you own (DELETE /api/kafka/topics).
Deploy an application from a local tarball (.tar, .tar.gz, .tgz, or .zip) to BasicDeploy. The runtime (Node.js, Python, or Go) is auto-detected from the archive contents; the app must listen on 0.0.0.0:8080. If containerId is omitted, a new container (with DB + S3) is created for the app; if provided, the archive is deployed into that existing container. Returns the resulting container and its public URL. IMPORTANT: tarballPath is a path on the machine running THIS MCP client (i.e. the local/stdio install). When BasicDeploy is added as a REMOTE connector (Claude/ChatGPT/Gemini chat) there is no shared filesystem, so this tool cannot read your tarball — deploy with exec_command instead (write the files into the container and start the server on 0.0.0.0:8080).
No output schemas documented. LLMs cannot introspect what fields are returned. For example, list_containers returns 'id, subdomain, public URL, status, and creation time' in narrative form, but no structured schema is provided. This forces LLMs to guess field names and types, increasing errors in downstream calls.
Parameter constraints documented in tool descriptions, not in parameter schemas. create_container's memoryMb accepts '256/512/1024/2048' but this is buried in the tool description, not in an enum schema. Kafka tools lack any parameter description beyond the name. LLMs cannot parse narrative constraints reliably.
Destructive operations lack confirmation or dry-run support. delete_container and delete_topic allow permanent deletion with no warning mechanism. Agents may accidentally call these without user confirmation, causing data loss.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
Run a shell command inside a container (like docker exec). Returns the combined stdout/stderr output and the exit code. Useful for inspecting files, installing packages, or restarting processes inside the container. DEPLOYING WITHOUT A TARBALL (the way to deploy over a remote/chat connector, where there is no shared filesystem for deploy_app): write your app's files into the container with exec_command (e.g. heredoc/echo or install from git), install deps, then start the server. CRITICAL: the container's public URL (https://<subdomain>.basicdeploy.com) is ALWAYS proxied to PORT 8080 inside the container, so your app MUST listen on 0.0.0.0:8080 — NOT localhost/127.0.0.1, and NOT 3000/5000/etc. Any other port or binding returns HTTP 503 at the public URL even though the process is running. The routing is wired when the container is created; you do NOT need deploy_app to 'register' it. There is no init/supervisor: a process you start runs only until the container sleeps or restarts and is NOT relaunched — for a long-running web server enable always-on (set_always_on) and start it detached.
Show the account's plan and capabilities: plan tier, container limit (plan base + add-ons), the memory sizes you may select, storage limit, how many always-on add-ons you hold, and whether containers auto-sleep. Use this to see what you're allowed to set.
Get full details of one container: id, subdomain, public URL, status, ports, database name and username, S3 bucket, volume path, and timestamps.
Kafka connection info + topics + limits
Fetch recent logs from a container. Use this to debug crashes or check application output.
List all BasicDeploy containers owned by (or shared with) the authenticated user. Returns each container's id, subdomain, public URL, status, and creation time.
Purge (empty) a Kafka topic you own (POST /api/kafka/topics/purge).
Turn a container's always-on (24/7, never sleeps) flag on or off. On Free this consumes a paid always-on add-on slot (fails if none is free); on Pro/Scale every container is always-on already. Returns the updated container.
Share a container with another BasicDeploy user by email, giving them access to it. The recipient is emailed a link that signs them in and opens the container. Optionally pass expiresInHours to make the share expire after that many hours (omit for a share that never expires).
Sleep a running container: stop it to free memory while keeping its volume, database, and public URL, so it wakes again on the next request. Returns the updated container.
Wake a slept container so it serves traffic again (start it). A no-op if it is already running. Note: any web request to the container's public URL also wakes it automatically. Returns the updated container.
Kafka tool descriptions are minimal and unhelpful. get_kafka has description 'Kafka connection info + topics + limits' (35 chars, well below 10-1024 baseline). create_topic is 'Create a Kafka topic (POST /api/kafka/topics). Optional label -> suffix. Returns { name }.' (40 chars). These lack context about when/why to use them, what the connection info contains, or what 'topics + limits' means.
No error handling guidance in tool descriptions. Agents have no idea what to do if create_container fails due to 'plan does not allow this memory size' or 'container limit exceeded'. Tool descriptions should guide recovery: 'If memory is rejected, call get_account() to see allowed sizes.'
deploy_app description is overly verbose (847 chars) and mixes multiple concerns. It tries to document both tarball mode and exec_command mode in one description, cluttering guidance. Should be split: one sentence for the primary use case, then bullet points for special modes.
Parameters lack format hints. exec_command accepts a 'command' parameter (string) with no guidance on shell, escaping, or what happens on syntax error. Share_container accepts 'email' with no validation hint. get_logs 'tail' parameter lacks min/max bounds (should be 1-1000 or similar).