Wassette: Running Wasm Components as MCP Tools Behind a Wasmtime Sandbox

The gap Wassette fills between an agent and a sandboxed tool

An MCP client gives an agent a list of tools. Something has to produce that list, route calls, and decide what each tool can touch. Wassette takes that middle position and narrows it: the tool implementations are WebAssembly Components, and they execute inside the Wasmtime sandbox rather than as native processes on the host. The README's three selling points are convenience, reusability and security, and the security claim is the specific one: it says Wassette is "built on the Wasmtime security sandbox, providing browser-grade isolation of tools." The reusability claim is the structural one. A Wasm Component is not MCP-specific, so a component written for one host can be loaded by another. That matters if you have already invested in building components, because Wassette becomes an adapter rather than a rewrite. The audience is therefore narrow and identifiable: teams that compile tools to WebAssembly, run an MCP-capable agent, and want the tool boundary to be a sandbox boundary instead of a process boundary. If your tools are Python scripts invoked over a shell, Wassette solves a problem you do not have yet.

What actually moves: OCI registry to MCP tool call

The data flow visible in the README starts with an OCI reference. The example the documentation gives is `oci://ghcr.io/microsoft/time-server-js:latest`, passed to the agent in a natural-language instruction to load the component. Wassette resolves that reference, pulls the component, and registers it with the MCP client so the agent can call it. The agent then issues a normal tool call, Wassette executes the component inside Wasmtime, and the result comes back as a tool response. The README shows the loop end to end: ask the agent to load the time component from the OCI URL, then ask "What is the current time?", and the documented output is a timestamp attributed to the component running in the sandbox. Two design consequences follow from that shape. First, distribution is registry-based, so a component is versioned and pulled like any other OCI artifact, and `:latest` in the example is a mutable tag rather than a pinned digest. Second, the tool surface is dynamic: components are loaded at runtime through the agent conversation, not compiled into the server at build time. The repository topics list capabilities, permissions and oci-artifacts alongside wasm and wasmtime, which is consistent with a runtime that treats a component's declared capabilities as the thing it must check before execution. The README does not spell out the permission-checking mechanism itself, so treat the capability list as the place to look in the documentation rather than something this article can confirm.

Install paths and the three-step registration

For Linux and macOS the README gives a one-liner: `curl -fsSL https://raw.githubusercontent.com/microsoft/wassette/main/scripts/install.sh | bash`. Piping a remote script into a shell is a supply-chain decision, and the repository offers no checksum or signature step in the material shown here, so a reader who cares about that should read the script before running it. Windows, Homebrew, Nix and Docker are handled in the separate installation guide rather than in the README. After installation the work is registration: the README describes a three-step Quick Start and points to an MCP clients guide with setup instructions for GitHub Copilot, Copilot CLI, Claude Code and Codex CLI. In other words, Wassette is configured as an MCP server inside whichever client you already use, and the client-specific wiring lives in the docs rather than in the repository root. Once registered, the interaction model is conversational rather than configurational. The README's example does not show a config file or a CLI subcommand for loading a component. It shows the user asking the agent to load it, which means the agent needs to have a Wassette-provided tool for loading components, and the load step is itself a tool call. That is a deliberate choice and it has a cost: component loading becomes part of the prompt surface, and anything that can talk to the agent can attempt to load a component.

The early-development warning is the first thing to take seriously

The README carries a warning block stating that the repository is not production ready, is in early development, and may change significantly. The release history is consistent with that. The listed releases include v0.7.0 plus two timestamped builds named `latest-20260830-2013-e1a0f20` and `latest-20260829-0113-e12ce57`, which look like automated snapshots keyed to a commit hash rather than curated version tags. A project publishing both semantic tags and dated commit builds is moving fast enough that pinning matters. If you build on Wassette, pin the release you tested rather than tracking the newest snapshot, and pin component digests rather than `:latest`, because the README's own example uses a floating tag. The second limitation is architectural rather than temporal. A sandbox constrains what a component can reach, but it does not constrain what the component does with what it is allowed to reach. A component granted network access to a host can still send data there. The isolation claim in the README is about the boundary, and the boundary is only as narrow as the capability set the component declares and the runtime enforces. That enforcement path is not described in the README text supplied here, and it is the single most important thing to read in the full documentation before trusting the model.

Where a plain MCP server is the better fit

The obvious alternative is a conventional MCP server written in a host language, exposing tools as ordinary functions. The difference is not speed or features, it is where the isolation lives. A conventional server runs in the same trust domain as the rest of your process: a tool that reads a file reads it with the server's own credentials and filesystem view, and adding a new tool means editing and redeploying the server. Wassette inverts both. The tool is a separately distributed artifact fetched from a registry, and its reach is meant to be bounded by declared capabilities inside Wasmtime. That inversion is worth paying for when tools come from different sources or when you want to add one without redeploying anything. It is not worth paying for when you have four internal tools, one trusted author, and no need for registry distribution. In that case a conventional server is simpler to debug, because a stack trace from native code is easier to read than a trap inside a wasm instance, and you avoid the wasm32 build step entirely. The README's reusability argument cuts the other way too: components are generic, so a component you write for Wassette is not locked to Wassette, which is a real hedge if the runtime changes under you.

Maintenance surface and the MIT licence

The project is MIT licensed, which is permissive: it allows modification and redistribution provided the copyright notice and licence text are retained. That is the whole of what can be said here, and it is not legal advice. Two practical consequences are worth naming anyway. First, MIT places no copyleft obligation on components you load through Wassette, so a component under a different licence stays under that licence and you are responsible for checking it separately. The README's example pulls `ghcr.io/microsoft/time-server-js`, and nothing in the material states the licence of that component as distinct from the runtime. Second, the trademark section notes that Microsoft trademarks and logos may not be used in modified versions in a way that implies sponsorship. If you fork and ship, that is the clause to read. On upgrade cost, the moving parts are the runtime, the Wasmtime dependency underneath it, and each component. Wasmtime is a versioned engine with its own release cadence, so a Wassette upgrade can pull a new engine version with it. The dated snapshot releases suggest the maintainers expect consumers to move frequently, which raises the cost of staying current. Budget for re-testing loaded components after a runtime upgrade, because a component that behaved under one engine version is not guaranteed to behave identically under the next.

Who should adopt it, and what to check before you do

The fit is a team that already produces WebAssembly Components, runs an agent that speaks MCP, and wants tool execution isolated from the host rather than merged into it. The README's own demo is a time server, which is a toy, but the mechanism it demonstrates is the point: a component pulled from a registry, executed in a sandbox, surfaced as a tool. If that mechanism matches your deployment shape, the project is worth a trial run behind the install script and the client registration docs. If your tools are shell scripts, or if you need a stable interface that will not shift between snapshots, wait. Before committing, check three things in the full documentation. Confirm the capability and permission model in detail, since the README asserts isolation without describing enforcement. Confirm how a component's declared capabilities are surfaced to the user at load time, because a load step driven by the agent conversation needs a review point. And confirm the release policy behind the dated snapshot tags, so you know what pinning to a version actually buys you.

Editorial conclusion

Adopt Wassette if you already build WebAssembly Components and want them callable from an MCP client without writing per-tool glue, and if you can tolerate the repository's own early-development warning. Do not adopt it if you need a stable tool surface today, or if your tools are plain scripts that have no reason to be compiled to wasm32. Verify first that the component you intend to load is published as an OCI artifact and that the capabilities it requests match what it actually does, because the sandbox is only as tight as that request list.

Official sources

1. License: MIT
2. microsoft/wassette on GitHub
3. Project website
4. README
5. Releases