# Mcpvessel > Cage untrusted MCP servers in containers, compose them into agents, and share them over any OCI registry. Signed, sandboxed, no Docker required. - **Type:** MCP server - **Install:** `agentstack add mcp-okedeji-mcpvessel` - **Verified:** Pending review - **Seller:** [okedeji](https://agentstack.voostack.com/s/okedeji) - **Installs:** 0 - **Category:** [Cloud & Infrastructure](https://agentstack.voostack.com/c/cloud-infrastructure) - **Latest version:** 0.1.0 - **License:** Apache-2.0 - **Upstream author:** [okedeji](https://github.com/okedeji) - **Source:** https://github.com/okedeji/mcpvessel ## Install ```sh agentstack add mcp-okedeji-mcpvessel ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # mcpvessel **Cage untrusted MCP servers, keep using them, compose them into agents, and share them.** [](https://github.com/okedeji/mcpvessel/actions/workflows/ci.yml) [](https://github.com/okedeji/mcpvessel/releases) [](LICENSE) An MCP server runs as a subprocess with your full user permissions. The protocol does not sandbox it, so an installed server can: - read your SSH keys, cloud credentials, and `.env` files - run arbitrary commands on your machine - send any of it anywhere This is not theoretical. [CVE-2025-6514](https://nvd.nist.gov/vuln/detail/CVE-2025-6514) (rated critical) is host remote code execution from connecting to an untrusted server, and audits keep finding thousands of vulnerable public servers. Safe today does not mean safe after the next update. mcpvessel runs each MCP server in an isolated container instead: - no access to your host or files - no outbound network unless you allow it - no provider keys inside the sandbox It brings its own runtime, so there is no Docker or container engine to install. It can also compose several caged servers into a single LLM agent and distribute them over an OCI registry, both covered below. Ask Claude to save an ordinary note. The caged server quietly tries to ship your STRIPE_SECRET_KEY to exfil.attacker.net, and mcpvessel blocks it. Claude sees a tool that just worked; you see the theft it tried to hide, denied in the audit feed. ## Contents - [Cage it](#cage-it) - [Give it a brain](#give-it-a-brain) - [Ship it](#ship-it) - [What the cage actually does](#what-the-cage-actually-does) - [What it does not protect against](#what-it-does-not-protect-against) - [How it works, briefly](#how-it-works-briefly) - [Install](#install) - [Requirements](#requirements) - [Uninstall](#uninstall) - [Commands](#commands) - [Contributing and support](#contributing-and-support) - [License](#license) ## Cage it On macOS or Linux: ```sh # Install the signed cask (this also wires up shell completions). brew install --cask okedeji/tap/mcpvessel # One-time runtime setup; on macOS this fetches a small Linux VM. mcpvessel init ``` > [!TIP] > **Try it in one command**, no token, no config. This pulls mcpvessel's own docs as a signed MCP server and runs it caged: > > ```sh > mcpvessel serve io.github.okedeji/mcpvessel-docs --listen 127.0.0.1:7000 > # point your MCP client at http://127.0.0.1:7000/mcp and ask it anything about mcpvessel > ``` Caging a server of your own works the same way, whichever server it is. The example below uses GitHub's, because it carries a real token the cage must keep from leaking: ```sh # Store the token. mcpvessel prompts for the value and hides your typing. # (Or pipe it in for scripts: mcpvessel secrets set NAME [!TIP] > Shape how it reasons with `--prompt "You are an on-call SRE; escalate P1s and cite the runbook."` (or `--prompt-file ./prompt.md` for a multi-line one). It needs a configured LLM provider (`mcpvessel config provider set`), plus the same keys and egress as before: ```sh # Give it a task, it reasons over both servers' tools to answer. mcpvessel run @me/oncall:0.1 "what is causing our top Sentry error this week, and how do I fix it?" \ --secret SENTRY_ACCESS_TOKEN --secret BRAVE_API_KEY \ --egress sentry.io --egress api.search.brave.com ``` This runs an LLM tool-use loop over both servers, caged alongside them, with a per-run spend cap. The result is an agent you invoke like any other, and the servers stay sandboxed as before. A secret only ever reaches a server that declares it, and like `--egress`, `--secret` can scope a key to just one server of several. It does not have to live in your terminal. Serve it and it is an HTTP endpoint you can hit with nothing but `curl`: ```sh # Serve the agent on one URL. mcpvessel serve @me/oncall:0.1 \ --listen 127.0.0.1:7000 --secret SENTRY_ACCESS_TOKEN --secret BRAVE_API_KEY \ --egress sentry.io --egress api.search.brave.com # Prompt it with curl; the result comes back as JSON. curl -sX POST 127.0.0.1:7000/agents/oncall -d '{"prompt":"what is causing our top Sentry error, and how do I fix it?"}' # {"result": "..."} ``` No MCP client or SDK needed, just JSON in and JSON out. The same agent can sit on a server, run in a CI job, or live behind your own API. It still speaks MCP on that port for clients that prefer it, and any single tool is directly callable at `POST /agents//tools/`. > [!TIP] > For a response an app can render as it generates, add `{"stream": true}` to the body; the answer streams back as Server-Sent Events, chunk by chunk, instead of one JSON blob. ## Ship it A caged server or agent is a content-addressed bundle. Push it to any OCI registry you have logged in to (`mcpvessel login`): ```sh mcpvessel push @me/oncall:0.1 ``` A teammate pulls and runs it by the same reference, sandboxed the same way, without importing or building it themselves: ```sh mcpvessel run @me/oncall:0.1 "what is causing our top Sentry error?" ``` It is signed on push and verified on pull, so they run exactly what you built, caged the same way. The publisher key fingerprint and how to verify a pull are in [SECURITY.md](SECURITY.md#signing-and-trust). ## What the cage actually does Concretely, per server: - **Own container, own network.** Each server runs alone in its own container on its own private network. It cannot see your files, your processes, or another caged server. Nothing from your host is mounted in. - **Deny-default egress.** No outbound connection opens unless the host is allowed. An unknown host is held and surfaced for you to approve (`mcpvessel egress`), and every decision lands in the audit log. - **Secrets by declaration.** A secret value is injected only into a server whose manifest declares that name, entered over stdin and never on a command line. Your LLM provider key never enters any cage at all; a broker outside the cage holds it. - **Hard caps.** Every cage runs under cpu, memory, and pid limits, and a reasoning run's LLM spend is metered against a hard budget. - **Verified distribution.** A shared bundle is content-addressed and signed; a pull verifies the bytes and pins the publisher's key, so a changed key or tampered bundle fails loudly. The full mechanism, with the threat model and invariants, is in [ARCHITECTURE.md](docs/ARCHITECTURE.md). ## What it does not protect against The cage constrains what a server can reach, not whether it behaves. Know the edges: - An allowed host receives whatever the server sends it. Egress control decides which hosts, not what goes to one you permitted. - A server granted a secret and a matching host can use them together. That is the grant working as issued; scope grants narrowly. - A signature proves who built a bundle, not that it is safe. The sandbox contains it; the signature only names its author. - Trust on first use trusts the first key it sees. Verify the printed fingerprint against the publisher's stated one on first pull. - A reasoning agent's model traffic goes to your configured provider directly, outside the egress allow-set, so anything the agent puts in a prompt reaches the provider. - `serve` authenticates no caller and speaks plain HTTP. The `--listen` address is the exposure decision: keep it on loopback, or put TLS and auth in front. - A tool that returns a plausible lie is not detected, and a host compromised outside mcpvessel is out of scope. The complete list is in [ARCHITECTURE.md §14](docs/ARCHITECTURE.md#14-limitations-and-non-goals). ## How it works, briefly A run is a small set of containers on private, internal-only networks. The server you cage sits alone on its own network with no route out. The only doors are small broker containers that mcpvessel runs for you: one filters every outbound network request against the allowlist you set, one brokers calls between servers, and when a server reasons with an LLM, one more holds your model key so the agent never sees it. On macOS all of this runs inside a lightweight Linux VM that mcpvessel sets up on first run, so nothing touches your host directly. On Linux it uses the host's own container runtime. ## Install **Homebrew (recommended).** Installs a signed cask and wires up shell completions: ```sh brew install --cask okedeji/tap/mcpvessel ``` **Direct download.** Grab the archive for your OS and architecture from the [releases page](https://github.com/okedeji/mcpvessel/releases), verify it against `checksums.txt`, then put the binary on your `PATH`. This is the right path on Windows (run it inside WSL2). **From source.** For contributors and anyone who wants to build it themselves: ```sh git clone https://github.com/okedeji/mcpvessel cd mcpvessel make build ``` Note: on macOS the release archives bundle the Linux VM image the runtime needs, so prefer Homebrew or the direct download over `go install`. ## Requirements - macOS (Apple Silicon or Intel) or Linux. On Windows, it runs inside WSL2: install the Linux binary in your WSL2 distro and run everything (the CLI, the daemon, and `~/.mcpvessel`) there. There is no native Windows binary. - Homebrew, for the recommended install above. - On first run, `mcpvessel init` sets up the runtime. On macOS that is a one-time step: it downloads a small Linux VM image and starts a rootless container daemon, which takes two to five minutes depending on your connection. Every run after that is a few seconds. On Linux this is a no-op and uses the host's container runtime directly. ## Uninstall Stop the runtime, remove the binary, then delete the state directory (this removes the macOS VM, cached images, your signing key, and config): ```sh mcpvessel daemon stop brew uninstall --cask mcpvessel # or delete the binary you installed rm -rf ~/.mcpvessel ``` ## Commands `mcpvessel --help` lists every command, and `mcpvessel --help` covers any one in full, with its flags and examples. You only need `import` and `serve` to get started; the rest is there as you grow into it. Deeper guides for each command live in the [docs](docs/) directory. ## Contributing and support - Bugs and feature requests: [open an issue](https://github.com/okedeji/mcpvessel/issues). - Contributing: see [CONTRIBUTING.md](CONTRIBUTING.md). - Found a security issue? Please report it privately. See [SECURITY.md](SECURITY.md). ## License Apache 2.0. See [LICENSE](LICENSE). ## Source & license This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [okedeji](https://github.com/okedeji) - **Source:** [okedeji/mcpvessel](https://github.com/okedeji/mcpvessel) - **License:** Apache-2.0 Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** yes - **Filesystem access:** no - **Shell / process execution:** yes - **Environment & secrets:** yes - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: flagged — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/mcp-okedeji-mcpvessel - Seller: https://agentstack.voostack.com/s/okedeji - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.