Skip to main content
Glama
AkaciaNL

BasicDeploy MCP Server

exec_command

Destructive

Run shell commands inside a BasicDeploy container to inspect files, install packages, or restart processes, with output and exit code returned.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commandYesShell command to execute inside the container
containerIdYesUUID of the container

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
outputNoCombined stdout/stderr.
exitCodeNoProcess exit code.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.3

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds rich behavioral context beyond the annotations: no init/supervisor, processes are not relaunched, the public URL is always proxied to 0.0.0.0:8080, and incorrect bindings yield HTTP 503. This is exactly the kind of hidden runtime behavior an agent cannot infer from schema or annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The prose is long but front-loaded and every section earns its place. The first sentence states purpose and return values, then the deployment and port constraints are separated into clearly flagged blocks; there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Combined with the schema, output schema, and annotations, the description covers command execution, output, exit codes, deployment workflow, port/proxy constraints, and process lifecycle. Nothing needed to call this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both containerId and command. The description does not add parameter-specific detail beyond usage examples, which keeps it at the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('Run a shell command inside a container') and the docker exec analogy, then clarifies the output (combined stdout/stderr and exit code). It also gives concrete use cases (inspecting files, installing packages, restarting processes) that separate it from container lifecycle or deployment tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly calls out when exec_command is the right tool: for actionable container work and for deploying without a tarball over remote/chat connectors where deploy_app's shared filesystem is unavailable. It also names set_always_on for long-running servers and clarifies that deploy_app is not needed for URL registration.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.