This server provides a two-tool interface that collapses many downstream tools into a single, token-efficient surface.
docs_search: Discover available downstream tools by name or substring. Call this first to learn what tools are accessible before writing any code.
execute_code: Run JavaScript snippets inside a sandboxed kernel. The snippet can chain multiple downstream tool calls via callTool(name, args). Only the final return value is surfaced — intermediate outputs stay hidden inside the sandbox, keeping token usage low.
Key benefits:
Chain multiple tool calls in one round-trip: Orchestrate N tool calls inside a single execute_code script instead of making N separate MCP calls, reducing back-and-forth with the model.
Token efficiency: Compressing N downstream tools into just 2 tools keeps bootstrap token cost flat (O(1)) rather than growing linearly — at 30 tools this is ~13.6% of the direct MCP token cost.
Portal mode: Can federate multiple upstream MCP servers (filesystem, GitHub, memory, etc.) behind this single two-tool surface with a unified security/capability manifest.
Allows deploying agents to Cloudflare Workers runtime.
Allows downloading models from Hugging Face for local execution.
Allows using Ollama as a local model endpoint for agent execution.
Allows using OpenAI's models for AI agent interactions.
Allows exporting telemetry data via OpenTelemetry for observability.
Provides Redis-based backend for checkpointing and state persistence.
Provides Upstash-based backend for checkpointing and state persistence.
WasmAgent adds a verifiable evidence layer to agent tool use: protect tool calls, record what happened, audit the result, and admit trusted traces into downstream systems.
Protect → Record → Audit → Admit · Sync — agent↔UI shared state
Pick your entry point:
Goal | Install |
Protect tools — runtime firewall, policy enforcement, taint tracking |
|
Record evidence — signed AEP records after every agent run |
|
Admit from traces — compliance scoring produces |
|
Sync state — reducer-backed agent↔UI shared state, agent reads projections + writes intent |
|
Trust Pack — 30-minute end-to-end: docs/quickstarts/trust-pack-30min.md
Related MCP server: Code Executor MCP Server
Three paths — pick the one that fits your use case:
Wrap any MCP server: vet tools before execution, enforce policy per call, track taint across results.
npm install @wasmagent/mcp-firewallimport { evaluatePolicy, snapshotTool, taintObservation, vetTool } from "@wasmagent/mcp-firewall";
const entry = {
name: "read_file",
description: "Read a file from disk",
inputSchema: { type: "object", properties: { path: { type: "string" } } },
};
const args = { path: "/tmp/report.txt" };
const consentRecords = [];
// Before calling a tool
const snap = snapshotTool(entry, "my-server"); // hash descriptor at registration
const vetting = vetTool(entry); // static scan: injection / exfil / rug-pull
const decision = evaluatePolicy(entry.name, args, vetting, consentRecords);
if (decision.decision === "deny") throw new Error(`Blocked: ${decision.reasons.join("; ")}`);
if (decision.decision === "ask_user") {
// surface consent UI, then call recordConsent(...)
}
// After receiving result
const rawResult = "example report contents";
const obs = taintObservation(entry.name, rawResult); // boundary-tagged, safe to assemble into prompt→ Security pack · OWASP Agentic Top 10 · Attack demos
Emit a signed evidence record after every agent run — consumable by trace-pipeline for audit and training.
npm install @wasmagent/aepimport { AEPEmitter } from "@wasmagent/aep";
const emitter = new AEPEmitter({ run_id: "run-001", model_id: "claude-sonnet-4-6" });
// During the run — add tool call evidence
emitter.addAction({ tool_name: "bash", outcome: "pass", exit_code: 0 });
// At the end — emit the record
const record = emitter.build();
// record satisfies aep/v0.1 JSON Schema — ready for evomerge validate-aep→ AEP schema · trace-pipeline 10-min tutorial
Run agent-generated code in an isolated WASM kernel — no host-process access.
npm install @wasmagent/aisdk @wasmagent/kernel-quickjsimport { sandboxedJsTool } from "@wasmagent/aisdk";
import { QuickJSKernel } from "@wasmagent/kernel-quickjs";
// Drop into any AI SDK / LangChain / OpenAI Agents setup
const codeTool = sandboxedJsTool({ kernel: new QuickJSKernel() });→ Kernel comparison · Getting started
Reducer-backed collaborative state where the LLM reads projections, dispatches semantic actions, and respects affordances — all through standard tools.
npm install @wasmagent/coreimport { defineStateModel, SharedStateStore, stateTools } from "@wasmagent/core/shared-state";
// 1. One reducer, shared by both UI and agent.
const model = defineStateModel({
initial: () => ({ page: "list", selectedId: null as string | null }),
reduce: (s, a) => {
if (a.type === "SELECT") return { ...s, page: "detail", selectedId: a.id };
if (a.type === "BACK") return { ...s, page: "list", selectedId: null };
return s;
},
project: (s) => ({ page: s.page, selectedId: s.selectedId }),
affordances: (s) => s.page === "list" ? ["SELECT"] : ["BACK"],
});
// 2. Server-side store keyed by session.
const store = new SharedStateStore(model);
// 3. Give the agent read_state + dispatch_action tools.
const tools = stateTools(store, "session-001");
// Pass `tools` to any ToolCallingAgent — the LLM reads state and dispatches intent.The semantic action stream doubles as AEP evidence — every dispatch is a provenance-ready record (see #141 for the full confluence design).
📚 Docs · Getting started · Kernels · OWASP governance · Security pack · Changelog
WasmAgent uses a five-tier maturity scale to prevent "shipped" from becoming a vague claim:
Tier | Meaning | Semver guarantee | Production use |
stable | Public API locked; breaking changes require major-version bump | Yes | Yes |
beta | Functional and used in production, but a specific limitation is documented (e.g. first-line filter only, contract still evolving) | Minor/patch only | Yes, with caveats documented |
alpha | Schema versioned; fields may be added without a breaking-change bump | No | Informed use |
demo | Demonstration or example code; not hardened for production | No | No |
research | Research-grade prototype; interfaces may change without notice | No | No |
Packages not listed here (model adapters, UI cards, etc.) follow the same scale — see each package's README or package.json wasmagent.stability field.
Package | Maturity | Notes |
| stable | Public API; semver guaranteed |
| stable | |
| stable | |
| stable | Published 0.1.0; gateway composes all firewall layers |
| beta | First-line filter, not adversarial-grade — keyword bag + lightweight n-gram classifier; use defence-in-depth |
| beta | v0.2 signature contract (Ed25519) shipped; schema versioned |
| alpha | GENAI_SEMCONV, AEP↔OTel bridge |
| alpha | API stable, may add fields |
| alpha | Schema versioned; may add fields without breaking |
| alpha — private | Not yet published to npm |
| alpha — private | Not yet published to npm |
| alpha | |
| alpha |
WasmAgent is a portable, governable agent runtime for safe code execution, verifiable rollouts, and post-training data loops.
Repo | Role |
wasmagent-js (this repo) | Embedded Agent Runtime / WASM Kernel / policy / verifier / adapters |
Cloudflare flagship demo and deploy template for safe coding agents | |
Public datafactory and eval-trust backend for rollout data |
Task → Safe Runtime → Verifiable Rollout → Trajectory Export → DPO/PPO Data → Better ModelsThree wedges where wasmagent stands apart from generic agent frameworks:
Wedge | What it means |
Sandboxed execution | Three isolation tiers — VmKernel / WASM (QuickJS·Pyodide·Wasmtime) / microVM — with a single |
Runtime compliance |
|
Trace-to-training contract | Verifiable rollout branching, objective scoring, DPO/PPO export — the loop from runtime evidence to training data is first-class, not an afterthought |
# | Axis | Status |
1 | Multi-provider adapters — one | shipped |
2 | Three isolation tiers — | shipped |
3 | Cross-runtime + offline — Node / edge / browser / air-gapped laptop; | shipped |
4 | Memory layers — | shipped |
5 | Durable workflows — | shipped |
6 | Code-mode MCP — N tools → 2 tools ( | shipped |
7 | Devtools + OTel — local Studio, | shipped |
8 | Goal-directed loop — agent synthesises success criteria, verifies, retries with hints | shipped 2026-06-18 |
9 | Adaptive execution — registered fallbacks (L1) → synthesised tool (L2) → relaxed goal (L3) | shipped 2026-06-18 |
10 | MCP runtime firewall — | shipped 2026-06-25 |
Full comparison with Vercel AI SDK, LangGraph.js, OpenAI Agents JS, Mastra, CF Agents SDK: docs/compare.md
import { ToolCallingAgent, AnthropicModel } from "@wasmagent/core";
import { z } from "zod";
const agent = new ToolCallingAgent({
model: new AnthropicModel("claude-haiku-4-5-20251001"),
tools: [{
name: "search", description: "Search the web",
inputSchema: z.object({ query: z.string() }),
readOnly: true, idempotent: true,
forward: async ({ query }) => `Results for: ${query}`,
}],
stopPolicies: ["steps:10", "cost:0.5"],
});
for await (const ev of agent.run("Search for recent AI news")) {
if (ev.event === "final_answer") console.log(ev.data.answer);
}import { CodeAgent, AnthropicModel } from "@wasmagent/core";
const agent = new CodeAgent({
model: new AnthropicModel("claude-sonnet-4-6"),
tools: [], // kernel executes code; no extra tools needed
maxSteps: 10,
});
for await (const ev of agent.run("What is 42 * 1337?")) {
if (ev.event === "final_answer") console.log(ev.data.answer);
}npm install -g @wasmagent/cli
# Agent runs
wasmagent run "What is the square root of 144?"
wasmagent run "Summarise AI news" --stream | jq .
# Rollout / training data
wasmagent rank-rollout rollouts.jsonl --out ranked.jsonl
wasmagent validate-rollouts ranked.jsonl
wasmagent export-rollouts --in ranked.jsonl --format dpo --out dpo.jsonl
# MCP security (scan → guard → evidence)
wasmagent init --guard # generate wasmagent.policy.yaml
wasmagent scan-mcp tools.json # static risk scan, exits 1 on critical findings
wasmagent guard --config wasmagent.policy.yaml --upstream tools.json
wasmagent evidence export --input aep-records.jsonl --format jsonGitHub Action — enforce policy in CI:
- uses: WasmAgent/wasmagent-js/.github/actions/agent-evidence-gate@main
with:
policy: wasmagent.policy.yaml
tools-file: mcp-tools.json
fail-on-policy-violation: "true"→ MCP Guard guide · Attack demos
Capability | Guide |
Shared state — reducer-backed agent↔UI sync, projections, affordances | |
MCP firewall — vetTool, ScopeLease, ApprovalReceipt | |
AEP v0.2 evidence — causal chain, scope lease, taint, memory refs | |
OWASP MCP Top 10 crosswalk | |
OWASP security demo (10 scenarios) | |
Security benchmark runner | |
AEP ↔ OTel bidirectional mapping | |
AgentTeam delegation chain | |
Claim dashboard |
|
Quality runners (self-consistency, reflect-refine, parallel fork-join) | |
Durable runtime (checkpoints, SSE resume, HITL) | |
Observational memory — ~22% tokens on 50-turn traces | |
Goal-directed agent with verifiers | |
Production APIs (retry, evals, OTel, React hook) | |
API stability policy |
First-class adapters: Anthropic · OpenAI · Doubao · DeepSeek · Kimi · Qwen · GLM · MiniMax · local llama.cpp
// Chinese providers with thinking support
import { DoubaoModel, DoubaoModels } from "@wasmagent/model-doubao";
import { DeepSeekModel, DeepSeekModels } from "@wasmagent/model-deepseek";
// Local / offline
import { LocalModel } from "@wasmagent/model-local"; // node-llama-cpp, multi-mirror downloadFull provider reference and proxy/custom endpoint setup: docs/guides/openai-compat-recipes.md
Project | Role |
Flagship Cloudflare deploy template — wires every wasmagent-js capability into a real edge product | |
Training data factory — converts ranked rollouts into DPO/PPO datasets |
Upstream integration status (PRs filed to Vercel AI SDK, Mastra,
LangChain.js, ElizaOS, MCP registry, …) is tracked in
docs/distribution/upstream-prs.md.
bun install && bun run build
bun test packages/
bun run typecheck
bun run bench # reproduce all README benchmarks
bun run check:branding # CI guard: no old brand references
bun run verify:claims # CI guard: all benchmark claims have evidence scriptsLook up the available downstream tools by name or substring. Call this BEFORE writing an execute_code script to learn what's available.
| Name | Required | Description | Default |
|---|---|---|---|
| names | No | Optional list of exact tool names to fetch. Takes precedence over `query`. | |
| query | No | Substring to filter tool names/descriptions. Empty/omitted returns all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It describes the search function but does not disclose any behavioral traits like idempotency, rate limits, or auth requirements. Lacks detail on what exactly is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema and does not describe return format. Since tool is used before writing code, knowing output structure is important. Incomplete in that aspect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by noting that empty query returns all and that names takes precedence over query. Enhances understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it looks up downstream tools by name or substring, distinguishing it from the sibling tool execute_code which executes code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to call BEFORE writing an execute_code script, providing clear context. Does not mention when not to use or alternatives, but sibling list is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a JavaScript snippet inside a sandboxed kernel. The snippet may call callTool(name, args) to invoke any downstream tool. Only the snippet's final return value (or the value assigned to __finalAnswer__) is returned to you — intermediate tool outputs stay in the sandbox. Use this to chain many tool calls in one round.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript source. May use top-level `await`. Must end with a return value or set `__finalAnswer__ = ...`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully cover behavioral traits. It mentions sandboxing, the ability to call downstream tools via callTool, and that only the final return value is returned. However, it lacks details on error handling, timeouts, or limitations on callTool, which are important for a code execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. Every sentence adds necessary information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of code execution and chaining, the description covers the core functionality: sandboxed execution, chaining via callTool, and final return value. Minor gaps remain in error behavior and environment specifics, but for an agent it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a description for the 'code' parameter. The tool's description adds value by explaining that the snippet may call `callTool(name, args)`, which is not in the schema description. It also reinforces the return value requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a JavaScript snippet in a sandboxed kernel, distinguishing it from the only sibling tool 'docs_search' which is for documentation search. It uses specific verbs and resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to chain many tool calls in one round,' providing clear context for when to use. It does not exclude alternatives, but with only one sibling, the distinction is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have completely distinct purposes: docs_search for discovering downstream tools, and execute_code for running code that calls them. There is no overlap or confusion.
Both tool names follow a consistent verb_noun pattern with snake_case: docs_search and execute_code.
Two tools is exactly right for this server's purpose as a meta-agent: search to discover, execute to run. It's minimal but complete.
The tool surface fully covers the intended workflow: discovering available downstream tools and executing code that chains them. There are no obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/WasmAgent/wasmagent-js'
If you have feedback or need assistance with the MCP directory API, please join our Discord server