hyper-mcp: an MCP server that gets its tools from WebAssembly plugins
📦️ A fast, secure MCP server that extends its capabilities through WebAssembly plugins.
At a glance
- What is it?
- hyper-mcp is a Rust MCP server that loads its tools as WebAssembly plugins, fetched over oci://, file://, http(s):// or s3:// URLs and sandboxed at runtime. The interesting part is the distribution model; the awkward part is that OCI plugins require the cosign CLI on your PATH.
- Who is it for?
- Adopt hyper-mcp if you already publish container images and want MCP tools that are versioned, signed and sandboxed rather than a pile of local scripts, and if you are willing to install cosign on every machine that loads an oci:// plugin. Do not adopt it if your tools are a handful of Python functions you edit in place; the WASM compile step and the registry round trip buy you nothing there.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: MCP tools that live in your repo instead of a registry
Most MCP servers ship a fixed set of tools compiled into the binary. If you want a new capability, you patch the server, rebuild it, and redeploy it to every client that talks to it. hyper-mcp inverts that. The server itself is a host: the README describes it as a server that extends its capabilities through WebAssembly plugins, and the tools a client sees come from plugin modules listed in a JSON config file. The stated distribution channel is a standard OCI registry, so a plugin is an image you push and pull like any other container artifact, with the version tag doing the work that a git commit would do in a source-built server.
The audience follows from that. This is for people who already run a registry, already have a release pipeline, and want the tools their LLM clients call to move through the same pipeline. The README names Claude Desktop and Cursor IDE as compatible apps, and mentions serverless, edge, mobile and IoT as deployment targets. That last list is only plausible because the plugins are WASM: the same artifact runs on a laptop and on a small device. If your tools are three Python functions you edit in place, none of this machinery earns its keep.
How a plugin becomes a tool: Extism, WASM sandboxing and runtime_config
The host is built on Extism, which is the plugin runtime doing the actual loading and calling. Each entry under plugins in the config has a url and an optional description. The description is not decoration: it is what the model sees when deciding whether to call the tool, so an entry with no description, like the hash plugin in the README example, presents a tool with no explanation attached.
Sandboxing is configured per plugin rather than globally. The README example gives the myip plugin an allowed_hosts list containing only 1.1.1.1, and the fetch plugin an allowed_hosts of ["*"] with a memory_limit of "100 MB". That is the shape of the access control: network destinations are enumerated by host, and memory is capped by a string with a unit. A plugin that needs to reach an API gets that API's host and nothing else. The README also lists filesystem access among the things WASM sandboxing can limit, and mentions fine-grained access control for host functions, though the truncated README does not show the config keys for either. Treat the filesystem side as something to confirm in RUNTIME_CONFIG.md before you rely on it.
Dynamic loading and unloading is listed as a feature and described as configurable. The README does not show the key. If you need a plugin to appear or disappear while the server is running, that detail has to come from the runtime config document.
Getting it running: config path, plugin URLs and the cosign prerequisite
Installation has four routes. Homebrew core (brew install hyper-mcp) needs no tap; the project's own tap (brew install hyper-mcp-rs/tap/hyper-mcp) is bumped on every GitHub Release, which the README notes picks up new versions immediately. Pre-built archives cover aarch64-apple-darwin, aarch64-unknown-linux-gnu, x86_64-unknown-linux-gnu and x86_64-pc-windows-msvc. Rust users can run cargo install hyper-mcp.
The config file location is platform-specific: $HOME/.config/hyper-mcp/config.json on Linux, $HOME/Library/Application Support/hyper-mcp/config.json on macOS, and {FOLDERID_RoamingAppData}\hyper-mcp\config.json on Windows. The README's example declares five plugins, all pulled over oci:// from ghcr.io/hyper-mcp-rs, covering time, QR codes, hashing, public IP lookup and fetching.
The prerequisite that shapes everything else is cosign. OCI plugin images are signed at publish time and verified at load time with sigstore, and the README states plainly that this verification is performed by shelling out to the cosign CLI, which must be installed and available on PATH. If you only use file://, http://, https:// or s3:// URLs, cosign is not needed. You can bypass the check with insecure_skip_signature: true in the config or HYPER_MCP_INSECURE_SKIP_SIGNATURE=true in the environment, which the README labels not recommended for production. Starting the server is just hyper-mcp; it speaks stdio, and RUST_LOG=debug turns up logging. Output goes to daily rolling log files under the hyper-mcp logs directory, for example $HOME/.config/hyper-mcp/logs/mcp-server.log on Linux.
The cosign dependency is a real operational constraint
Verification by shelling out to an external binary is a deliberate choice with a cost. The MCP server now has a runtime dependency that is not part of its own build and not managed by cargo or Homebrew's dependency resolution for this formula. A container image that runs hyper-mcp needs cosign installed too, and a CI job that smoke-tests plugin loading needs it as well. Nothing in the README suggests cosign is vendored or called as a library.
The failure mode is blunt: if cosign is missing from PATH, OCI plugin loading cannot proceed, and the escape hatch is to disable signature checking entirely. That is a bad trade to be forced into, because the two states are verified and unverified, with no middle ground described. There is also a network dependency implied by the OCI path. Pulling oci://ghcr.io/hyper-mcp-rs/time-plugin:latest at startup means the server's tool set depends on registry availability, and the :latest tag means it depends on whatever was pushed most recently. Pinning a digest or a version tag is not discussed in the README, but the URL format accepts tags, so pinning is at least expressible.
One more constraint worth stating: the README recommends running SSE or streamable-http by wrapping hyper-mcp in a proxy that supports network transports and that creates an instance of hyper-mcp per client connection. That is a per-connection process model, not a shared server, and the README does not describe a built-in HTTP transport. Anyone expecting hyper-mcp to be the network-facing component is reading it wrong.
Where hyper-mcp is the wrong tool
If your tools are local and private, the plugin pipeline is overhead. A file:// URL avoids cosign, but you still pay for compiling to WebAssembly and for the host-guest boundary on every call. A server that imports your functions directly does not have that boundary.
If you need a tool that shells out to a system binary, reads a local socket, or touches hardware, the sandbox is working against you. The README frames sandboxing as a feature, and it is, but the same property that stops a malicious plugin from reading your filesystem stops a legitimate one from doing so too. You would be looking for host functions or an escape hatch, and the truncated README does not document one.
If you need a long-lived shared HTTP endpoint with per-session state, hyper-mcp's stdio-first design pushes that into a proxy layer that the project does not ship. And if you want a large catalog of ready-made tools rather than a plugin format to write against, the five example plugins in the README are the entire catalog it shows; the value here is the mechanism, not a library of integrations.
Compared with a source-built MCP server
The obvious alternative is an MCP server where tools are compiled in, written in the same language as the host, and updated by rebuilding and redeploying. The difference is where the boundary sits. A source-built server has no plugin runtime and no signature verification step, so a tool change is a code change and a deploy. hyper-mcp moves the tool change to a registry push, which is better when the tools outnumber the people who can merge into the server's codebase, and worse when they do not.
The second difference is the trust model. A source-built server trusts its own build. hyper-mcp trusts the registry, the signature, and cosign's verdict, and gives you a per-plugin allowlist for network hosts and a memory cap as the runtime half of that trust. That is a more explicit model, and it is the reason to pick hyper-mcp even when the plugin count is small: the access a tool has is written down in config rather than implied by the process it runs in.
Maintenance, versions and licence
The release history shows a nightly build alongside tagged releases v0.8.2 and v0.8.3, with the nightly published more recently than either tag. A project that publishes nightlies on every push is telling you the main branch moves; if you deploy from a tag, expect the gap between tags to matter. The README example config uses :latest on every OCI plugin URL, which means an unmodified config tracks whatever was pushed last, independent of the hyper-mcp version you installed.
Upgrade cost splits in two. The binary upgrades through whichever channel you chose, and the README notes the project's Homebrew tap is bumped automatically on every GitHub Release, so it will move ahead of core. Plugins upgrade on their own schedule through their registry tags. There is no compatibility matrix in the README tying a hyper-mcp version to a plugin version, so plugin and host upgrades are independent variables you have to test together.
Licence is Apache-2.0. That is a permissive licence, and it does not impose copyleft obligations on your own code. Separately, cosign is a distinct project with its own licence and is not bundled here; you install it yourself. Nothing in this article is legal advice.
Editorial conclusion
Adopt hyper-mcp if you already publish container images and want MCP tools that are versioned, signed and sandboxed rather than a pile of local scripts, and if you are willing to install cosign on every machine that loads an oci:// plugin. Do not adopt it if your tools are a handful of Python functions you edit in place; the WASM compile step and the registry round trip buy you nothing there. Before committing, verify three things: that cosign is present on each host or that you have explicitly accepted insecure_skip_signature, that the allowed_hosts value in runtime_config matches what each plugin actually needs, and whether your client can spawn one hyper-mcp process per connection if you intend to put an SSE or streamable-http proxy in front of stdio.
Community notes