BasicDeploy MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BASICDEPLOY_URL | No | API base URL. Defaults to https://basicdeploy.com. | https://basicdeploy.com |
| BASICDEPLOY_API_KEY | Yes | Your API key (bd_…). The server refuses to start without it. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_containersA | List all BasicDeploy containers owned by (or shared with) the authenticated user. Returns each container's id, subdomain, public URL, status, and creation time. |
| create_containerA | 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. |
| set_always_onA | 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. |
| wake_containerA | 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. |
| sleep_containerA | 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. |
| get_accountA | 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_containerA | Get full details of one container: id, subdomain, public URL, status, ports, database name and username, S3 bucket, volume path, and timestamps. |
| exec_commandA | 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://.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. |
| get_logsA | Fetch recent logs from a container. Use this to debug crashes or check application output. |
| deploy_appA | 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). |
| share_containerA | 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). |
| delete_containerA | 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. |
| get_docsA | Fetch the BasicDeploy documentation as Markdown so you can answer the user's questions and deploy correctly without leaving the chat. Covers: what BasicDeploy is, deploying an app (the 0.0.0.0:8080 rule), the runtime and preset env vars, the PostgreSQL database and S3 object storage, the REST API, the MCP tools, custom domains, SSH, plans/pricing, and hosted auth-as-a-service (OpenID Connect) for your app's own end-users. Optional 'topic' returns only the matching section(s). |
| whoamiA | Return the identity of the BasicDeploy account this connection is authenticated as — the user's email and account id. Use it to confirm WHICH user is logged in before acting on their behalf. |
| get_kafkaA | Get the user's Kafka connection details and topics. BasicDeploy gives every account a Kafka broker (SASL/SCRAM, SCRAM-SHA-256) shared by all their containers. Returns the internal bootstrap (preset as KAFKA_BOOTSTRAP inside containers), the external bootstrap (for outside clients), the SASL username/password, the mandatory consumer-group id prefix (group ids MUST start with it), the current topics, usage and the plan limits. Provisions the tenancy on first call. |
| create_topicA | Create a Kafka topic for the user. The name is auto-namespaced under their prefix; an optional 'label' becomes a readable suffix (sanitized), otherwise it's randomized. Retention, partitions and the per-topic size are fixed by the plan. Fails if the topic count or storage budget is exceeded (see get_kafka / get_account). Returns the full topic name. |
| purge_topicA | Purge (empty) one of the user's Kafka topics — deletes all its messages but KEEPS the topic. Use this to restart processing after a mistake: purge, then have consumers read from the start again. The topic name must be one the user owns (starts with their prefix). |
| delete_topicA | PERMANENTLY delete one of the user's Kafka topics (the topic and all its messages). Cannot be undone. Only call when the user clearly asked to remove the topic. The name must be one they own. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Container tools and Kafka tools are cleanly separated, and lifecycle actions (create/get/list/delete/wake/sleep) each target a distinct operation. The only mild overlap is deploy_app vs exec_command, but their descriptions clearly differentiate local-tarball vs remote deployment.
Most tools follow verb_noun snake_case (list_containers, create_topic, delete_container), making the set predictable. Exceptions like whoami and set_always_on are minor and still readable.
18 tools is on the higher end but justified by two resource domains (containers and Kafka) plus account/meta helpers. Each tool addresses a real operation, though a few (get_docs, whoami) are auxiliary.
Container lifecycle is well covered: create, list, get, deploy, exec, logs, sleep/wake, share, delete, plus always-on. Kafka has get/create/purge/delete; missing container resize/custom-domain tools are workaroundable via exec_command but notable gaps.