Where does the command actually run?

Depends on the server, and that is the thing to get right. Composio's bash tool runs in a disposable remote sandbox with no access to your systems. Heroku's one-off dyno runs inside your app's environment. Kubernetes pods_exec runs against a real pod in your cluster. The sandbox is the safe default; the cluster exec is the one that needs locked-down credentials.

Is it safe to give an agent shell access?

It depends entirely on the target. A sandboxed bash tool is low-stakes because the environment is throwaway. A pod exec against production is as dangerous as the service account behind it, so scope that to a non-privileged role and a single namespace, and stay on a non-production cluster while you are still learning how the agent behaves.

MCP servers that can run a shell command

3 verified servers expose a tool that can run a shell command

Some jobs do not map to a tidy API call. The agent just needs a shell: run a script, manipulate a file, exec into something and look around. A few infrastructure servers expose that, and the important difference between them is where the command actually runs.

These verified servers let an agent run a shell command, from a throwaway sandbox to a pod in your own cluster.

Top pick

Composio

Official

Composio's universal MCP server: connect an agent to 500+ apps like Gmail, Slack, GitHub, and Notion through one OAuth-authenticated endpoint.

automation

Tool:

RUBE_REMOTE_BASH_TOOL

RUBE_REMOTE_BASH_TOOL runs bash in a remote sandbox, isolated from your infrastructure, which makes it the low-risk default for file work and shell post-processing between other tool calls.

Pick 2

Heroku

Heroku (Salesforce)

Official

Heroku's official Platform MCP server: deploy apps, scale dynos, manage add-ons and pipelines, run one-off commands, and operate Postgres from your agent.

cloud-infra

Tool:

deploy_one_off_dyno

deploy_one_off_dyno runs a command in a sandboxed one-off dyno, so the agent gets your Heroku app's config and add-ons without touching the web dynos serving traffic.

Pick 3

Kubernetes

containers (Red Hat)

Community

Native Kubernetes and OpenShift MCP server: list, inspect, and manage cluster resources, pods, and Helm releases directly through the Kubernetes API.

dev-tools

Tools:

pods_exec
pods_run

Straight at the cluster: pods_exec drops into a running pod and pods_run launches a new one, alongside tools to list and read logs from the workloads around it.

What to know

Read each pick for where the command lands, because that is the whole risk calculation. A remote sandbox is disposable: the blast radius is one container that gets torn down, so it suits file manipulation and post-processing on data the agent already pulled. A one-off dyno runs inside your Heroku app's environment, with its config and add-ons attached. A pod exec runs against your live Kubernetes cluster, which is the sharpest of the three and wants the tightest credentials: a non-privileged service account, one namespace, a non-production cluster while you learn the agent's behavior.

Note that none of these tools remembers the last command. An exec that restarts a process or edits a file leaves nothing behind once the output scrolls off, so if the next session needs to know what state things were left in, that has to be written down somewhere outside the shell.

Questions

Where does the command actually run?: Depends on the server, and that is the thing to get right. Composio's bash tool runs in a disposable remote sandbox with no access to your systems. Heroku's one-off dyno runs inside your app's environment. Kubernetes pods_exec runs against a real pod in your cluster. The sandbox is the safe default; the cluster exec is the one that needs locked-down credentials.
Is it safe to give an agent shell access?: It depends entirely on the target. A sandboxed bash tool is low-stakes because the environment is throwaway. A pod exec against production is as dangerous as the service account behind it, so scope that to a non-privileged role and a single namespace, and stay on a non-production cluster while you are still learning how the agent behaves.