Skip to main content
Glama
AkaciaNL

BasicDeploy MCP Server

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
BASICDEPLOY_URLNoAPI base URL. Defaults to https://basicdeploy.com.https://basicdeploy.com
BASICDEPLOY_API_KEYYesYour 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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 18 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues