hyper-mcp: an MCP server that loads its tools as WebAssembly plugins

The problem hyper-mcp solves: MCP tools as distributable artifacts

Most MCP servers are compiled programs. Adding a tool means adding code to the server, rebuilding it, and shipping a new binary. hyper-mcp inverts that. The server itself is a host, and each tool arrives as a WebAssembly module that the server loads at startup from a URL. The README frames this as "Write plugins in your favorite language, distribute them through container registries, and run them anywhere", and the configuration file is where that promise becomes concrete: a plugin entry is a name, a URL, and an optional description.

The audience is narrow but real. If you run Claude Desktop, Cursor IDE, or another MCP-compatible client and you want to add capabilities without writing Rust, the plugin boundary is the point. The repository also ships a CREATING_PLUGINS.md and a TEMPLATES.md at the top level, which suggests the maintainers expect plugin authors rather than only server users. The Extism dependency in Cargo.toml is what makes the WASM host work; hyper-mcp is not implementing a WebAssembly runtime itself.

How plugin resolution and sandboxing actually work

At startup hyper-mcp reads a JSON or YAML config and resolves each plugin URL. Five schemes are documented: oci:// for OCI-compliant registries, file:// for local files, http:// and https:// for remote files, and s3:// for Amazon S3 objects, which the README says requires AWS credentials in the environment. The Cargo.toml backs this up with oci-client, aws-sdk-s3 and aws-config as direct dependencies, so S3 support is compiled in rather than bolted on.

The security model has two layers. The first is the WASM sandbox: the README lists the ability to limit network, filesystem and memory access, and the config exposes that through runtime_config. In the example config the myip plugin is restricted with allowed_hosts set to ["1.1.1.1"], while the fetch plugin uses ["*"], and fetch also sets memory_limit to "100 MB". That is a per-plugin decision, not a global one, which means a careless entry can widen the sandbox for one tool without touching the rest.

The second layer applies only to oci:// URLs. hyper-mcp verifies the signature of every OCI plugin before loading it, and the README states this is done by shelling out to the cosign CLI. That is an unusual design choice: signature verification is delegated to an external binary on PATH rather than performed in-process, even though sigstore appears as a Rust dependency with the cosign, verify and bundle features enabled. Either way, the operational consequence is the same. A missing cosign binary breaks OCI plugin loading.

Installing hyper-mcp and loading a first plugin

The README offers three install paths. Homebrew covers macOS and Linux from core with no tap setup, and the project's own tap is bumped on every GitHub release. Pre-built archives exist for macOS ARM64, Linux ARM64, Linux x86_64 and Windows x86_64. If Rust is already installed, crates.io works too.

brew install hyper-mcp

The core formula is the recommended default; the tap variant installs the same binary but tracks releases sooner. From Rust:

cargo install hyper-mcp

Before any oci:// plugin will load, cosign must be on PATH. The README points at the official sigstore installation instructions rather than shipping one. If you only use file://, http://, https:// or s3:// URLs, cosign is not needed at all.

The next step is the config file. On Linux it lives at $HOME/.config/hyper-mcp/config.json, on macOS at $HOME/Library/Application Support/hyper-mcp/config.json, and on Windows under the roaming app data folder. The README's example config is the shortest path to a working setup:

{
  "plugins": {
    "time": {
      "url": "oci://ghcr.io/hyper-mcp-rs/time-plugin:latest",
      "description": "Get current time and do time calculations"
    },
    "hash": {
      "url": "oci://ghcr.io/hyper-mcp-rs/hash-plugin:latest"
    }
  }
}

Starting the server is a single command:

hyper-mcp

The server speaks stdio, so it is meant to be launched by an MCP client rather than used from a terminal session. For debugging, the README suggests RUST_LOG=debug. Output is also written to daily rolling log files, at $HOME/.config/hyper-mcp/logs/mcp-server.log on Linux. If you point the config at a plugin without a valid signature, loading fails unless you set insecure_skip_signature to true or export HYPER_MCP_INSECURE_SKIP_SIGNATURE=true, and the README explicitly calls that not recommended for production.

Where hyper-mcp stops: stdio only, and the proxy workaround

The README is direct about transports. hyper-mcp supports stdio. For SSE or streamable-http, the instruction is to wrap hyper-mcp in a proxy that supports those network transports and that creates one hyper-mcp instance per client connection. That second clause matters. A shared instance would have shared plugin state, and the README's phrasing implies the intended deployment is one process per client.

This is the sharpest limitation in the project. If your architecture assumes a long-lived HTTP MCP endpoint, hyper-mcp is not that out of the box, and the proxy you insert becomes part of your operational surface. The axum dependency in Cargo.toml suggests HTTP machinery is present in the build, but the README does not document a built-in network transport, and nothing in the repository's documentation describes one.

The plugin lifecycle is a second boundary. Dynamic plugin loading and unloading is listed as a feature and marked configurable, but the README does not document the config keys or the semantics of unloading a plugin while a client holds a reference to its tools. Treat that as unverified until you read RUNTIME_CONFIG.md.

A third gap is rollback. The example configs use the :latest tag on OCI plugins. The README does not document rollback or version pinning behaviour, so if a plugin publisher pushes a bad image under the same tag, the documentation gives you no documented recovery path beyond changing the URL yourself.

hyper-mcp compared with a compiled MCP server

The obvious alternative is a conventional MCP server written in TypeScript or Python, where each tool is a function in the same process and distribution happens through npm or PyPI. The difference is not language preference, it is the trust boundary. A compiled server runs every tool with the same privileges as the server itself. hyper-mcp gives each plugin its own runtime_config, so allowed_hosts and memory_limit can be set per plugin, and OCI plugins carry a signature that is checked before load.

The cost is indirection. A compiled server has one dependency graph; hyper-mcp has one dependency graph plus one artifact per tool plus cosign. Debugging moves from a stack trace in your own code to a log file under the config directory and a WASM module you may not have written. For a handful of tools you control, that trade is probably not worth it. For a client that needs to pull tools from third parties, or for a deployment where you want to hand a plugin author a URL scheme instead of a merge request, the boundary pays for itself.

The README also mentions tool name prefixes to prevent collisions, which is the kind of feature you only need once plugins come from more than one source. It is a small signal that the project is designed for a multi-vendor plugin ecosystem rather than a single team's internal tools.

Maintenance, licensing and what the release cadence implies

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent: v0.8.2 on 2026-06-15, v0.8.3 on 2026-06-24, and a nightly build on 2026-09-10. The nightly channel means there is a moving target alongside tagged releases, and the Homebrew tap is described as bumped automatically on every GitHub release, so the tap tracks faster than core. If you install from the tap, expect version churn between tagged crates.io releases.

Upgrade cost is mostly the plugin artifacts, not the server. The example configs pin plugins to :latest, which means a server upgrade and a plugin upgrade are independent events. Nothing in the README documents a lockfile or digest pinning for plugin URLs, so if you want reproducible deployments you would need to pin tags or digests yourself in the config.

Licensing is Apache-2.0, stated in both Cargo.toml and the README badge. That is a permissive licence with an explicit patent grant and a notice requirement when redistributing. It says nothing about the licences of the plugins you load, which are separate artifacts from separate publishers. Check those independently; the hyper-mcp licence does not cover them. This is not legal advice.

Editorial conclusion

Adopt hyper-mcp if you want MCP tools packaged as signed WebAssembly artifacts that you can pin by URL and sandbox with allowed_hosts and memory_limit, and if you are comfortable with stdio plus a per-connection proxy for network transports. Do not adopt it if you need a server that speaks SSE or streamable-http on its own, or if you cannot install cosign and are unwilling to set insecure_skip_signature. Verify three things before committing: that cosign is on PATH for every OCI plugin you list, that each plugin's runtime_config names only the hosts it needs, and that the plugin tags you reference are ones you intend to keep pulling.

Frequently asked questions

Official sources

1. hyper-mcp-rs/hyper-mcp on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases