Publish an MCP tool as a static, hash-verified file. Run it sandboxed, on demand, with zero infrastructure — the way static site hosting did to web servers: don't run Apache, publish HTML.
npx -y @rckflr/mcpwasm https://mauricioperera.github.ioMCP clients like Claude or Cursor can call arbitrary third-party tools. Executing that code directly in your backend means it can read your secrets, hit your database, phone home, or loop forever. You either trust the author fully, or you don't run the tool.
Five steps, all sandboxed, no state kept between requests.
/llms.txt plus per-skill tool.js and SKILL.md.llms.txt, fetches each tool.js, and verifies its SHA-256.host.fetchOrigin — scoped to the publishing origin only; anything else throws inside the sandbox.tools/list / tools/call over JSON-RPC 2.0 back to the client.All four are real, deployed, and tested — not roadmap.
Point any MCP client at the deployed gateway. It discovers, verifies, and sandboxes a publisher's skills on every request.
curl -s -X POST \
"https://llmstxt-gateway.rckflr.workers.dev/mcp?origin=<url-encoded-origin>" \
-H "Authorization: Bearer <AUTH_TOKEN>" \
-H "content-type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'Run any origin's skills locally over stdio — including origin memory (verified BM25 search, 0.4.0), each skill's SKILL.md recipe served as an MCP resource (0.5.0), and multi-project origins via scopes: kdd__search_knowledge with per-scope memory (new in 0.6.0). No gateway, no server, on either end.
npx -y @rckflr/mcpwasm https://mauricioperera.github.ioBuild your own platform host with the exact isolation the gateway uses.
import { AsyncToolHost } from "@rckflr/mcpwasm";
const host = new AsyncToolHost({ allowedOrigin: "https://example.com" });
await host.init();
host.loadToolSource(toolJsSource);
const result = await host.callTool("sum_numbers", { a: 2, b: 40 });
host.dispose();The whole runtime in a browser tab (new in 0.7.0): discovery, byte-for-byte SHA-256 verification, one QuickJS-wasm sandbox per tool, scopes and per-scope memory. The publisher only needs CORS — GitHub Pages already sends it. No server on their side, no Node on yours.
import { connectStaticSkills } from "@rckflr/mcpwasm/web";
const skills = await connectStaticSkills("https://mauricioperera.github.io", opts);
await skills.callTool("search_knowledge", { q: "how do I publish?" });tab-agent is a personal AI agent that is nothing but static files + your browser: shared memory (the cq-git commons over the GitHub API), verified tools (this runtime, hash-pinned & sandboxed), and a model you own — the provider credential is never exposed (run it in-tab via WebGPU, your endpoint, or an operator proxy). It answers the personal-agent supply-chain problem by inverting it: tools are verified, not screened.
None of them alone is enough. Together, they bound what a third-party tool can do — and who vouches for it.
Every tool.js is pinned by SHA-256 in llms.txt. A single flipped byte and the skill is excluded — not degraded, not executed.
Each skill runs in its own QuickJS-wasm context: no fetch, no process, no disk. The only bridge out is an explicit, origin-scoped host.fetchOrigin.
Signed human review with an expiry window — pre-registered Ed25519 keys or keyless Sigstore identities (the spec's recommended default since v0.4). Honest today: one registered reviewer. The mechanism scales; the reviewer network hasn't yet.
Real numbers from the deployed gateway, not synthetic estimates.
Single-client benchmark from México to the Cloudflare Workers edge — this is latency of one observer, not a load test. Full matrix, methodology, and raw data are in BENCHMARK.md.
npx -y @rckflr/mcpwasm https://mauricioperera.github.io{
"mcpServers": {
"misitio": {
"command": "npx",
"args": ["-y", "@rckflr/mcpwasm", "https://mauricioperera.github.io"]
}
}
}curl -s -X POST \
"https://llmstxt-gateway.rckflr.workers.dev/mcp?origin=https%3A%2F%2Fllmstxt-demo-site.rckflr.workers.dev" \
-H "Authorization: Bearer <AUTH_TOKEN>" \
-H "content-type: application/json" \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"sum_numbers","arguments":{"a":2,"b":40}}}'The deployed gateway requires a bearer token (not published here). Full curl walkthrough — including the open demo, bookstore, and docs publishers — is in the README.
llms-txt-skills is the format; mcpwasm is a runtime for it. A publisher serves hash-pinned, attested skills once, the standard way — the runtime discovers, verifies, and runs each as an MCP tool. The whole contract between them is one tool_sha256 and its attestation.
llms.txt whose ## Skills section lists each executable skill with its tool.js and tool_sha256 — mirrored in /.well-known/agent-skills/index.json and signed in attestations.json. Optionally, a hash-pinned BM25 snapshot (one llms-skills memory command over an OKF bundle) adds serverless search over the site's own knowledge. This is exactly what the llms-txt-skills spec defines. Since llms-skills 0.4.0, the bundle can also carry signed freshness: a reviewer attests “still true”, voided on edit, expiring on a date.llms.txt, and verifies every tool.js against its tool_sha256 and its attestation — rejecting any mismatch before loading it.SKILL.md recipe is served alongside as an MCP resource (with a get_skill_guide fallback) — the agent gets the manual, not just the hammer. Claude, Cursor, any MCP host list and call it like any other tool.tool.js verbatim inside a QuickJS-wasm sandbox — no network or filesystem except the host capabilities it grants (a scoped fetchOrigin back to the site, and search over the site's own content). The result returns to the client.Neither side has to trust the other's prose: mcpwasm re-derives the hash and checks the signature itself. Static hosting + a verifying runtime = an MCP server with no server to run.
Want to be the publisher side? Start from the GitHub template — a working publisher out of the box (example knowledge bundle, generated skills, validation CI) that this runtime consumes as-is.
mcpwasm is the reference implementation of two provisional extensions to the llms-txt-skills standard: Executable Skills (v0.5, with origin memory and scopes) and Skill Attestations (v0.4). Every MUST in those specs is field-tested in this code — spec and implementation are kept in sync.