Hyper MCP Server
Author: tuananh
Description: A fast, security-focused Model Context Protocol (MCP) server implemented in Rust that loads and runs tools via sandboxed WebAssembly (WASM) plugins.
Stars: 2
Forks: 0
License: Apache License 2.0
Category: Open Source
Overview
Installation
{
"plugins": {
"time": {
"url": "oci://ghcr.io/tuananh/time-plugin:latest"
},
"qr_code": {
"url": "oci://ghcr.io/tuananh/qrcode-plugin:latest"
},
"hash": {
"url": "oci://ghcr.io/tuananh/hash-plugin:latest"
},
"myip": {
"url": "oci://ghcr.io/tuananh/myip-plugin:latest",
"runtime_config": {
"allowed_hosts": ["1.1.1.1"]
}
},
"fetch": {
"url": "oci://ghcr.io/tuananh/fetch-plugin:latest",
"runtime_config": {
"allowed_hosts": ["*"],
"memory_limit": "100 MB",
}
}
}
}hyper-mcp{
"mcpServers": {
"hyper-mcp": {
"command": "/path/to/hyper-mcp"
}
}
}FAQs
How does Hyper MCP Server's WebAssembly sandboxing compare to container-based isolation for MCP tool security?
WASM sandboxing provides finer-grained isolation and faster startup than containers. WASM runtimes like Extism enforce memory safety at the instruction level, block all I/O by default, and start in under 10ms versus 100-300ms for containers. Per-instance memory footprint stays under 5MB, enabling per-invocation sandboxing that containers cannot match economically. The tradeoff: containers support any Linux binary without recompilation, while WASM requires plugins built for wasm32-wasi targets. Prioritize WASM for high-frequency, low-trust plugin execution and containers when legacy tooling or full OS-level isolation requirements dominate.
What are the performance implications of running each MCP tool in its own WASM VM via Extism?
Each WASM VM adds 1-10ms startup latency per plugin instantiation, and Extism's runtime layer introduces roughly 5-15% overhead for compute-intensive tasks due to instruction translation and sandbox boundary crossings. Memory scales linearly since each VM maintains its own heap, so ten plugins with 100MB limits reserve up to 1GB. For I/O-bound operations like API calls, WASM overhead is negligible relative to network latency. CPU-heavy plugins (cryptographic operations, large data parsing) will consistently underperform native implementations. Benchmark your specific plugin mix, because performance impact depends on whether tools are compute-bound or I/O-bound.
How does Sigstore/Cosign signature verification work for Hyper MCP Server plugins, and what happens if verification fails?
During plugin initialization, Hyper MCP Server queries the registry's transparency log via Sigstore to confirm the plugin's digest matches a signature from an authorized publisher, then uses Cosign to validate the signing certificate against Fulcio's chain of trust. This happens before the WASM binary is instantiated. If verification fails, the plugin load aborts and the server continues without that plugin. The `HYPER_MCP_INSECURE_SKIP_SIGNATURE=true` environment variable bypasses all checks, but should only be used during local development with unsigned artifacts.
Can Hyper MCP Server plugins communicate with each other, or are they fully isolated from one another?
Plugins are fully isolated at the WASM runtime layer. Each runs in its own Extism VM instance, so one plugin cannot call another's functions, read another's memory, or share state. Plugins can indirectly coordinate through the MCP client, which can invoke multiple tools sequentially and pass outputs from one tool as inputs to another. This orchestration happens at the client layer, not within the server runtime. A compromised plugin cannot escalate privileges through peer plugins, only through explicitly granted network or filesystem permissions configured per plugin.
How do I write a custom Rust plugin using the V2 plugin interface and publish it to a private OCI registry for Hyper MCP Server?
Add `extism-pdk` to your Cargo.toml and define plugin functions with input/output types matching your MCP tool schema. Compile to `wasm32-unknown-unknown` using `cargo build --target wasm32-unknown-unknown --release`. Publish to a private OCI registry using ORAS CLI with `oras push your-registry.internal/tool:v1.0.0 target/wasm32-unknown-unknown/release/your-plugin.wasm`. For production, sign your plugin with `cosign sign --key cosign.key your-registry.internal/tool:v1.0.0` so Hyper MCP Server can verify the artifact at load time. Configure registry credentials via Docker config or environment variables for authenticated pulls.
What is the recommended way to configure allowed_hosts and memory_limit for production deployments of Hyper MCP Server?
Adopt a principle of least privilege: enumerate specific API domains rather than wildcards in allowed_hosts, and set memory_limit conservatively based on actual workload testing. Maintain separate config files per environment so development can use broader permissions while production enforces stricter boundaries. Monitor WASM runtime errors to identify when plugins hit memory caps or attempt blocked network calls, then adjust deliberately. Consider running separate Hyper MCP Server instances with distinct configs to isolate high-risk third-party tools from internal utilities. Document every allowed_hosts entry with a business justification and review quarterly.