Two problems get solved together here. Plugins ship as OCI images, so installing a tool is a registry pull with a signature check rather than a git clone and a build. And because they run in Wasm, each one's network and memory access is declared in your config instead of inherited from the host process — a real answer to the question of what a third-party MCP tool can reach. Check the new repository for current development.
A fast MCP server written in Rust that gets its capabilities from WebAssembly plugins rather than from built-in tools. Plugins can be written in any language that compiles to Wasm, distributed through standard OCI registries, and run anywhere from a server to an edge or IoT device. It is built on Extism, and supports all three transports in the spec: `stdio`, `sse` and `streamable-http`.
- A plugin model where each entry in the config is a URL — `oci://` for container registries, `file://` for local files, `http://` or `https://` for remote files, and `s3://` for Amazon S3 objects using your existing AWS credentials
- Sandboxing that is configured, not assumed: per-plugin `runtime_config` sets `allowed_hosts` and a `memory_limit`, so a fetch plugin can reach the network while an IP-lookup plugin is restricted to a single host
- Supply-chain verification — OCI plugin images are signed at publish time and verified at load time with sigstore, and loading an unsigned plugin requires explicitly setting an insecure-skip flag or `HYPER_MCP_INSECURE_SKIP_SIGNATURE`
- Tool name prefixing to stop collisions when several plugins expose similarly named tools
- Example plugins maintained in the repository to start from, covering time, QR codes, hashes, IP lookup, web fetching, filesystem operations, GitHub and GitLab, arXiv search, SQLite, Qdrant, crates.io and Go module lookups, library documentation, web search and Python evaluation
- A documented pattern for filtering the exposed tool set with regexes, for keeping a large plugin set manageable per environment
No account and no key for the server itself; individual plugins may want their own credentials, and the S3 scheme uses whatever AWS credentials are already in your environment. Write a config file at the platform path — `$HOME/.config/hyper-mcp/config.json` on Linux, `$HOME/Library/Application Support/hyper-mcp/config.json` on macOS — listing your plugins and their runtime configs, then run `hyper-mcp`. It defaults to `stdio`; `--transport sse` or `--transport streamable-http` switch it. A container image is published as `tuananh/hyper-mcp` on Docker Hub. Apache 2.0 licensed. Note that the project has been transferred to a new repository, `joseph-wortmann/hyper-mcp`, which the author points to for the latest updates.